shatejas commented on PR #13407: URL: https://github.com/apache/lucene/pull/13407#issuecomment-2228981677
@benwtrent > Its not necessary and without it things are simpler (less code and less API features is a good thing by itself) This shouldn't come at the cost of not providing the core parameters of a widely used algorithm > Leaking the internal storage mechanism in the query API directly is frustrating. This is more of a compute mechanism with ability to improve recall and not the storage mechanism, it leverages how its stored but not a storage mechanism in itself. Not providing those is limiting the users their ability to improve the results. Forcing them to have a work around (in this case bumping up the `k`) is even more frustrating as there will be some amount of logic that needs to added on each client end. @msokolov Thanks for linking those! Most of the discussion around removing the parameter is based on the fact that its in on an abstract layer which cannot be reused. I do believe that there is a possibility of having an implementation which can make it abstract enough for other algorithms and provide flexibility to have parameters. It doesn't have to be either-or. To conclude this discussion, I wouldn't want to introduce a non-optimal way to accomplish something when it isn't a blocker. The optimal way unfortunately will require significant refactor to accomplish both the goals. Closing this for now -- 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
