Gilles, I took another look at the code and it turns out we can easily remove the entire Equivalency interface and just use methods of the form "eq(T, DoublePrecisionContext)", exactly the same way that the VectorXD classes do it now. This way, it's a little more clear what precision is being used for the comparison and we don't have an extra interface floating around. The original behavior can also be replicated with just "obj.eq(other, obj.getPrecision())".
WDYT? -Matt ________________________________ From: Gilles Sadowski <gillese...@gmail.com> Sent: Friday, January 3, 2020 8:12 PM To: Commons Developers List <dev@commons.apache.org> Subject: Re: [Geometry] Class "Equivalency" Hi. 2020-01-03 22:02 UTC+01:00, Matt Juntunen <matt.juntu...@hotmail.com>: > Gilles, > > Yes, users are responsible for handling their own PrecisionContexts. The > idea behind the Equivalency interface was to provide an easy way to perform > "fuzzy" comparisons between objects. The interface itself does not define > what the comparison involves. Classes that implement the interface (such as > Line and Plane) decide what "fuzzy" means in their particular case. All of > the current implementations of this interface contain a requirement that > PrecisionContexts used by the compared objects (and used in floating point > comparisons in the eq() method itself) be exactly equal in order for the > objects to be considered equivalent. This is done to make the operation > commutative, so that if "a.eq(b)" is true, then "b.eq(a)" is also true. This > is documented on each implementing class. My impression is that it is more akin to "strict" equality rather than fuzzy. Looking at the code, e.g. for "Line3D", it doesn't strike as obvious what the different use-cases are for "equals" and "eq". In effect, I could imagine that "fuzzy" equality could not be commutative (random, perhaps naive, thought): an instance with low precision would indicate that some result (where precision could have been lost) would consider itself equal to another instance (that may have have been set with higher precision). Gilles > > -Matt > ________________________________ > From: Gilles Sadowski <gillese...@gmail.com> > Sent: Friday, January 3, 2020 12:56 PM > To: Commons Developers List <dev@commons.apache.org> > Subject: [Geometry] Class "Equivalency" > > Hello. > > I'm wary about making that class part of the public API. > I thought that the original idea was that users would be > responsible of how they handle the "PrecisionContext". > However, it seems that "Equivalency" requires equality > of "PrecisionContext" instances (not the "double" value). > This is non-obvious and IMHO deserves some explanation > in the Javadoc and user guide. > > Regards, > 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