[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lucene-dev
Subject:    [jira] Updated: (LUCENE-469) (Parallel-)MultiSearcher: using Sort object changes the scores
From:       "Luc Vanlerberghe (JIRA)" <jira () apache ! org>
Date:       2005-11-25 20:28:56
Message-ID: 1285772752.1132950536915.JavaMail.jira () ajax ! apache ! org
[Download RAW message or body]

     [ http://issues.apache.org/jira/browse/LUCENE-469?page=all ]

Luc Vanlerberghe updated LUCENE-469:
------------------------------------

    Attachment: MultiSearcherSort.patch

Here's the updated patch (at last....)

- the redundant changes to FieldDocSortedHitQueue are reverted.
- maxScore is private with public accessors.
- TopFieldDocs search (Weight weight, Filter filter, int n, Sort sort) is corrected \
                in MultiSearcher and ParallelMultiSearcher.
- I didn't add compatible but deprecated constructors for TopDocs and TopFieldDocs.  \
Those constructors where package private, so they couldn't be used by derived classes \
anyway.  So I think risk of breaking backwards compatibility for existing \
applications by changing these classes is fairly low.


> (Parallel-)MultiSearcher: using Sort object changes the scores
> --------------------------------------------------------------
> 
> Key: LUCENE-469
> URL: http://issues.apache.org/jira/browse/LUCENE-469
> Project: Lucene - Java
> Type: Bug
> Components: Search
> Versions: CVS Nightly - Specify date in submission
> Environment: 21 november 2005, revision 345901
> Reporter: Luc Vanlerberghe
> Attachments: MultiSearcherSort.patch, MultiSearcherSort.patch, \
> TestMultiSearcher.patch 
> Example: 
> Hits hits=multiSearcher.search(query);
> returns different scores for some documents than
> Hits hits=multiSearcher.search(query, Sort.RELEVANCE);
> (both for MultiSearcher and ParallelMultiSearcher)
> The documents returned will be the same and in the same order, but the scores in \
> the second case will seem out of order. Inspecting the Explanation objects shows \
> that the scores themselves are ok, but there's a bug in the normalization of the \
> scores. The document with the highest score should have score 1.0, so all document \
> scores are divided by the highest score.  (Assuming the highest score was>1.0) \
> However, for MultiSearcher and ParallelMultiSearcher, this normalization factor is \
> applied *per index*, before merging the results together (the merge itself is ok \
> though). An example: if you use
> Hits hits=multiSearcher.search(query, Sort.RELEVANCE);
> for a MultiSearcher with two subsearchers, the first document will have score 1.0.
> The next documents from the same subsearcher will have decreasing scores.
> The first document from the other subsearcher will however have score 1.0 again !
> The same applies for other Sort objects, but it is less visible.
> I will post a TestCase demonstrating the problem and suggested patches to solve it \
> in a moment...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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


[prev in list] [next in list] [prev in thread] [next in thread]