lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LUCENE-903) FilteredQuery explanation inaccuracy with boost
Date Mon, 04 Jun 2007 01:48:15 GMT

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

Hoss Man updated LUCENE-903:
----------------------------

    Attachment: lucene-903.patch

in general i'm not fond of the inspecting the string to determine whether the math is correct
... in an ideal world every query would have it's own unit test class and it would have a
"testExplanation" method that would know exactly what structure (ie: how many sub-details)
to expect from an artificially constructed query instance.  the current approach of having
big "explanation" test classes that validate an explanation by comparing them to the scores
is a fairly big hack (and i say that as the guy that added it).

But i'm okay with the string comparisons as a "Convenience" to make it easier for us to test
the explanations of the core queries (since so many of them follow very clear patterns) ...
but i think we should avoid having any sort of expectation on the string for custom queries
(either that they match "product of" or that they match "other:")

my main concern is purely with giving people a way to do the same kind of Explanation testing
they could do before (that the root value equals the score) even if the details of their explanation
don't fit any of the patterns of the existing core queries.  (i'd hate for people to not even
do shallow testing of their Explanations just because we don't give them a method for doing
so)

this refactoring...
 
- makes verifyExplanations a public method in CheckHits that anyone can call
- adds a "deep" boolean option to verifyExplanations
- adds variants of CheckHits.checkExplanations and the ExplanationAsserter to make the "deep"
testing optional
- makes QueryUtils.checkExplanations use the "deep" option
- makes TestExplanations explicitly use deep testing

...at the moment, the "old" APIs default to deep==false but i'm on board with changing those
to "true" if you want to (in theory it's a non-backawards compatible API change, but since
it's in src/test we can probably get away with it).


> FilteredQuery explanation inaccuracy with boost
> -----------------------------------------------
>
>                 Key: LUCENE-903
>                 URL: https://issues.apache.org/jira/browse/LUCENE-903
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Search
>    Affects Versions: 2.2
>            Reporter: Doron Cohen
>            Assignee: Doron Cohen
>            Priority: Minor
>             Fix For: 2.2
>
>         Attachments: lucene-903.patch, lucene-903.patch
>
>
> The value of explanation is different than the product of its part if boost > 1.
> This is exposed after tightening the explanation check (part of LUCENE-446).

-- 
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


Mime
View raw message