lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: SweetSpotSimiliarity
Date Wed, 24 May 2006 21:12:24 GMT

: > Searcher.getSimilarity() is documented as a public method, but maybe
: > it's still OK to add Searcher.getSimilarity(String field)
:
: Right.  We can add a new method that, by default, punts to the old method.

it's not really clear to me why Marvin said...

: Adding a fieldName argument to similarity.tf(freq) would add
: significant overhead, since it gets called a *lot*.

...why would having the extra param add signifianct overhead? ... or is
the point just that if someone wants customized tf based on field name, it
would be better to make that choice once when starting to score a query,
(since the choice is going to be the same for all docs) rather then
everytime tf is called becuase the way a user chooses *might* involve a
lot of overhead?


Basically what we're discussing is adding this to Searcher...

  public Similarity getSimilarity(String fieldName) {
    return this.getSimilarity();
  }

And then modifying any Lucene core Query class that has a field associated
with it to call that method from it's own getSimilarity(Searcher) method.

Which raises the question in my mind:  Should a similar change be made to
IndexWriter, and replace Similarity.lengthNorm(String,int) with
lengthNorm(int) ?




-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message