0.1.0-PRE38

• Fixed docs for running nearest neighbors query on a filtered subset of documents.
  The original suggestion to use a bool query results in evaluating all docs.
  The correct way to do it is to use a standard query with a rescorer.

0.1.0-PRE37

• Fixed null pointer exception which was happening when running queries after deleting some vectors.

0.1.0-PRE36

• Fixed null pointer exception which was happening when running queries after deleting some vectors.

0.1.0-PRE35

• Removed guava dependency from models project.
• Some internal cleanup.

0.1.0-PRE34

• More memory-efficient implementation of Python ElastiknnModel.fit method. Uses an iterator over the vectors instead of a list of the vectors.

0.1.0-PRE33

• Renamed parameter r in L2Lsh mapping to w, which is more appropriate and common for "width".
• Updates and fixes in the Python client based on usage for ann-benchmarks. Mainly adding/fixing data classes in elastiknn.api.

0.1.0-PRE32

• Updated MatchHashesAndScoreQuery so that approximate queries will emit no more than candidates doc IDs.
  This slightly decreases recall, since the previous implementation could emit > candidates IDs.

0.1.0-PRE31

• Support sparse bool query vectors with unsorted true indices.

0.1.0-PRE30

• Added new submodules which can be used without Elasticsearch:
  • com.klibisz.elastiknn:models contains exact and approximate similarity models, all in Java with minimal dependencies.
  • com.klibisz.elastiknn:lucene contains the custom Lucene queries and some Lucene-related utilities used by Elastiknn.
  • com.klibisz.elastiknn:api4s_2.12 contains Scala case classes and codecs representing the Elastiknn JSON API.
  • com.klibisz.elastiknn:client-elastic4s_2.12 contains the Elastiknn Scala client.

0.1.0-PRE29

• Switched to less-naive implementation of multiprobe L2 LSH. Specifically, uses algorithm 1 from Qin, et. al. to generate
  perturbation sets lazily at query time instead of generating them exhaustively. This does not use the estimated
  scoring optimization from that paper.
• Performance optimizations for approximate queries. Specifically using a faster sorting method to sort the hashes before
  retrieving matching docs from the shard.