[
https://issues.apache.org/jira/browse/LUCENE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385546#comment-17385546
]
Michael Sokolov commented on LUCENE-10015:
------------------------------------------
Yes, let's keep the similarity function! It's an essential component of a
metric space (or non-metric space), and is implicit in the vectors: you can't
just use any arbitrary function, as Julie says.
It makes my life a little more complicated that we removed NONE since it
simplifies schema management at the next level. You can define a schema with
fields of type vector, and then separately say whether you want to support KNN
search for such a field. We used to support such vectors with BinaryDocValues,
and then switched to this impl. Now we will have to switch back. But I guess we
are now saying these fields are *only* to be be used for NN search, so it makes
sense, and I won't block it.
> Remove VectorValues.SimilarityFunction, remove NONE
> ---------------------------------------------------
>
> Key: LUCENE-10015
> URL: https://issues.apache.org/jira/browse/LUCENE-10015
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Robert Muir
> Priority: Blocker
> Fix For: 9.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This stuff is HNSW-implementation specific. It can be moved to a codec
> parameter.
> The NONE option should be removed: it just makes the codec more complex.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
