Hi.
Le mer. 23 mars 2022 à 03:27, Matt Juntunen
<matt.a.juntu...@gmail.com> 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 <gillese...@gmail.com> wrote:
> >
> > Le mar. 22 mars 2022 à 14:46, Matt Juntunen
> > <matt.a.juntu...@gmail.com> 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<Vector3D, V>")?
> >
> > 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
