[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519968#comment-17519968
]
Matt Juntunen edited comment on GEOMETRY-146 at 4/9/22 11:45 AM:
-----------------------------------------------------------------
>From a previous response...
bq. You intentionally hid the internal implementation of PointMap, yet the
"near"/"far" methods make one assume that such an implementation must support
specific iteration "modes"; hence I'm feeling uncomfortable with the
(apparent?) inconsistency, at the "public" level.
Yes, I've made the _near/far_ concepts part of the {{PointMap/Set}} interfaces.
I don't see how this produces any inconsistency. The interfaces describe the
methods that must be available and it is up to the implementations on how they
accomplish that.
bq. For example, from your answers above, I seem to understand that PointMap
and DistanceOrdering are tightly coupled;
I wouldn't say they're "tightly coupled" since they are interfaces; more like
they are closely related.
bq. one wonders: "nearest"/farthest to what? The reference point is
"out-of-scope" (so to speak)...
Yes, intentionally so. The {{DistanceOrdering}} interface defines methods for
accessing a particular subset of the points. It does not answer the question of
what is selected. This is the separation of the _what_ and the _how_ that we
mentioned previously. I could easily picture using this interface in the future
for Euclidean 2D and 3D to access points in order of distance from a line. If
{{DistanceOrdering}} defined the target of the distance computation, this would
be more complicated.
bq. why not make the coupling obvious, as in
I don't see any added benefit in that API. Rather, it doesn't seem as
expressive or readable. Ex:
{code:java}
// I find this ...
Iterable<Entry<P, V>> it = map.entriesFrom(pt).nearToFar();
// easier to read than this ...
Iterable<Entry<P, V>> it = map.entries(pt, DistanceOrdering.ASCENDING);
{code}
bq. I'm also a bit wary of only returning a StreamableIterator interface rather
than e.g. a List, because in the potential use case which I have in mind, the
selected points are rather few (as compared to the map's contents) and the
number of them should be known in order to, for example, compute an
interpolation of the associated values.
{{StreamableIterator}} is returned instead of {{List}} for two reasons:
1. The total number of elements within the area of interest is generally not
known until all of the elements are enumerated. The main exception to this is
when the entire map/set is being iterated.
2. The list could be quite large so it should be up to the caller on whether or
not to incur the cost of allocation.
If a list is needed, it is a one-liner:
{code:java}
List<P> closePts = set.withinDistance(p,
dist).nearToFar().stream().collect(Collectors.toList());
{code}
was (Author: mattjuntunen):
>From a previous response...
bq. You intentionally hid the internal implementation of PointMap, yet the
"near"/"far" methods make one assume that such an implementation must support
specific iteration "modes"; hence I'm feeling uncomfortable with the
(apparent?) inconsistency, at the "public" level.
Yes, I've made the _near/far_ concepts part of the {{PointMap/Set}} interfaces.
I don't see how this produces any inconsistency. The interfaces describe the
methods that must be available and it is up to the implementations on how they
accomplish that.
bq. For example, from your answers above, I seem to understand that PointMap
and DistanceOrdering are tightly coupled;
I wouldn't say they're "tightly coupled" since they are interfaces; more like
they are closely related.
bq. one wonders: "nearest"/farthest to what? The reference point is
"out-of-scope" (so to speak)...
Yes, intentionally so. The {{DistanceOrdering}} interface defines methods for
accessing a particular subset of the points. It does not answer the question of
what is selected. This is the separation of the _what_ and the _how_ that we
mentioned previously. I could easily picture using this interface in the future
for Euclidean 2D and 3D to access points in order of distance from a line. If
{{DistanceOrdering}} defined the target of the distance computation, this would
be more complicated.
bq. why not make the coupling obvious, as in
I don't see any added benefit in that API. Rather, it doesn't seem as
expressive or readable. Ex:
{code:java}
// I find this ...
Iterable<Entry<P, V>> it = map.entriesFrom(pt).nearToFar();
// easier to read than this ...
Iterable<Entry<P, V>> it = map.entries(pt, DistanceOrdering.ASCENDING);
{code}
bq. I'm also a bit wary of only returning a StreamableIterator interface rather
than e.g. a List, because in the potential use case which I have in mind, the
selected points are rather few (as compared to the map's contents) and the
number of them should be known in order to, for example, compute an
interpolation of the associated values.
{{StreamableIterator}} is returned instead of {{List}} for two reasons:
1. The total number of elements within the area of interest is generally not
known until all of the elements are enumerated. The main exception to this is
when the entire map/set is being iterated.
2. The list could be quite large so it should be up to the caller on whether or
not to incur the cost of allocation.
If a list is needed, it is a one-liner:
{{code:java}
List<P> closePts = set.withinDistance(p,
dist).nearToFar().stream().collect(Collectors.toList());
{code}
> PointSet/Map closest points
> ---------------------------
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
> Reporter: Matt Juntunen
> Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet<P> {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable<P> closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable<P> farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
