[
https://issues.apache.org/jira/browse/LUCENE-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16144754#comment-16144754
]
ASF subversion and git services commented on LUCENE-7942:
---------------------------------------------------------
Commit 4f6cfd6d50df14f9f03ff3bd6b2b3a49c00f4dc8 in lucene-solr's branch
refs/heads/branch_6x from [[email protected]]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4f6cfd6 ]
LUCENE-7942: Explicitly require conversion to 'aggregation' form before
aggregating distances, plus require a conversion back. This is more efficient
than my initial commit for this ticket, since sqrt values will be cached for
path segments, and will not need to be recomputed.
> For Geo3d paths, aggregating distance values using "+" is not adequate for
> squared distances
> --------------------------------------------------------------------------------------------
>
> Key: LUCENE-7942
> URL: https://issues.apache.org/jira/browse/LUCENE-7942
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
> Reporter: Karl Wright
> Assignee: Karl Wright
> Fix For: 6.7, master (8.0), 7.1
>
>
> The GeoStandardPath object aggregates distances segment by segment using
> simple addition. For some kinds of Distance computations, though, addition
> is not an adequate way to do this. The xxxSquaredDistance computations, for
> example, do not produce true squared distances but rather a distance metric
> that is a combination of both squared and linear.
> I propose adding support in Distance for aggregation, which would allow
> distance calculators to compute an accurate distance (at some computational
> cost) instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
