Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 46948 invoked from network); 7 Apr 2008 23:04:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Apr 2008 23:04:12 -0000 Received: (qmail 34794 invoked by uid 500); 7 Apr 2008 23:04:10 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 34750 invoked by uid 500); 7 Apr 2008 23:04:10 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 34739 invoked by uid 99); 7 Apr 2008 23:04:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2008 16:04:10 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Apr 2008 23:03:26 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 60606234C0C0 for ; Mon, 7 Apr 2008 16:01:25 -0700 (PDT) Message-ID: <1920227100.1207609285393.JavaMail.jira@brutus> Date: Mon, 7 Apr 2008 16:01:25 -0700 (PDT) From: "Karl Wettin (JIRA)" To: java-dev@lucene.apache.org Subject: [jira] Commented: (LUCENE-1260) Norm codec strategy in Similarity In-Reply-To: <1445780161.1207599325798.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/LUCENE-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586588#action_12586588 ] Karl Wettin commented on LUCENE-1260: ------------------------------------- I suppose it would be possible to implement a NormCodec that would listen to encodeNorm(float) while one is creating a subset of the index in order to find all norm resolution sweetspots for that corpus using some appropriate algorithm. Mean shift?. Perhaps it even would be possible to compress it down to n bags from the start and then allow for it to grow in case new documents with other norm requirements are added to the store. I haven't thought too much about it yet, but it seems to me that norm codec has more to do with the physical store (Directory) than Similarity and should perhaps be moved there instead? I have no idea how, but I also want to move it to the instance scope so I can have multiple indices with unique norm span/resolutions created from the same classloader. > Norm codec strategy in Similarity > --------------------------------- > > Key: LUCENE-1260 > URL: https://issues.apache.org/jira/browse/LUCENE-1260 > Project: Lucene - Java > Issue Type: Improvement > Components: Search > Affects Versions: 2.3.1 > Reporter: Karl Wettin > Attachments: LUCENE-1260.txt > > > The static span and resolution of the 8 bit norms codec might not fit with all applications. > My use case requires that 100f-250f is discretized in 60 bags instead of the default.. 10? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org