Hello. 2020-01-04 6:10 UTC+01:00, Matt Juntunen <matt.juntu...@hotmail.com>: > 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?
+1 For further consolidation, could we rename "eq" to "equals", and make "equals(Object)" call "equals(T, DoublePrecisionContext)"? Gilles > > -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
