[Xapian-tickets] [Xapian] #216: Inconsistent return values for percentage weights

[Xapian]

#216: Inconsistent return values for percentage weights
---------------------+------------------------------------------------------
 Reporter:  richard  |        Owner:  olly     
     Type:  defect   |       Status:  assigned 
 Priority:  normal   |    Milestone:  1.0.11   
Component:  Matcher  |      Version:  SVN trunk
 Severity:  normal   |   Resolution:           
 Keywords:           |    Blockedby:           
 Platform:  All      |     Blocking:           
---------------------+------------------------------------------------------

Comment(by olly):

 Even with better bounds on the weight, we're rarely going to get the
 attained maximum equalling the bound.  And users are (quite reasonably)
 going to be surprised if 100% is not attained in most cases where a
 document matches all the terms in the query.  I don't think that approach
 is really workable.

 There isn't actually a lot of special case code for changes to percentage
 cutoff weights - that's all handled in a single if statement.  But it does
 feature quite a lot in the post-match adjusting of bounds, etc.

 Several people have seemed confused that two matches with the same
 percentage score don't count as having the same "relevance" so I think if
 we're going to give up on the current approach to percentages, we should
 just leave it to the user to calculate them if they want them.  Ironically
 this is how it used to be - the percentage calculating code was originally
 part of Omega.

 > We could also provide an interface which returns the term weights for
 each of the terms in a query (generally useful).

 Already exists - MSet::get_termweight(tname)!

 > they could get hold of the weight of the top document (either by asking
 for it to be included in the mset, if they're doing a relevance-sorted
 search [...])

 MSet::get_max_attained() should report that weight even if first > 0.

 Anyway, for the moment, the question is really if we should apply this
 patch for 1.0.11.  I'll try running some tests to see if the patch slows
 things down much.

-- 
Ticket URL: <http://trac.xapian.org/ticket/216#comment:18>
Xapian <http://xapian.org/>
Xapian