Re: Re: [geometry] PointMap and PointSet
Hello,
This kind of API sounds useful but not directly related to the
PointMap/Set types. As you mentioned, it seems like the API would most
likely use PointMap/Set internally. I believe the next step should be
to create a JIRA issue and figure out the details there.
Since it sounds like there are no objections to the current
PointMap/Set PR, I'm going to go ahead and merge it in and then
continue on with the closest point/farthest point API (GEOMETRY-146).
Regards,
Matt
On Wed, Mar 23, 2022 at 12:58 PM Gilles Sadowski wrote:
>
> Hi.
>
> Le mer. 23 mars 2022 à 03:27, Matt Juntunen
> a écrit :
> >
> > Gilles,
> >
> > > Say, for example, that "V" holds a single (floating-point) value. We
> > > insert entries
> > > map.put(x, 2);
> > > map.put(y, 8);
> > > assuming that "x" and "y" and just barely different, according to the
> > > chosen "precision context". Then:
> > > z = (x + y) / 2; // Pseudo-code.
> > > m = map.get(z);
> > > Does "m" equal "2" or "8", depending on whether "z" is (however
> > > slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)?
> >
> > It would be either 2 or 8. In the current implementations the first
> > matching entry is returned and since entries are typically searched
> > low to high, the entry corresponding to the lower of the two keys
> > would be returned. However, I do not consider this "lowest match wins"
> > behavior to be part of the public API since it depends on the
> > implementation details.
>
> For sure, any functionality must start from some low-level data
> structure with some prescribed behaviour. Here, we assume that
> the "mechanism" returns "2" or "8" (depending on the "details").
>
> My point is rather that the "cloud of points" abstraction seems to
> require a higher-level API (for which "PointMap" would, in turn,
> be an "implementation detail" too).
> Within that abstraction, querying the value at location between
> "x" and "y" would return some interpolation (i.e. any user-defined
> "combiner") of the data stored within a given "radius" of the
> queried location.
> This would make more sense (IMO) than the application having
> to deal with a result ("2" or "8") that is implementation-dependent:
> Such an additional API layer would allow the caller to specify the
> "combiner" as, for example, "the average of the values", the result
> would then be univocally defined ("5").
> [Obviously, when specifying a radius smaller than the "precision
> context", the behaviour would be identical to a direct query to the
> underlying "PointMap".]
>
> >
> > > But is it the right behaviour in all cases, or should there be a
> > > "replacement policy" (to apply whenever points are already stored
> > > within the "precision context" neighbourhood)?
> >
> > This seems to me like additional logic that could be built on top of
> > PointMap/Set, probably using the distance query methods in
> > GEOMETRY-146.
>
> Indeed; my question aimed at pointing to the importance of providing
> such an API.
>
> > Do you have a use case in mind here?
>
> In 2D: create an image (i.e. rectangular regular grid) that represents
> the (interpolated) data associated with the (scattered) points.
>
> Another (unrelated to the above discussion) feature: Allow different
> precision contexts in different regions of the space (cf. [1]).
>
> Best,
> Gilles
>
> [1] https://en.wikipedia.org/wiki/Unstructured_grid
>
> >
> > Regards,
> > Matt
> >
> > On Tue, Mar 22, 2022 at 1:05 PM Gilles Sadowski
> > wrote:
> > >
> > > Le mar. 22 mars 2022 à 14:46, Matt Juntunen
> > > a écrit :
> > > >
> > > > Hello,
> > > >
> > > > Unless there are any other comments on the PR, I'm going to plan on
> > > > merging it into master within the next couple of days.
> > > >
> > >
> > > Thanks for providing this new functionality.
> > >
> > > Do you envision that [Geometry] will also provide ways to manipulate
> > > data stored in the map (the "V" in e.g. "PointMap")?
> > >
> > > Say, for example, that "V" holds a single (floating-point) value. We
> > > insert entries
> > > map.put(x, 2);
> > > map.put(y, 8);
> > > assuming that "x" and "y" and just barely different, according to the
> > > chosen "precision context". Then:
> > > z = (x + y) / 2; // Pseudo-code.
> > > m = map.get(z);
> > > Does "m" equal "2" or "8", depending on whether "z" is (however
> > > slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)?
> > >
> > > This is related to the feature which I mentioned in GEOMETRY-146.
> > > I get that the low-level data-structure cannot "make up" a value that
> > > is not actually stored but it seems that the next step would be an API
> > > that lets the user specify what it means to retrieve data from the map.
> > >
> > > Then, there is also
> > > map.put(z, 10);
> > > Currently "10" will replace either the value at "x" or the value at "y".
> > > But is it the right behaviour in all cases, or should there be a
> > > "replacement policy" (to apply whenever points
Re: Re: [geometry] PointMap and PointSet
Hi.
Le mer. 23 mars 2022 à 03:27, Matt Juntunen
a écrit :
>
> Gilles,
>
> > Say, for example, that "V" holds a single (floating-point) value. We
> > insert entries
> > map.put(x, 2);
> > map.put(y, 8);
> > assuming that "x" and "y" and just barely different, according to the
> > chosen "precision context". Then:
> > z = (x + y) / 2; // Pseudo-code.
> > m = map.get(z);
> > Does "m" equal "2" or "8", depending on whether "z" is (however
> > slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)?
>
> It would be either 2 or 8. In the current implementations the first
> matching entry is returned and since entries are typically searched
> low to high, the entry corresponding to the lower of the two keys
> would be returned. However, I do not consider this "lowest match wins"
> behavior to be part of the public API since it depends on the
> implementation details.
For sure, any functionality must start from some low-level data
structure with some prescribed behaviour. Here, we assume that
the "mechanism" returns "2" or "8" (depending on the "details").
My point is rather that the "cloud of points" abstraction seems to
require a higher-level API (for which "PointMap" would, in turn,
be an "implementation detail" too).
Within that abstraction, querying the value at location between
"x" and "y" would return some interpolation (i.e. any user-defined
"combiner") of the data stored within a given "radius" of the
queried location.
This would make more sense (IMO) than the application having
to deal with a result ("2" or "8") that is implementation-dependent:
Such an additional API layer would allow the caller to specify the
"combiner" as, for example, "the average of the values", the result
would then be univocally defined ("5").
[Obviously, when specifying a radius smaller than the "precision
context", the behaviour would be identical to a direct query to the
underlying "PointMap".]
>
> > But is it the right behaviour in all cases, or should there be a
> > "replacement policy" (to apply whenever points are already stored
> > within the "precision context" neighbourhood)?
>
> This seems to me like additional logic that could be built on top of
> PointMap/Set, probably using the distance query methods in
> GEOMETRY-146.
Indeed; my question aimed at pointing to the importance of providing
such an API.
> Do you have a use case in mind here?
In 2D: create an image (i.e. rectangular regular grid) that represents
the (interpolated) data associated with the (scattered) points.
Another (unrelated to the above discussion) feature: Allow different
precision contexts in different regions of the space (cf. [1]).
Best,
Gilles
[1] https://en.wikipedia.org/wiki/Unstructured_grid
>
> Regards,
> Matt
>
> On Tue, Mar 22, 2022 at 1:05 PM Gilles Sadowski wrote:
> >
> > Le mar. 22 mars 2022 à 14:46, Matt Juntunen
> > a écrit :
> > >
> > > Hello,
> > >
> > > Unless there are any other comments on the PR, I'm going to plan on
> > > merging it into master within the next couple of days.
> > >
> >
> > Thanks for providing this new functionality.
> >
> > Do you envision that [Geometry] will also provide ways to manipulate
> > data stored in the map (the "V" in e.g. "PointMap")?
> >
> > Say, for example, that "V" holds a single (floating-point) value. We
> > insert entries
> > map.put(x, 2);
> > map.put(y, 8);
> > assuming that "x" and "y" and just barely different, according to the
> > chosen "precision context". Then:
> > z = (x + y) / 2; // Pseudo-code.
> > m = map.get(z);
> > Does "m" equal "2" or "8", depending on whether "z" is (however
> > slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)?
> >
> > This is related to the feature which I mentioned in GEOMETRY-146.
> > I get that the low-level data-structure cannot "make up" a value that
> > is not actually stored but it seems that the next step would be an API
> > that lets the user specify what it means to retrieve data from the map.
> >
> > Then, there is also
> > map.put(z, 10);
> > Currently "10" will replace either the value at "x" or the value at "y".
> > But is it the right behaviour in all cases, or should there be a
> > "replacement policy" (to apply whenever points are already stored
> > within the "precision context" neighbourhood)?
> >
> > Does this make sense?
> >
> > Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [geometry] PointMap and PointSet
Gilles, > Say, for example, that "V" holds a single (floating-point) value. We > insert entries > map.put(x, 2); > map.put(y, 8); > assuming that "x" and "y" and just barely different, according to the > chosen "precision context". Then: > z = (x + y) / 2; // Pseudo-code. > m = map.get(z); > Does "m" equal "2" or "8", depending on whether "z" is (however > slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)? It would be either 2 or 8. In the current implementations the first matching entry is returned and since entries are typically searched low to high, the entry corresponding to the lower of the two keys would be returned. However, I do not consider this "lowest match wins" behavior to be part of the public API since it depends on the implementation details. > But is it the right behaviour in all cases, or should there be a > "replacement policy" (to apply whenever points are already stored > within the "precision context" neighbourhood)? This seems to me like additional logic that could be built on top of PointMap/Set, probably using the distance query methods in GEOMETRY-146. Do you have a use case in mind here? Regards, Matt On Tue, Mar 22, 2022 at 1:05 PM Gilles Sadowski wrote: > > Le mar. 22 mars 2022 à 14:46, Matt Juntunen > a écrit : > > > > Hello, > > > > Unless there are any other comments on the PR, I'm going to plan on > > merging it into master within the next couple of days. > > > > Thanks for providing this new functionality. > > Do you envision that [Geometry] will also provide ways to manipulate > data stored in the map (the "V" in e.g. "PointMap")? > > Say, for example, that "V" holds a single (floating-point) value. We > insert entries > map.put(x, 2); > map.put(y, 8); > assuming that "x" and "y" and just barely different, according to the > chosen "precision context". Then: > z = (x + y) / 2; // Pseudo-code. > m = map.get(z); > Does "m" equal "2" or "8", depending on whether "z" is (however > slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)? > > This is related to the feature which I mentioned in GEOMETRY-146. > I get that the low-level data-structure cannot "make up" a value that > is not actually stored but it seems that the next step would be an API > that lets the user specify what it means to retrieve data from the map. > > Then, there is also > map.put(z, 10); > Currently "10" will replace either the value at "x" or the value at "y". > But is it the right behaviour in all cases, or should there be a > "replacement policy" (to apply whenever points are already stored > within the "precision context" neighbourhood)? > > Does this make sense? > > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [geometry] PointMap and PointSet
Le mar. 22 mars 2022 à 14:46, Matt Juntunen a écrit : > > Hello, > > Unless there are any other comments on the PR, I'm going to plan on > merging it into master within the next couple of days. > Thanks for providing this new functionality. Do you envision that [Geometry] will also provide ways to manipulate data stored in the map (the "V" in e.g. "PointMap")? Say, for example, that "V" holds a single (floating-point) value. We insert entries map.put(x, 2); map.put(y, 8); assuming that "x" and "y" and just barely different, according to the chosen "precision context". Then: z = (x + y) / 2; // Pseudo-code. m = map.get(z); Does "m" equal "2" or "8", depending on whether "z" is (however slightly) closer to either "x" or "y"? Or is it "5" (interpolated value)? This is related to the feature which I mentioned in GEOMETRY-146. I get that the low-level data-structure cannot "make up" a value that is not actually stored but it seems that the next step would be an API that lets the user specify what it means to retrieve data from the map. Then, there is also map.put(z, 10); Currently "10" will replace either the value at "x" or the value at "y". But is it the right behaviour in all cases, or should there be a "replacement policy" (to apply whenever points are already stored within the "precision context" neighbourhood)? Does this make sense? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [geometry] PointMap and PointSet
Hello, Unless there are any other comments on the PR, I'm going to plan on merging it into master within the next couple of days. Regards, Matt On Sun, Mar 20, 2022 at 11:39 AM Matt Juntunen wrote: > > Hi Eric, > > > Would Java’s Map.entrySet provide the “getEntry” type method needed? > > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet-- > > Or would this provide all entry’s and still need to find the specific entry > > so maybe a forEach variation to filter for a specific entry? > > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer- > > This would work but it would require iterating through half of the set > on average in order to find the correct entry, meaning we would lose > the performance benefits of the spatial data structure. The > PointMap.getEntry() method currently in the PR avoids this iteration > requirement. > > Regards, > Matt > > On Sun, Mar 20, 2022 at 9:13 AM Eric Bresie wrote: > > > > > > > > > > On March 14, 2022 at 10:19:14 AM CDT, Matt Juntunen > > wrote: > > > > I'm a little bit confused: Isn't it always the case that > > > > getEntry(p).getKey() > > will return the originally inserted (i.e. "canonical") point (i.e. not "p")? > > > > Map does not contain a "getEntry" method. If it did, that would indeed > > be preferable. > > > > > > Would Java’s Map.entrySet provide the “getEntry” type method needed? > > > > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet-- > > > > Or would this provide all entry’s and still need to find the specific entry > > so maybe a forEach variation to filter for a specific entry? > > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer- > > > > Unless I'm missing a standard use-case, the specialized methods > > > > "closestFirst" and "farthestFirst" don't seem useful (and wasteful > > of computing resources: If iterating over the whole set, why would > > one want to start from some particular point?). > > > > > > Eric Bresie > > ebre...@gmail.com > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [geometry] PointMap and PointSet
Hi Eric, > Would Java’s Map.entrySet provide the “getEntry” type method needed? > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet-- > Or would this provide all entry’s and still need to find the specific entry > so maybe a forEach variation to filter for a specific entry? > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer- This would work but it would require iterating through half of the set on average in order to find the correct entry, meaning we would lose the performance benefits of the spatial data structure. The PointMap.getEntry() method currently in the PR avoids this iteration requirement. Regards, Matt On Sun, Mar 20, 2022 at 9:13 AM Eric Bresie wrote: > > > > > On March 14, 2022 at 10:19:14 AM CDT, Matt Juntunen > wrote: > > I'm a little bit confused: Isn't it always the case that > > getEntry(p).getKey() > will return the originally inserted (i.e. "canonical") point (i.e. not "p")? > > Map does not contain a "getEntry" method. If it did, that would indeed > be preferable. > > > Would Java’s Map.entrySet provide the “getEntry” type method needed? > > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet-- > > Or would this provide all entry’s and still need to find the specific entry > so maybe a forEach variation to filter for a specific entry? > https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer- > > Unless I'm missing a standard use-case, the specialized methods > > "closestFirst" and "farthestFirst" don't seem useful (and wasteful > of computing resources: If iterating over the whole set, why would > one want to start from some particular point?). > > > Eric Bresie > ebre...@gmail.com > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [geometry] PointMap and PointSet
> > On March 14, 2022 at 10:19:14 AM CDT, Matt Juntunen > mailto:matt.a.juntu...@gmail.com)> wrote: > > > I'm a little bit confused: Isn't it always the case that > getEntry(p).getKey() > will return the originally inserted (i.e. "canonical") point (i.e. not "p")? > > Map does not contain a "getEntry" method. If it did, that would indeed > be preferable. Would Java’s Map.entrySet provide the “getEntry” type method needed? https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#entrySet-- Or would this provide all entry’s and still need to find the specific entry so maybe a forEach variation to filter for a specific entry? https://docs.oracle.com/javase/8/docs/api/java/util/Map.html#forEach-java.util.function.BiConsumer- > > Unless I'm missing a standard use-case, the specialized methods > "closestFirst" and "farthestFirst" don't seem useful (and wasteful > of computing resources: If iterating over the whole set, why would > one want to start from some particular point?). Eric Bresie ebre...@gmail.com >
