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
