dsmiley commented on PR #14433: URL: https://github.com/apache/lucene/pull/14433#issuecomment-2777428910
Thanks for the historical context! I can definitely add more docs; I started with the bare minimum. Definitely need to emphasize a dependency on the default `computeNorm` formula! That documentation should also mention `discountOverlaps`. I'm not married to the name; do you have ideas? If it has "term" in the name, people may be confused that the argument to the method is a term but it's just the field. Something like termLength would be confusing -- the length of what term? (no). Ultimately I like "position length" because it is the number of positions, the length, of the field. Using "length" in some way, I think, is likely to resonate with people on its use. Then code shows how EMPTY is needed. It mirrors the same for DoubleValues.EMPTY. I found it odd/surprising that it did _not_ exist, and it's a common pattern I expect in Lucene. Is polymorphism really an issue here? I anticipated possible doubt as to the placement of this. It's not a whole-index statistic, but it is related to the others here for there use in relevancy. BTW I could imagine another interesting/useful utility method that takes a string (which is a query in practice), applies the _index_ analyzer, counts the positions, and finally produces a constant and then build a constant LongValueSource from that. This would allow doing ~exact-ish matching of a query when combined with a phrase query targeting the field. Maybe nothing is needed at a Lucene level; it's a small amount of code that could be added at a higher level (like Solr). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
