Re: [geometry] Rename Transform to AffineTransform
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 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. -Matt From: Gilles Sadowski Sent: Tuesday, January 7, 2020 6:41 PM To: Commons Developers List Subject: Re: [geometry] Rename Transform to AffineTransform Le mar. 7 janv. 2020 à 17:55, Matt Juntunen 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 > Sent: Tuesday, January 7, 2020 10:29 AM > To: Commons Developers List > Subject: Re: [geometry] Rename Transform to AffineTransform > > Hello. > > Le mar. 7 janv. 2020 à 16:00, Matt Juntunen > 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
Re: [geometry] Rename Transform to AffineTransform
Le mar. 7 janv. 2020 à 17:55, Matt Juntunen 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 > Sent: Tuesday, January 7, 2020 10:29 AM > To: Commons Developers List > Subject: Re: [geometry] Rename Transform to AffineTransform > > Hello. > > Le mar. 7 janv. 2020 à 16:00, Matt Juntunen > 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
Re: [geometry] Rename Transform to AffineTransform
Gilles, > "AffineMap" (?) I think any name that doesn't include the word "transform" somehow would probably be confusing. > 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. -Matt From: Gilles Sadowski Sent: Tuesday, January 7, 2020 10:29 AM To: Commons Developers List Subject: Re: [geometry] Rename Transform to AffineTransform Hello. Le mar. 7 janv. 2020 à 16:00, Matt Juntunen 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
Re: [geometry] Rename Transform to AffineTransform
Hello. Le mar. 7 janv. 2020 à 16:00, Matt Juntunen 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
[geometry] Rename Transform to AffineTransform
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 - 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). Anyone have any insight or opinions on this? I've created GEOMETRY-80 to track this issue. Regards, Matt
Re: [VOTE] Release Apache Commons VFS Project 2.6.0 based on RC1
[x] +1 Release these artifacts Build passing on Java 8, Ubuntu LTS. Checked dist area and maven signatures, found no issues. Nothing wrong with zip sources file as well (RELEASE-NOTES & NOTICE check OK). Thanks Bruno On Tuesday, 7 January 2020, 7:45:33 am NZDT, Gary Gregory wrote: We have fixed a *compatibility bug* and added some minor enhancements since Apache Commons VFS Project 2.5.0 was released, so I would like to release Apache Commons VFS Project 2.6.0. Apache Commons VFS Project 2.6.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/vfs/2.6.0-RC1 (svn revision 37487) The Git tag commons-vfs-2.6.0-RC1 commit for this RC is 10155cc7e5814de21de179ba44e449ba4e6c45d7 which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-vfs.git;a=commit;h=10155cc7e5814de21de179ba44e449ba4e6c45d7 You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-vfs.git --branch commons-vfs-2.6.0-RC1 commons-vfs-2.6.0-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1485/org/apache/commons/ These are the artifacts and their hashes: /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0-tests.jar.asc (SHA1: 6d51958014e7bbe966ce22a5966464ae904471c8) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0.jar.asc (SHA1: f4ef4d7c526fa60f466fd1cae475bd2f15d595f7) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0-sources.jar (SHA1: f9eb21241ffa52e26c77768898aae727e3191f01) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0.pom.asc (SHA1: e04e8b3c4abfb4e30f312c79f7899e5edb2b8677) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0-javadoc.jar.asc (SHA1: 58fe812ed4ecfb6dc38382a5d98a38b0bdcbaac7) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0.pom (SHA1: 49577c2d3fe44c5f2d42075ba0c02d9f54f7033d) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0-sources.jar.asc (SHA1: 2a3f72eb255b4364ffd9f4022cc08270c867de29) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0-tests.jar (SHA1: 8ca8c2af6668ac425c8e8b86e35f5cee5775f734) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0.jar (SHA1: 3a6b5774f51d3f3190cdca027eb4cdfc8cba4cc8) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0-test-sources.jar (SHA1: 0a2727e9c2fd27faa62ff85eb8d07e8078b8eaeb) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0-javadoc.jar (SHA1: 37d0d7d075a09de49381934d72ac549cd1d9e5dd) /org/apache/commons/commons-vfs2-jackrabbit2/2.6.0/commons-vfs2-jackrabbit2-2.6.0-test-sources.jar.asc (SHA1: a80b1b66cd233a188c2140d7e7e34a4833c904a4) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0.jar (SHA1: 33b34c84ce6903de314c3359349fe0ca20dfb0fc) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0-sources.jar (SHA1: 02612097550eea07380bce9a4ab677ca434d300d) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0.pom (SHA1: c940dcc79fa8d6bb92b66524c1308db791aa5541) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0-tests.jar (SHA1: d4135131eac4c0f0c5f386b5cf1cc3d4b873) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0-sources.jar.asc (SHA1: 3d4a43891e6223ed77ee8ac2f4e52e500c003bb0) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0-tests.jar.asc (SHA1: 9c8f4ef406b9be919a74de48de187eb6604059ed) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0.jar.asc (SHA1: 6e3103408c923f8e6b16366f844b50aa4155be04) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0-test-sources.jar.asc (SHA1: 96b883122c241436b0b2feaf56a3b33e5f8d89fd) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0.pom.asc (SHA1: 16b6be13d08af3e8742e4ce9276cc1957a3cc06e) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0-javadoc.jar.asc (SHA1: db4696814e59eaf2c7c9d78ad61cfac14dd3a67c) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0-test-sources.jar (SHA1: 3c02db51df79c3be0b2d04e0fc06e5d1efb5fe38) /org/apache/commons/commons-vfs2-jackrabbit1/2.6.0/commons-vfs2-jackrabbit1-2.6.0-javadoc.jar (SHA1: c10c020e2be09b8b35a419dd103517ea8e6471a5) /org/apache/commons/commons-vfs2-distribution/2.6.0/commons-vfs2-distribution-2.6.0.pom (SHA1: 5f4439329920a98a7387d6bd14c449c9c6bd3a4a) /org/apache/commons/commons-vfs2-distribution/2.6.0/commons-vfs2-distribution-2.6.0.pom.asc (SHA1: 45cf6d745dbe174ea94174b54edca58a69d2f23d) /org/apache/commons/commons-vfs2/2.6.0/commons-vfs2-2.6.0-javadoc.jar.asc (SHA1: 2cc1ac10c49c890685ab94
