Norms are generally not calculated. You need to change the field you
want with this attribute: omitNorms="false".
On Tue, Feb 16, 2010 at 2:38 PM, Ahmet Arslan wrote:
>> After getting aware of all
>> these combinations, it seems not
>> wise to proceed blindly by punushing what ever we want.
>> Th
> After getting aware of all
> these combinations, it seems not
> wise to proceed blindly by punushing what ever we want.
> Thank you very
> much for letting me know.
Generally most of the people are happy with default solr scoring. Especially in
web like search.
I am not sure but you can find t
Hello ,
Thanks for your detailed explaination.
> Do you want to punish *more* long documents?
Not alot, but a bit more than default implementation. It seems
"lengthNorm" is field based and pinushing lengthy fields does fit most
of the cases in our project.
> There will be a trade-off
> Hello ,
> Thanks. That clears my
> doubts. Coming to the point two, Can
> you please tell me which part of the Similarity takes care
> of the
> same. Is it possible to implement in such a way that we
> give more
> preference to "number of found terms".
public float coord(int overlap,
Hello ,
Thanks. That clears my doubts.Coming to the point two, Can
you please tell me which part of the Similarity takes care of the
same. Is it possible to implement in such a way that we give more
preference to "number of found terms". Also, here in our case we need
to give more import
> 1) Does Solr (Lucene) consider exact match to be something
> more important ? I mean if the query is
> "description:organisation", then
> which one of the following would be returned?
> Document A, consiting
> just "description:organisation" , where
> as Document B consisting "descriptio
