Hi, I'm not happy with the how scoring works either, it might be efficient though. I have been investigating the code for a while. Everything gets down to -Query (TermQuery, BooleanQuery, PhraseQuery etc.), -Inner class Weight in Query, -Similarity, -Scorer (TermScorer, BooleanScorer etc.) and interaction between them. Highly wired, back and forth method calls, query re-writings and so on.
I guess the main challenge is the Query and its derived classes. At the moment there is not entry point to dive and add your independent scoring models. (I hope I understood u guys right.) Murat, > On Mon, 2006-05-08 at 18:34 -0700, Otis Gospodnetic wrote: >> Hi, >> >> Not sure if people caught my question over on java-user@ >> about the possibility of eliminating floating point >> calculations from Lucene's scoring. Before I embark on this, >> I thought I'd ask: >> >> - Am I crazy? > > I'm all for a refactor of the scoring strategy. A single interface > attached to the index that takes care of it all. > >> Is this at all doable? > > Of course it is. > >> - Is this doable without forking and maintaining my own >> patches? > > That I doubt. I have no deep knowledge of the scoring mechanism, but the > current classes are heavily couple by how the boosts work. It would > require a huge amount of deprication. > > I would start with creating the new interface Index, inherited by > Directory or any other top level index implementation. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
