ChrisHegarty commented on code in PR #13370:
URL: https://github.com/apache/lucene/pull/13370#discussion_r1602135463
##########
lucene/core/src/java/org/apache/lucene/codecs/hnsw/DefaultFlatVectorScorer.java:
##########
@@ -109,6 +109,12 @@ public float score(int node) throws IOException {
};
}
+ @Override
+ public float score(int firstOrd, int secondOrd) throws IOException {
+ return similarityFunction.compare(
+ vectors1.vectorValue(firstOrd), vectors2.vectorValue(secondOrd));
Review Comment:
ha!! this is what I originally thought too, until I added a test case for
this recently, see
https://github.com/apache/lucene/blob/b1d3c086194f247b7d77352b1f105e4ae829d2e8/lucene/core/src/test/org/apache/lucene/codecs/hnsw/TestFlatVectorScorer.java#L80
Since neither scoreSuppliers or scorers are thread safe, then their
operation has to be considered in a single-threaded model. For example: if one
where to do this:
```
ss.scorer(ord1).score(ord2)
ss.scorer(ord3).score(ord4)
```
Then vectors1 is used to retrieve the value of, first ord1, then ord3. No
issue (other than the internal cache-of-one will be invalidated when ord3 is
retrieved). This is already the case. What this PR proposes is to support a
model similar to:
```
ss.score(ord1, ord2)
ss.score(ord3, ord4)
```
, which simply avoids the creation of two scorer instances. Make sense, or
maybe I've missed your point?
Additionally, I added a few small javadoc comments to help clarify the usage.
--
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
