[jira] Commented: (LUCENE-903) FilteredQuery explanation inaccuracy with boost
[ https://issues.apache.org/jira/browse/LUCENE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501067 ] Hoss Man commented on LUCENE-903: - I have some reservations about this patch. I think it's fine to set as a goal that all core query classes should have Explanations where the description accurately describes a mathematical calculation that can be performed on the details to arrive at the value of the Explanation -- which is easy to do since we have the luxury of changing the CHeckHits class to suit our needs anytime we add a new class that has a more interesting mathematical calculation then we can current account for. But we should also try to maintain CheckHIts as a reusable class that clients can use to run basic sanity tests on their own custom Query classes, and holding them to the same standard (when they can't easily modify the string pattern rules in CheckHits) doesn't seem fair. lemme try to refactor the current patch a bit so that the deep Explanation testing is optional (and used by the core tests) 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-903) FilteredQuery explanation inaccuracy with boost
[ https://issues.apache.org/jira/browse/LUCENE-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501074 ] Doron Cohen commented on LUCENE-903: holding them to the same standard (when they can't easily modify the string pattern rules in CheckHits) doesn't seem fair. lemme try to refactor the current patch a bit so that the deep Explanation testing is optional (and used by the core tests) I agree (and pointed that) the deep explanation test is imperfect in this regard. But it seems to me that it is the benefit of new query writers to have their new queries explanations tested as thorough as possible. So I am not sure that disabling this test by default (for non core queries) is the right thing to do. How do you feel about adding an escape way, allowing one to specify that a certain (part of an) explanation is not to be checked in this manner? I see two immediate ways to add this: - by the explanation text: if the description starts with other: the explanation is not subject to this deep check - by api: adding a property to Explanation class - disabledDeepCheck - false by default - allows new unique queries to deliberately disable this deep test. 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
