[ 
https://issues.apache.org/jira/browse/LUCENE-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-1420:
---------------------------------------

    Attachment: LUCENE-1420.patch

Thanks Andrzej.

I made some further changes (attached new patch):

  * Changed the new Similarity.computeNorm(String, FieldInvertState)
    method to return the float norm instead of setting it on the
    FieldInvertState.  I also removed FieldInvertState.{get,set}Norm.

  * I put back the changes to SweetSpotSimilarity & MemoryIndex, but
    kept the old APIs (deprecated) for back compat.

  * I added {set/get}DiscountOverlaps to DefaultSimilarity, and also
    overrode computeNorm to use discountOverlaps to compute the number
    of tokens to pass to lengthNorm.

  * The Info class is private inside MemoryIndex, even though its ctor
    is public, so, I just added boolean to its ctor (ie, there's no
    back-compat issue).

  * Tweaked javadocs

So now, both DefaultSimilarity and SweetSpotSimilarity have the option
to discount overlaps, but do not do so by default.

> Similarity.lengthNorm and positionIncrement=0
> ---------------------------------------------
>
>                 Key: LUCENE-1420
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1420
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>    Affects Versions: 2.3.3, 2.9
>            Reporter: Andrzej Bialecki 
>            Assignee: Michael McCandless
>             Fix For: 2.3.3, 2.9
>
>         Attachments: LUCENE-1420.patch, similarity-v2.patch, similarity.patch
>
>
> Calculation of lengthNorm factor should in some cases take into account the 
> number of tokens with positionIncrement=0. This should be made optional, to 
> support two different scenarios:
> * when analyzers insert artificially constructed tokens into TokenStream 
> (e.g. ASCII-fied versions of accented terms, stemmed terms), and it's 
> unlikely that users submit queries containing both versions of tokens: in 
> this case lengthNorm calculation should ignore the tokens with 
> positionIncrement=0.
> * when analyzers insert synonyms, and it's likely that users may submit 
> queries that contain multiple synonymous terms: in this case the lengthNorm 
> should be calculated as it is now, i.e. it should take into account all terms 
> no matter what is their positionIncrement.
> The default should be backward-compatible, i.e. it should count all tokens.
> (See also the discussion here: http://markmail.org/message/vfvmzrzhr6pya22h )

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to