Greets,
With the discussion on matching vs. scoring going on in other threads, I
thought it might be useful to revisit the rationale behind Lucy's Matcher
class.
Consider the following query:
foo AND NOT bar
The 'bar' term can *never* contribute to the score of a hit.
If a document contains 'bar', it does not match the query. Therefore, the
score of any hit will be solely derived from the 'foo' term and we should not
spend any effort calculating scores for 'bar'.
Lucy's Matcher class was introduced for situations like this -- where we need
to match but not score.
We used to have a "Scorer" class, derived from the Lucene class of the same
name. Matcher replaced it. Both classes had a Score() method, but while
Scorers *had* to implement Score(), for Matchers, implementing Score() is
optional.
Certain non-scoring Matchers do significantly less work than their scoring
counterparts -- particularly ORMatcher. Because we have the non-scoring
ORMatcher class available, queries like this perform better:
foo AND NOT (bar OR baz)
Lucy will use a non-scoring Matcher instead of a scoring Matcher whenever it
can.
Marvin Humphrey
