[
https://issues.apache.org/jira/browse/LUCENE-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-7127:
--------------------------------
Attachment: LUCENE-7127.patch
Here's my patch. Now GeoPoint and LatLonPoint are tested the exact same way
(they are already generally returning exact same answers on any reasonable
dataset, modulo bugs).
Tests generally pass but there are sporatic corner case failures: e.g.
{noformat}
[junit4] Started J0 PID(16923@localhost).
[junit4] Suite:
org.apache.lucene.spatial.geopoint.search.TestLegacyGeoPointQuery
[junit4] 1> T1: id=1623 should not match but did
[junit4] 1> small=false query=GeoPointDistanceQuery: field=point:
Center: [-78.95940156653523,-61.08293957076967] Distance: 5705904.858922883
meters] docID=1623
[junit4] 1> lat=-67.50789809972048 lon=95.3347154147923
[junit4] 1> deleted?=false
[junit4] 1> docID=1623 centerLon=-78.95940156653523
centerLat=-61.08293957076967 pointLon=95.3347154147923
pointLat=-67.50789809972048 distanceMeters=5715359.332616319 vs
radiusMeters=5705904.858922883
[junit4] 2> ??? 22, 2016 7:36:32 ?
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
[junit4] 2> WARNING: Uncaught exception in thread:
Thread[T1,5,TGRP-TestLegacyGeoPointQuery]
[junit4] 2> java.lang.AssertionError: wrong hit (first of possibly more)
[junit4] 2> at
__randomizedtesting.SeedInfo.seed([2E99F05640D677C6]:0)
[junit4] 2> at org.junit.Assert.fail(Assert.java:93)
[junit4] 2> at
org.apache.lucene.spatial.util.BaseGeoPointTestCase$VerifyHits.test(BaseGeoPointTestCase.java:553)
[junit4] 2> at
org.apache.lucene.spatial.util.BaseGeoPointTestCase$2._run(BaseGeoPointTestCase.java:772)
[junit4] 2> at
org.apache.lucene.spatial.util.BaseGeoPointTestCase$2.run(BaseGeoPointTestCase.java:637)
[junit4] 2>
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestLegacyGeoPointQuery -Dtests.method=testRandomWithThreads
-Dtests.seed=2E99F05640D677C6 -Dtests.locale=ar-EG
-Dtests.timezone=Antarctica/Syowa -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
{noformat}
I will start to try to debug through some of these, see if i can get things
happy.
> remove epsilon-based testing from lucene/spatial
> ------------------------------------------------
>
> Key: LUCENE-7127
> URL: https://issues.apache.org/jira/browse/LUCENE-7127
> Project: Lucene - Core
> Issue Type: Test
> Reporter: Robert Muir
> Attachments: LUCENE-7127.patch
>
>
> Currently, the random tests here allow a TOLERANCE and will fail if the error
> exceeds. But this is not fun to debug! It also keeps the door wide open for
> bugs to creep in.
> Alternatively, we can rework the tests like we did for sandbox/ points. This
> means the test is aware of the index-time quantization and so it can demand
> exact answers.
> Its more difficult at first, because even floating point error can cause a
> failure. It requires us to maybe work through corner cases/rework
> optimizations. If any epsilons must be added, they can be added to the
> optimizations themselves (e.g. bounding box) instead of the user's result.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
