[ 
https://issues.apache.org/jira/browse/LUCENE-7166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222858#comment-15222858
 ] 

ASF subversion and git services commented on LUCENE-7166:
---------------------------------------------------------

Commit f8ea8b855e43fc0a2fa434ab8c366de810047c8f in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f8ea8b8 ]

LUCENE-7166: fix quantization bugs in LatLonPoint and GeoPointField, remove 
test leniency

Squashed commit of the following:

commit 83c0f9b6158495b8b3d7108059a23bdf38e0f7f3
Author: Robert Muir <rm...@apache.org>
Date:   Fri Apr 1 23:33:29 2016 -0400

    fix geopoint

commit 97ebd2de516e61c236542fb2fb28e71cf6bdc403
Author: Robert Muir <rm...@apache.org>
Date:   Fri Apr 1 23:06:05 2016 -0400

    fix test and LatLonPoint encoding/quantization/box queries


> fix quantization bugs in LatLonPoint and GeoPointField, remove test leniency
> ----------------------------------------------------------------------------
>
>                 Key: LUCENE-7166
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7166
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Robert Muir
>         Attachments: LUCENE-7166.patch
>
>
> Currently a few remaining tests (around newRectQuery) are lenient and 
> quantize the query rectangles. This is masking several bugs:
> 1. Both LatLonPoint and GeoPointField's bbox queries quantize their endpoints 
> incorrectly at query-time, which can e.g. cause it to bring in false positive 
> results
> 2. Tests have always been lenient about this (either by using epsilons or 
> incorrectly quantizing the query rectangles in tests), hiding the above. 
> 3. Both LatLonPoint and GeoPointField still have rounding issues at 
> quantization. For very special values they do not always consistently round 
> in one direction.
> 4. Random encoding tests will never find the above issue, hiding it. This is 
> because you need very special double values that the current stuff (e.g. 
> {{-180 + 360.0 * random().nextDouble()}} will never find!).



--
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