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
