Hi. Le mer. 8 janv. 2020 à 04:39, Matt Juntunen <matt.juntu...@hotmail.com> a écrit : > > Gilles, > > > I thought that the question was how to replace "transform"... > > I should probably clarify. I want to change the name of the Transform class > to make it clear that it only represents transforms that preserve parallelism > (eg, affine transforms). The most obvious name would be AffineTransform
How about keeping "Transform" for the interface name and define a method ---CUT--- /** * Move here the doc explaining under what conditions this method can return "true". */ boolean isAffine(); ---CUT--- ? Gilles > like I suggested but I want to make sure that no one objects to this for > design or mathematical reasons. > > > Anyways, what would be the issue(s) of a non-affine transform? > > IOW why should implementations of "Transfrom" be restricted to affine > > transform? > > Instances of Transform are used to transform hyperplanes and > hyperplane-bounded regions. If the transform is not affine, then the computed > results will not be accurate. I don't get that it is an "accuracy" issue. If some requirement is not met, results will be plain wrong; so it depends on usage: when the transform must be affine, the code being passed that instance should be able to check whether it can use it for the intended purpose. I wonder why the documented requirement that an "inverse transform must exist" does not translate into a method ---CUT--- Transform<P> getInverse(); ---CUT--- Regards, Gilles > -Matt > ________________________________ > From: Gilles Sadowski <gillese...@gmail.com> > Sent: Tuesday, January 7, 2020 6:41 PM > To: Commons Developers List <dev@commons.apache.org> > Subject: Re: [geometry] Rename Transform to AffineTransform > > Le mar. 7 janv. 2020 à 17:55, Matt Juntunen > <matt.juntu...@hotmail.com> a écrit : > > > > Gilles, > > > > > "AffineMap" (?) > > > > I think any name that doesn't include the word "transform" somehow would > > probably be confusing. > > This is supposed to be a synonym.[1] > I thought that the question was how to replace "transform"... > > > > > > Was the same "Transform" interface used in both the "euclidean" and the > > "spherical" packages of "Commons Math"? > > > > Indirectly. SphericalPolygonsSet extended AbstractRegion, which included an > > applyTransform(Transform) method. > > So the "affine" requirement (in the doc) applied there too. > > Anyways, what would be the issue(s) of a non-affine transform? > IOW why should implementations of "Transfrom" be restricted to affine > transform? > > Regards, > Gilles > > [1] https://en.wikipedia.org/wiki/Affine_transformation > > > -Matt > > ________________________________ > > From: Gilles Sadowski <gillese...@gmail.com> > > Sent: Tuesday, January 7, 2020 10:29 AM > > To: Commons Developers List <dev@commons.apache.org> > > Subject: Re: [geometry] Rename Transform to AffineTransform > > > > Hello. > > > > Le mar. 7 janv. 2020 à 16:00, Matt Juntunen > > <matt.juntu...@hotmail.com> a écrit : > > > > > > Hi all, > > > > > > The documentation for the o.a.c.geometry.core.Transform interface (which > > > comes from the original commons-math version) states that implementations > > > must be affine. Therefore, I think we should rename this interface to > > > AffineTransform to avoid confusion with other types of transforms, such > > > as projective transforms. Potential problems with this are > > > - the fact that the JDK already has a class with the same name > > > (java.awt.geom.AffineTransform), and > > > > "AffineMap" (?) > > > > > - I'm not sure if the term "affine" can technically be applied to > > > non-Euclidean geometries, such as spherical geometry (there may be > > > nuances there that I'm not aware of). > > > > Was the same "Transform" interface used in both the "euclidean" and the > > "spherical" packages of "Commons Math"? > > > > Regards, > > Gilles > > > > > Anyone have any insight or opinions on this? I've created GEOMETRY-80 to > > > track this issue. > > > > > > Regards, > > > Matt --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
