lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <>
Subject Re: Explaining a filter; Scorer extending Matcher;
Date Tue, 23 May 2006 07:24:34 GMT
On Monday 22 May 2006 23:43, Chris Hostetter wrote:
> : In case Explanation is also to explain what a Filter does, it would need 
> : have both a match flag and a score value.
> that's a good point, i hadn't considered hte possibility of "explaining"
> filters much ... but there's no reason why the "valueO 'f an explanation
> couldn't be an optional part of the explanation as well (ie: migrate from
> float to Float when adding the "Boolean match" so that future Explanation
> instances (of Filters) can say they match without claiming a particular
> score (or "faking it" with some magic float value)
> : At the moment I'm trying to implement filters by refactoring Scorer to 
have an
> : abstract superclass Matcher that could also become a superclass for filter
> : implementations (instead of DocNrSkipper).
> :
> : This Matcher class has all methods of Scorer that are not using score
> : values: doc(), next(), skipTo(docNr).
> : Any thoughts on whether such a Matcher would be preferable to
> : a DocNrSkipper that only has this method:
> :   int nextDocNr(int docNr)
> (I'm very ammused by this question, you'll see why in a second)
> I am 100% on board with the "Matcher" API you are describing ... but i
> think it might make more sense as an interface, perhaps called
> "DocIterator", that way even TermDocs could impliment it ...
> 	:)

Well, I was about to add a reference to that thread at the
issue on compact sparse filters. The current patch there is
just the result of me trying to get something in that direction
to actually work, after mostly forgetting some of the "details"
of that thread.

I'll repeat the DocIterator from that thread:

     public interface DocIterator { 
         public int doc(); 
         public boolean next(); 
         public boolean skipTo(int target); 
to come to my question: should that interface should also have an
explain(int docNr) method?
When so, it does more than iterating, so it might even be called Matcher.
Or would both DocIterator and Matcher be useful?

I don't know whether interfaces or abstract classes would be better for this.

Paul Elschot

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message