Thanks for the review David!
LMDirichletSimilarity has a mu-less constructor. Maybe we could avoid defining a constant in two places if we used that? E.g.
Same goes for H3 and Z.
+1, I think it would be good (though probably unavoidable for e.g. BM25's (k1, b) to do it this way if we want to provide default parameters.
Alternative, another idea would be for all 'parametric' models to require the parameter? Then in the "still-to-be-written" test config
that tests all these sims, we would just have good default parameters specified? Part of me likes this solution: if you are using a parametric
model then it requires you to think about it?
Wouldn't it be good if we could instantiate custom classes via reflection?
We could add this, e.g. if the parameter doesnt match any of the supplied names. But i started thinking about this, say I created NormalizationRob,
and it wants a bunch of parameters... at the end of the day for practical purposes a user could just make their own simple factory that uses
I(F)BRob(2.3, 4.5, 6.99) or whatever they wanted, because I think the intent here is to support all of lucene-core's capabilities?
Its still pluggable in the sense someone can always make their own factory for their custom stuff.
I don't know the Lucene/Solr conventions for line length. There are some rather long lines in IB and DFR, but maybe its not a problem?
Yeah maybe especially for the javadocs, but we can probably re-arrange these.