Forwarding to ML. Gilles
P.S. Please don't send to me directly when the post is meant for the list, as otherwise hitting "Reply" will move the conversation off-list... ---------- Forwarded message --------- De : Gilles Sadowski <gillese...@gmail.com> Date: sam. 4 janv. 2020 à 19:54 Subject: Re: [Geometry] Class "Equivalency" To: Matt Juntunen <matt.juntu...@hotmail.com> Hello. Le sam. 4 janv. 2020 à 17:30, Matt Juntunen <matt.juntu...@hotmail.com> a écrit : > > Gilles, > > I removed the Equivalency interface and pushed the changes to my current PR, > along with some changes related to the shape-generation classes (GEOMETRY-83). > > In regard to renaming "eq" to "equals", I personally prefer "eq" (short for > "equivalent") to make it more distinct from "equals". I thought that it was short for "equals", so this is indeed confusing and the method should actually be named "equivalent". > The "eq" method does not satisfy the strict requirements for "equals", namely > transitivity and the relation to hashCode. (This is also why I don't think > "equals" should internally call "eq".) OK. > Having "eq" be an overload of "equals" would to me imply that they have the > same general properties, which is not the case. Not so sure; but I don't have any strong argument at hand. :-) However, are there unit tests and/or examples of use-cases from which newbies can grasp when to use which? Thanks, Gilles > > -Matt > ________________________________ > From: Gilles Sadowski <gillese...@gmail.com> > Sent: Saturday, January 4, 2020 6:26 AM > To: Commons Developers List <dev@commons.apache.org> > Subject: Re: [Geometry] Class "Equivalency" > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
