[ 
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

Just adding one more print to the new distance test to make it more debuggable.

It shows a good fail like this which reproduces easily:
{noformat}
   [junit4] Started J0 PID(21772@localhost).
   [junit4] Suite: org.apache.lucene.spatial.geopoint.search.TestGeoPointQuery
   [junit4]   1> center: (-2.6859204112252826,-126.5501794954457), 
radius=1.933955591025525E7
   [junit4]   1> 0: (-37.8248053137213,30.965997129678726), 
distance=1.4967104936764924E7
   [junit4]   1> 1: (-88.12955391593277,-49.35365941375494), 
distance=9673775.807110526
   [junit4]   1> 2: (64.47744741104543,-10.247774831950665), 
distance=1.1518639744313335E7
   [junit4]   1> 3: (-19.651501905173063,16.937049888074398), 
distance=1.5335235632819101E7
   [junit4]   1> 4: (38.89845754019916,163.5567674227059), 
distance=8487195.64357184
   [junit4]   1> 5: (-2.730920696631074,-125.4338058270514), 
distance=124236.35394072857
   [junit4]   1> 6: (-9.463954903185368,-119.37913874164224), 
distance=1094829.0184535114
   [junit4]   1> 7: (2.784616006538272,58.78787197172642), 
distance=1.9443855071787946E7
   [junit4]   1> 8: (-76.14117253571749,151.79019374772906), 
distance=9506656.192332761
   [junit4]   1> 9: (66.5075888670981,1.8173518404364586), 
distance=1.1896270113358853E7
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeoPointQuery 
-Dtests.method=testRandomDistance -Dtests.seed=BFDD43F3DB3D2FDC 
-Dtests.locale=zh -Dtests.timezone=Pacific/Pago_Pago -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 12.2s | TestGeoPointQuery.testRandomDistance <<<
   [junit4]    > Throwable #1: java.lang.AssertionError: expected:<{0, 1, 2, 3, 
4, 5, 6, 8, 9}> but was:<{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}>
{noformat}

So document 7 is really too far away, but gets wrongly included in the result. 
I can probably debug it from here...

> 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, LUCENE-7127.patch, 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

Reply via email to