dsmiley commented on issue #1303: LUCENE-9114: Improve ValueSourceScorer's Default Cost Implementation URL: https://github.com/apache/lucene-solr/pull/1303#issuecomment-593151099 Lets add the following test to TestFunctionRangeQuery: ``` @Test public void testTwoRangeQueries() throws IOException { Query rq1 = new FunctionRangeQuery(INT_VALUESOURCE, 2, 4, true, true); Query rq2 = new FunctionRangeQuery(INT_VALUESOURCE, 8, 10, true, true); Query bq = new BooleanQuery.Builder() .add(rq1, BooleanClause.Occur.SHOULD) .add(rq2, BooleanClause.Occur.SHOULD) .build(); ScoreDoc[] scoreDocs = indexSearcher.search(bq, N_DOCS).scoreDocs; expectScores(scoreDocs, 10, 9, 8, 4, 3, 2); } ``` This'll stack-overflow on your first implementation. > Maybe have FunctionValues expose an abstract cost() method, have all FV derivatives implement it and then simply let VSC's matchCost use that method? Yes; we certainly need the FV to provide the cost; the TPI.matchCost should simply look it up. By the FV (or VS) having a cost, it then becomes straight-forward for anyone's custom FV/VS to specify what their cost is. It's debatable wether this cost should be on the VS vs FV.
---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
