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 <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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
