[GitHub] [lucene] 0roman commented on issue #12165: Integrating Apache Lucene into OSS-Fuzz
0roman commented on issue #12165: URL: https://github.com/apache/lucene/issues/12165#issuecomment-1439586559 > So I disagree with adding another fuzzing engine into Lucene. We have a library called "randomized-testing" which provides everything needed. Almost every test in Lucene has fuzzing included, the example above is just a very special one with a very wide range of components tested. Background: Lucene is using randomized testing since around 2012. Here is a talk from 2014 by @dweiss about it: https://2019.berlinbuzzwords.de/14/session/randomize-your-tests-and-it-will-blow-your-socks.html The talk was interesting, and Randomized Testing is a great contribution to explore complex boundary conditions and to find unexpected edge cases. However, the approach is quite different, which is fine because it fits your use case. Modern fuzzing is coverage-guided, which means the tested code is instrumented to give the fuzzer feedback about code coverage and further insights when executing a test case. The fuzzer then optimizes its mutations to generate inputs that maximize code coverage and pass checks in the code, such as string comparisons. Furthermore, [Jazzer](https://github.com/CodeIntelligenceTesting/jazzer) has specialized bug detectors that detect various classes of vulnerabilities like command injections, insecure deserialization, or attacker-controlled class loading. Based on that, I suggest we continue the OSS-Fuzz Onboarding without a maintainer. This way, you don't get any findings notifications from OSS-Fuzz. We will then receive finding reports from OSS-Fuzz, and we will make sure that we communicate interesting findings with you. You can still be added as maintainers afterward if you later see an added value in the findings you get. Thanks all for the contribution. -- 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
[GitHub] [lucene] MarcusSorealheis opened a new issue, #12166: `pointInPolygon` method in Tesselator is no longer used
MarcusSorealheis opened a new issue, #12166: URL: https://github.com/apache/lucene/issues/12166 ### Description The method is not found in the code base, and no tests fail upon its removal. -- 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.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
[GitHub] [lucene] dweiss commented on issue #12165: Integrating Apache Lucene into OSS-Fuzz
dweiss commented on issue #12165: URL: https://github.com/apache/lucene/issues/12165#issuecomment-1439747236 Sure, never enough bug reports. I keep wondering what does it report as a legitimate error/ problem if the patch catches a lot of what can be thrown from the inside, for example: https://github.com/google/oss-fuzz/pull/9772/files#diff-f3b3b0a611aa50e69c4823a63b6e760d6c607a635e584a14f836146bc49de48eR195-R196 -- 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
[GitHub] [lucene] cpoerschke opened a new issue, #12167: org.apache.lucene.search.grouping.TestGroupFacetCollector.testRandom fails reproducibly
cpoerschke opened a new issue, #12167: URL: https://github.com/apache/lucene/issues/12167 ### Description Please see https://lists.apache.org/thread/t5hgzv0q177nf8qqyz6h9qhhvwp366gp or https://jenkins.thetaphi.de/job/Lucene-9.x-Linux/8706 for full details. ``` Error Message: java.lang.IndexOutOfBoundsException: Range [0, 0 + 813) out of bounds for length 80 Stack Trace: java.lang.IndexOutOfBoundsException: Range [0, 0 + 813) out of bounds for length 80 at __randomizedtesting.SeedInfo.seed([173F7C2A08C39662:65735925B9A32011]:0) at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromIndexSize(Preconditions.java:82) at java.base/jdk.internal.util.Preconditions.checkFromIndexSize(Preconditions.java:361) at java.base/java.util.Objects.checkFromIndexSize(Objects.java:411) at java.base/java.nio.HeapByteBuffer.get(HeapByteBuffer.java:180) at org.apache.lucene.core@9.6.0-SNAPSHOT/org.apache.lucene.store.ByteBuffersDataInput.readBytes(ByteBuffersDataInput.java:155) at org.apache.lucene.core@9.6.0-SNAPSHOT/org.apache.lucene.store.ByteBuffersIndexInput.readBytes(ByteBuffersIndexInput.java:85) at org.apache.lucene.test_framework@9.6.0-SNAPSHOT/org.apache.lucene.tests.store.MockIndexInputWrapper.readBytes(MockIndexInputWrapper.java:148) at org.apache.lucene.core@9.6.0-SNAPSHOT/org.apache.lucene.codecs.lucene90.Lucene90DocValuesProducer$TermsDict.decompressBlock(Lucene90DocValuesProducer.java:1235) at org.apache.lucene.core@9.6.0-SNAPSHOT/org.apache.lucene.codecs.lucene90.Lucene90DocValuesProducer$TermsDict.next(Lucene90DocValuesProducer.java:1093) at org.apache.lucene.search.grouping.TermGroupFacetCollector$MV$SegmentResult.nextTerm(TermGroupFacetCollector.java:437) at org.apache.lucene.search.grouping.GroupFacetCollector.mergeSegmentResults(GroupFacetCollector.java:97) at org.apache.lucene.search.grouping.TestGroupFacetCollector.testRandom(TestGroupFacetCollector.java:429) ... ``` ### Gradle command to reproduce ./gradlew test --tests TestGroupFacetCollector.testRandom -Dtests.seed=173F7C2A08C39662 -Dtests.multiplier=3 -Dtests.locale=ru-KZ -Dtests.timezone=America/Mazatlan -Dtests.asserts=true -Dtests.file.encoding=UTF-8 -- 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.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
[GitHub] [lucene] gsmiller commented on a diff in pull request #12158: Clone the BytesRef[] values in KeywordField#newSetQuery
gsmiller commented on code in PR #12158:
URL: https://github.com/apache/lucene/pull/12158#discussion_r1114516161
##
lucene/core/src/java/org/apache/lucene/document/KeywordField.java:
##
@@ -169,7 +169,7 @@ public static Query newSetQuery(String field, BytesRef...
values) {
Objects.requireNonNull(field, "field must not be null");
Objects.requireNonNull(values, "values must not be null");
return new IndexOrDocValuesQuery(
-new TermInSetQuery(field, values), new
SortedSetDocValuesSetQuery(field, values));
+new TermInSetQuery(field, values), new
SortedSetDocValuesSetQuery(field, values.clone()));
Review Comment:
If the class was public, I would agree. Not cloning in the ctor though
leaves open the option of sharing a pre-sorted array across different query
implementations. Like what’s being explored in #12141. So I think I favor this
approach still, even though it is a bit trappy. At a minimum though, let me at
least add some javadoc to the ctor warning of this.
--
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
[GitHub] [lucene] uschindler commented on issue #12165: Integrating Apache Lucene into OSS-Fuzz
uschindler commented on issue #12165: URL: https://github.com/apache/lucene/issues/12165#issuecomment-1440293014 That is basically the same like: https://github.com/apache/lucene/blob/cce33b07e4f545ae4442c743c5023df1fb5d8fb9/lucene/analysis.tests/src/test/org/apache/lucene/analysis/tests/TestRandomChains.java#L761-L763 (although ours is more specific and also handles NULL because we forcefully pass NULL) -- 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
[GitHub] [lucene] nknize commented on a diff in pull request #12162: Add LatLonField class to index both LatLonPoint and LatLonDocValues
nknize commented on code in PR #12162:
URL: https://github.com/apache/lucene/pull/12162#discussion_r1114644266
##
lucene/core/src/java/org/apache/lucene/document/LatLonField.java:
##
@@ -0,0 +1,318 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.document;
+
+import static org.apache.lucene.geo.GeoEncodingUtils.decodeLatitude;
+import static org.apache.lucene.geo.GeoEncodingUtils.decodeLongitude;
+import static org.apache.lucene.geo.GeoEncodingUtils.encodeLatitude;
+import static org.apache.lucene.geo.GeoEncodingUtils.encodeLongitude;
+
+import java.io.IOException;
+import org.apache.lucene.geo.LatLonGeometry;
+import org.apache.lucene.geo.Point;
+import org.apache.lucene.geo.Polygon;
+import org.apache.lucene.index.DocValuesType;
+import org.apache.lucene.search.BooleanClause.Occur;
+import org.apache.lucene.search.BooleanQuery;
+import org.apache.lucene.search.FieldDoc;
+import org.apache.lucene.search.IndexOrDocValuesQuery;
+import org.apache.lucene.search.IndexSearcher;
+import org.apache.lucene.search.MatchAllDocsQuery;
+import org.apache.lucene.search.MatchNoDocsQuery;
+import org.apache.lucene.search.Query;
+import org.apache.lucene.search.SortField;
+import org.apache.lucene.search.TopFieldDocs;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.NumericUtils;
+
+/**
+ * An indexed location field for querying and sorting. If you need more
fine-grained control you can
+ * use {@link LatLonPoint} and {@link LatLonDocValuesField}.
+ *
+ * Finding all documents within a range at search time is efficient.
Multiple values for the same
+ * field in one document is allowed.
+ *
+ * This field defines static factory methods for common operations:
+ *
+ *
+ * {@link #newBoxQuery newBoxQuery()} for matching points within a
bounding box.
+ * {@link #newDistanceQuery newDistanceQuery()} for matching points
within a specified
+ * distance.
+ * {@link #newPolygonQuery newPolygonQuery()} for matching points within
an arbitrary polygon.
+ * {@link #newGeometryQuery newGeometryQuery()} for matching points
complying with a spatial
+ * relationship with an arbitrary geometry.
+ * {@link #newDistanceFeatureQuery newDistanceFeatureQuery()} for
returning points scored by
+ * distance to a specified location.
+ * {@link #nearest nearest()} for returning the nearest points from a
specified location.
+ * {@link #newDistanceSort newDistanceSort()} for ordering documents by
distance from a
+ * specified location.
+ *
+ *
+ * If you also need to store the value, you should add a separate {@link
StoredField} instance.
+ *
+ * WARNING: Values are indexed with some loss of precision from the
original {@code
+ * double} values (4.190951585769653E-8 for the latitude component and
8.381903171539307E-8 for
+ * longitude).
+ *
+ * @see LatLonPoint
+ * @see LatLonDocValuesField
+ */
+public class LatLonField extends Field {
Review Comment:
These class names are getting super inconsistent. Since this targets points
can we refactor this to `LatLonPointField` so as to not confuse general
`LatLonField` w/ `ShapeField`? I think this also makes it more consistent w/
`LatLonPointSortField`.
##
lucene/core/src/java/org/apache/lucene/geo/LatLonGeometry.java:
##
@@ -17,7 +17,23 @@
package org.apache.lucene.geo;
-/** Lat/Lon Geometry object. */
+/**
+ * Represents a unified view of the supported geometries on the earth's
surface. They can determine
+ * their spatial relationship against data indexed with {@link
+ * org.apache.lucene.document.LatLonField}, {@link
org.apache.lucene.document.LatLonPoint} and
+ * {@link org.apache.lucene.document.LatLonDocValuesField}.
+ *
+ * The supported geometries are:
+ *
+ *
+ * {@link Point}
+ * {@link Line}
+ * {@link Polygon}
+ * {@link Circle}
+ *
+ *
+ * @lucene.experimental
+ */
public abstract class LatLonGeometry extends Geometry {
Review Comment:
In the spirit of internal vs public facing APIs, is there a need to keep
this class public? This is a generic contract to enable `Circle`, `Line`,
`Point`, `Polygon`, `Rectangle` geometries to implement `Component2D`
comparisons. I do
[GitHub] [lucene] nknize commented on a diff in pull request #12162: Add LatLonField class to index both LatLonPoint and LatLonDocValues
nknize commented on code in PR #12162:
URL: https://github.com/apache/lucene/pull/12162#discussion_r1114644266
##
lucene/core/src/java/org/apache/lucene/document/LatLonField.java:
##
@@ -0,0 +1,318 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.document;
+
+import static org.apache.lucene.geo.GeoEncodingUtils.decodeLatitude;
+import static org.apache.lucene.geo.GeoEncodingUtils.decodeLongitude;
+import static org.apache.lucene.geo.GeoEncodingUtils.encodeLatitude;
+import static org.apache.lucene.geo.GeoEncodingUtils.encodeLongitude;
+
+import java.io.IOException;
+import org.apache.lucene.geo.LatLonGeometry;
+import org.apache.lucene.geo.Point;
+import org.apache.lucene.geo.Polygon;
+import org.apache.lucene.index.DocValuesType;
+import org.apache.lucene.search.BooleanClause.Occur;
+import org.apache.lucene.search.BooleanQuery;
+import org.apache.lucene.search.FieldDoc;
+import org.apache.lucene.search.IndexOrDocValuesQuery;
+import org.apache.lucene.search.IndexSearcher;
+import org.apache.lucene.search.MatchAllDocsQuery;
+import org.apache.lucene.search.MatchNoDocsQuery;
+import org.apache.lucene.search.Query;
+import org.apache.lucene.search.SortField;
+import org.apache.lucene.search.TopFieldDocs;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.NumericUtils;
+
+/**
+ * An indexed location field for querying and sorting. If you need more
fine-grained control you can
+ * use {@link LatLonPoint} and {@link LatLonDocValuesField}.
+ *
+ * Finding all documents within a range at search time is efficient.
Multiple values for the same
+ * field in one document is allowed.
+ *
+ * This field defines static factory methods for common operations:
+ *
+ *
+ * {@link #newBoxQuery newBoxQuery()} for matching points within a
bounding box.
+ * {@link #newDistanceQuery newDistanceQuery()} for matching points
within a specified
+ * distance.
+ * {@link #newPolygonQuery newPolygonQuery()} for matching points within
an arbitrary polygon.
+ * {@link #newGeometryQuery newGeometryQuery()} for matching points
complying with a spatial
+ * relationship with an arbitrary geometry.
+ * {@link #newDistanceFeatureQuery newDistanceFeatureQuery()} for
returning points scored by
+ * distance to a specified location.
+ * {@link #nearest nearest()} for returning the nearest points from a
specified location.
+ * {@link #newDistanceSort newDistanceSort()} for ordering documents by
distance from a
+ * specified location.
+ *
+ *
+ * If you also need to store the value, you should add a separate {@link
StoredField} instance.
+ *
+ * WARNING: Values are indexed with some loss of precision from the
original {@code
+ * double} values (4.190951585769653E-8 for the latitude component and
8.381903171539307E-8 for
+ * longitude).
+ *
+ * @see LatLonPoint
+ * @see LatLonDocValuesField
+ */
+public class LatLonField extends Field {
Review Comment:
These class names are getting super inconsistent. Since this targets points
can we refactor this to `LatLonPointField` so as to not confuse general
`LatLonField` w/ `ShapeField` w/ `LatLonShape` etc? I think this also makes it
more consistent w/ `LatLonPointSortField`.
--
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
[GitHub] [lucene] nknize commented on pull request #12162: Add LatLonField class to index both LatLonPoint and LatLonDocValues
nknize commented on PR #12162:
URL: https://github.com/apache/lucene/pull/12162#issuecomment-1440455711
> This PR doesn't have this, but I'm unsure what should be the canonical
representation of a geo point in stored fields.
@jpountz Thinking out loud here, would it make sense to add something like a
`StoredFieldCanonicalFormat` interface that offers `Object format(BytesRef
...` `Object format(long ...` methods? This way we could decide to store
LatLonPoint as an efficient integer encoded XY long value and provide standard
formatters like:
`LatLonPointStandardFormatter` - formats to standard lat, lon string
representation.
`LatLonPointJSONFormatter` - formats to the geojson standard string
representation.
`XYPointStandardFormatter` - formats to standard x, y string representation.
Of course we could keep things tidy by having something like
```java
public class LatLonPointStandardFormatter {
public static class JSON implements StoredFieldCanonicalFormat {
@override
public String format(BytesRef value) {
StringBuffer sb = ...
return sb.toString();
}
}
}
```
--
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
[GitHub] [lucene] kaivalnp commented on a diff in pull request #12160: Concurrent rewrite for KnnVectorQuery
kaivalnp commented on code in PR #12160:
URL: https://github.com/apache/lucene/pull/12160#discussion_r1114954874
##
lucene/core/src/java/org/apache/lucene/search/AbstractKnnVectorQuery.java:
##
@@ -73,17 +76,41 @@ public Query rewrite(IndexSearcher indexSearcher) throws
IOException {
.build();
Query rewritten = indexSearcher.rewrite(booleanQuery);
filterWeight = indexSearcher.createWeight(rewritten,
ScoreMode.COMPLETE_NO_SCORES, 1f);
+} else {
+ filterWeight = null;
}
-for (LeafReaderContext ctx : reader.leaves()) {
- TopDocs results = searchLeaf(ctx, filterWeight);
- if (ctx.docBase > 0) {
-for (ScoreDoc scoreDoc : results.scoreDocs) {
- scoreDoc.doc += ctx.docBase;
-}
- }
- perLeafResults[ctx.ord] = results;
-}
+TopDocs[] perLeafResults =
+reader.leaves().stream()
+.map(
+ctx -> {
+ Supplier supplier =
+ () -> {
+try {
+ TopDocs results = searchLeaf(ctx, filterWeight);
+ if (ctx.docBase > 0) {
+for (ScoreDoc scoreDoc : results.scoreDocs) {
+ scoreDoc.doc += ctx.docBase;
+}
+ }
+ return results;
+} catch (Exception e) {
+ throw new CompletionException(e);
+}
+ };
+
+ Executor executor = indexSearcher.getExecutor();
+ if (executor == null) {
+return CompletableFuture.completedFuture(supplier.get());
+ } else {
+return CompletableFuture.supplyAsync(supplier, executor);
Review Comment:
Thanks for the input! This was helpful in reducing latency from thread
switching further
--
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
[GitHub] [lucene] kaivalnp commented on pull request #12160: Concurrent rewrite for KnnVectorQuery
kaivalnp commented on PR #12160: URL: https://github.com/apache/lucene/pull/12160#issuecomment-1440817461 I ran some benchmarks as well (Columns 2-4 are latency in ms): ### enwiki (topK = 100, segment count = 10) | recall | Sequential | CompletableFuture | SliceExecutor | nDoc | fanout | maxConn | beamWidth | |-|-|-|-|-|-|-|-| | 0.995 | 1.00 | 0.31 | 0.32 | 1 | 0 | 16 | 32 | | 0.998 | 1.33 | 0.37 | 0.38 | 1 | 50 | 16 | 32 | | 0.998 | 1.09 | 0.31 | 0.32 | 1 | 0 | 16 | 64 | | 0.999 | 1.43 | 0.37 | 0.40 | 1 | 50 | 16 | 64 | | 0.995 | 0.99 | 0.29 | 0.31 | 1 | 0 | 32 | 32 | | 0.998 | 1.31 | 0.35 | 0.37 | 1 | 50 | 32 | 32 | | 0.998 | 1.05 | 0.29 | 0.31 | 1 | 0 | 32 | 64 | | 0.999 | 1.40 | 0.36 | 0.38 | 1 | 50 | 32 | 64 | | 0.987 | 1.73 | 0.39 | 0.41 | 10 | 0 | 16 | 32 | | 0.992 | 2.37 | 0.49 | 0.52 | 10 | 50 | 16 | 32 | | 0.993 | 1.92 | 0.41 | 0.44 | 10 | 0 | 16 | 64 | | 0.996 | 2.57 | 0.53 | 0.56 | 10 | 50 | 16 | 64 | | 0.987 | 1.74 | 0.39 | 0.41 | 10 | 0 | 32 | 32 | | 0.992 | 2.34 | 0.50 | 0.52 | 10 | 50 | 32 | 32 | | 0.994 | 1.98 | 0.42 | 0.45 | 10 | 0 | 32 | 64 | | 0.997 | 2.68 | 0.54 | 0.57 | 10 | 50 | 32 | 64 | | 0.971 | 2.76 | 0.56 | 0.46 | 100 | 0 | 16 | 32 | | 0.982 | 3.75 | 0.72 | 0.60 | 100 | 50 | 16 | 32 | | 0.985 | 3.26 | 0.61 | 0.55 | 100 | 0 | 16 | 64 | | 0.991 | 4.24 | 0.80 | 0.64 | 100 | 50 | 16 | 64 | | 0.973 | 2.80 | 0.58 | 0.51 | 100 | 0 | 32 | 32 | | 0.983 | 3.88 | 0.75 | 0.62 | 100 | 50 | 32 | 32 | | 0.986 | 3.33 | 0.65 | 0.57 | 100 | 0 | 32 | 64 | | 0.992 | 4.57 | 0.85 | 0.70 | 100 | 50 | 32 | 64 | ### enwiki (topK = 100, segment count = 5) | recall | Sequential | CompletableFuture | SliceExecutor | nDoc | fanout | maxConn | beamWidth | |-|-|-|-|-|-|-|-| | 0.991 | 0.59 | 0.28 | 0.23 | 1 | 0 | 16 | 32 | | 0.996 | 0.84 | 0.34 | 0.27 | 1 | 50 | 16 | 32 | | 0.997 | 0.62 | 0.28 | 0.23 | 1 | 0 | 16 | 64 | | 0.999 | 0.89 | 0.35 | 0.31 | 1 | 50 | 16 | 64 | | 0.991 | 0.60 | 0.26 | 0.21 | 1 | 0 | 32 | 32 | | 0.995 | 0.81 | 0.35 | 0.26 | 1 | 50 | 32 | 32 | | 0.997 | 0.65 | 0.27 | 0.22 | 1 | 0 | 32 | 64 | | 0.999 | 0.86 | 0.36 | 0.29 | 1 | 50 | 32 | 64 | | 0.978 | 0.97 | 0.36 | 0.29 | 10 | 0 | 16 | 32 | | 0.987 | 1.29 | 0.47 | 0.38 | 10 | 50 | 16 | 32 | | 0.989 | 1.08 | 0.40 | 0.31 | 10 | 0 | 16 | 64 | | 0.994 | 1.46 | 0.52 | 0.41 | 10 | 50 | 16 | 64 | | 0.977 | 0.98 | 0.36 | 0.31 | 10 | 0 | 32 | 32 | | 0.987 | 1.32 | 0.49 | 0.37 | 10 | 50 | 32 | 32 | | 0.989 | 1.14 | 0.40 | 0.34 | 10 | 0 | 32 | 64 | | 0.994 | 1.55 | 0.56 | 0.42 | 10 | 50 | 32 | 64 | | 0.957 | 1.54 | 0.57 | 0.45 | 100 | 0 | 16 | 32 | | 0.972 | 2.07 | 0.70 | 0.60 | 100 | 50 | 16 | 32 | | 0.976 | 1.71 | 0.61 | 0.53 | 100 | 0 | 16 | 64 | | 0.985 | 2.33 | 0.76 | 0.65 | 100 | 50 | 16 | 64 | | 0.959 | 1.58 | 0.57 | 0.45 | 100 | 0 | 32 | 32 | | 0.974 | 2.17 | 0.73 | 0.63 | 100 | 50 | 32 | 32 | | 0.978 | 1.88 | 0.65 | 0.53 | 100 | 0 | 32 | 64 | | 0.987 | 2.57 | 0.83 | 0.69 | 100 | 50 | 32 | 64 | ### enwiki (topK = 100, segment count = 1) | recall | Sequential | CompletableFuture | SliceExecutor | nDoc | fanout | maxConn | beamWidth | |-|-|-|-|-|-|-|-| | 0.941 | 0.23 | 0.25 | 0.21 | 1 | 0 | 16 | 32 | | 0.970 | 0.24 | 0.27 | 0.25 | 1 | 50 | 16 | 32 | | 0.965 | 0.19 | 0.23 | 0.20 | 1 | 0 | 16 | 64 | | 0.984 | 0.27 | 0.28 | 0.28 | 1 | 50 | 16 | 64 | | 0.941 | 0.17 | 0.20 | 0.17 | 1 | 0 | 32 | 32 | | 0.970 | 0.23 | 0.27 | 0.24 | 1 | 50 | 32 | 32 | | 0.966 | 0.20 | 0.22 | 0.20 | 1 | 0 | 32 | 64 | | 0.985 | 0.26 | 0.29 | 0.28 | 1 | 50 | 32 | 64 | | 0.909 | 0.26 | 0.29 | 0.28 | 10 | 0 | 16 | 32 | | 0.945 | 0.36 | 0.38 | 0.38 | 10 | 50 | 16 | 32 | | 0.944 | 0.30 | 0.32 | 0.31 | 10 | 0 | 16 | 64 | | 0.969 | 0.42 | 0.43 | 0.43 | 10 | 50 | 16 | 64 | | 0.914 | 0.28 | 0.30 | 0.29 | 10 | 0 | 32 | 32 | | 0.948 | 0.37 | 0.43 | 0.44 | 10 | 50 | 32 | 32 | | 0.949 | 0.31 | 0.35 | 0.31 | 10 | 0 | 32 | 64 | | 0.972 | 0.41 | 0.48 | 0.43 | 10 | 50 | 32 | 64 | | 0.870 | 0.35 | 0.38 | 0.36 | 100 | 0 | 16 | 32 | | 0.911 | 0.48 | 0.51 | 0.50 | 100 | 50 | 16 | 32 | | 0.913 | 0.40 | 0.43 | 0.42 | 100 | 0 | 16 | 64 | | 0.945 | 0.55 | 0.59 | 0.57 | 100 | 50 | 16 | 64 | | 0.881 | 0.38 | 0.43 | 0.39 | 100 | 0 | 32 | 32 | | 0.919 | 0.52 | 0.57
[GitHub] [lucene] MarcusSorealheis commented on pull request #12162: Add LatLonField class to index both LatLonPoint and LatLonDocValues
MarcusSorealheis commented on PR #12162: URL: https://github.com/apache/lucene/pull/12162#issuecomment-1440954007 > I don't care about use of it for shapes since only 0.001% of users give a crap about shapes that's correct, today. -- 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
