[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722577#comment-16722577
]
Matt Juntunen commented on GEOMETRY-14:
---
I added the {{Rotation3D}} interface as well as an {{AffineTransformMatrix}}
interface. They both extend {{Transform}} but have default implementations that
throw exceptions for the methods that will be removed with GEOMETRY-24. I can't
push directly to your branch so I merged your branch into my PR branch and made
the change there.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722445#comment-16722445
]
Gilles commented on GEOMETRY-14:
bq. I'm thinking of doing it after \[...\]
OK. We can resolve this issue after you add add the {{Rotation3D}} interface
to the feature branch.
It should probably already extend {{Transform}} (with implementations that
throw an exception if necessary) so that we do not forget...
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722360#comment-16722360
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}continue (on the feature branch) with {{Transfom}}
{quote}
I was picturing the {{Transform}} stuff (GEOMETRY-24) as a separate PR. It's
going to need modifications to all of the Hyperplane and SubHyperplane
implementations and so is going to be non-trivial. I'm thinking of doing it
after GEOMETRY-11 and maybe even some of the Hyperplane issues I just added.
{quote}Could you have a look at adapting the unit test currently in
{{QuaternionRotationTest}} (all depending on {{Vector3D}}) and port some to
{{SlerpTest}} in "Numbers"?
{quote}
Yep.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722338#comment-16722338
]
Gilles commented on GEOMETRY-14:
Commit 437c7c4976dde2757fb70aaae08fc86c30e017e7 uses {{Slerp}} defined in
"Commons Numbers".
Could you have a look at adapting the unit test currently in
{{QuaternionRotationTest}} (all depending on {{Vector3D}}) and port some to
{{SlerpTest}} in "Numbers"?
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722315#comment-16722315
]
Gilles commented on GEOMETRY-14:
bq. Are you planning on doing it or should I?
I'll move {{Slerp}} to "Numbers", and some more deletions. ;-)
Then I'd let you continue (on the feature branch) with {{Transfom}} and so on.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722285#comment-16722285 ] Matt Juntunen commented on GEOMETRY-14: --- Also, what's the plan for making these changes? Are you planning on doing it or should I? > AffineTransform?D Classes > - > > Key: GEOMETRY-14 > URL: https://issues.apache.org/jira/browse/GEOMETRY-14 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > Fix For: 1.0 > > > We should create AffineTransform?D classes that implement matrix-based affine > transforms. They should have simple methods for creating translations, > rotations, and scaling and calculating the inverse. > > -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]- > Pull Request #2: [https://github.com/apache/commons-geometry/pull/16] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722283#comment-16722283
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}I've refactored the "slerp" functionality into its own {{Slerp}} class.
{quote}
I like it! I think the performance improvement alone makes it worth it. It
should definitely go in commons-numbers.
{quote}(e.g. to provide/use functional interfaces)
{quote}
My end goal is to have {{QuaternionRotation}} and all of the
{{AffineTransformMatrix?D}} classes extends a greatly simplified version of the
{{Transform}} interface (GEOMETRY-24). The interface would extend
{{UnaryOperator}} and only have the single {{apply}} method. I know we talked
about this previously and I didn't want to go back that road, but I think it
will work well if we streamlined the {{Transform}} interface and have
{{multiply}} and {{premultiply}} methods on the implementation classes to
perform composition. That will make it abundantly clear what's going on
mathematically and also allow users to take advantage of all the functional
goodies from the JDK. I didn't make this change as part of this PR because of
the sheer number of changes involved.
{quote}I've removed the redundant accessor methods
{quote}
Sounds good.
{quote}What is the purpose of {{toArray()}}?
{quote}
I thought that since I was allowing creation of instances from an array, I
should include a way to output an array. It's not needed if we just have the
{{of(Quaternion)}} factory method.
{quote}I think that it would make sense to have {{QuaternionRotation}} be an
implementation of a {{Rotation3D}} interface.
{quote}
That works. I'd much rather do that than rename the class to {{Rotation3D}}.
Here's a very simple possibility:
{code:java}
public interface Rotation3D extends UnaryOperator { // extend
Transform after GEOMETRY-24
Vector3D getAxis();
double getAngle();
Rotation3D getInverse();
}
{code}
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16722266#comment-16722266
]
Gilles commented on GEOMETRY-14:
I've removed the redundant accessor methods: If {{QuaternionRotation}}
discloses its underlying implementation, then the {{getQuaternion()}} accessor
is all that's needed.
Similarly, a single factory method (namely: {{of(Quaternion q)}}) would be
sufficient.
What is the purpose of {{toArray()}}?
I think that it would make sense to have {{QuaternionRotation}} be an
implementation of a {{Rotation3D}} interface.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721985#comment-16721985
]
Gilles commented on GEOMETRY-14:
{quote}plenty to review
{quote}
Indeed. Thanks for all that work!
Since we were talking about quaternions, I directed my attention to
{{QuaternionRotation}}.
First thing that struck me is the size of source file: More than 900 lines
looks a bit too much for a single class.
Then the name itself (literally) compounds high- and low-level functionality,
API and implementation; the class definitely represents the concept of
"rotation" (through its {{apply(Vector3D)}} and other methods that deal with
angles), but its API also almost completely duplicates the (Commons Numbers)
{{Quaternion}} API, although this "facet" of the class is never used outside
itself (which confirms that the rotation API is central, and that the class
should perhaps be renamed to... {{Rotation3D}}!).
To be more concrete, I've updated a branch named {{feature_GEOMETRY-14}}; it's
your PR, on which I've refactored the "slerp" functionality into its own
{{Slerp}} class.
Please have a look.
IMHO, this kind of change immediately makes the code leaner and clearer (and
provides for some performance improvement if several values of the
interpolation parameters are needed).
Additionally, the "slerp" code is now totally decoupled from the "rotation"
code.; and we can obviously wonder whether this should actually belong to the
{{commons-numbers-quaternion}} module...
I wouldn't be surprised if other such refactorings may prove interesting (e.g.
to provide/use functional interfaces).
WDYT?
Overall, it's really great that the library evolves rapidly, driven by your
actual use cases (I suppose).
However, not being a "power" user of the functionality, I can't hope to
achieve an exhaustive review, all by myself. :-{
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721818#comment-16721818
]
Matt Juntunen commented on GEOMETRY-14:
---
The latest pull request is ready to go. It's now using {{Quaternion}} from
commons-numbers.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16716017#comment-16716017
]
Matt Juntunen commented on GEOMETRY-14:
---
Pull request is ready. {{QuaternionRotation}} is not yet using commons-number
{{Quaternion}} but there is plenty there to review anyway. We can either merge
this as-is and open a separate issue for using {{Quaternion}} or do it as
another commit in this pull request. Either way works for me.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> -Pull Request #1: [https://github.com/apache/commons-geometry/pull/14]-
> Pull Request #2: [https://github.com/apache/commons-geometry/pull/16]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16716013#comment-16716013 ] ASF GitHub Bot commented on GEOMETRY-14: darkma773r opened a new pull request #16: GEOMETRY-14: Adding Transform Classes URL: https://github.com/apache/commons-geometry/pull/16 Adding AffineTransformMatrix?D, QuaternionRotation, and AxisAngleSequence classes. Removing previous Rotation class. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > AffineTransform?D Classes > - > > Key: GEOMETRY-14 > URL: https://issues.apache.org/jira/browse/GEOMETRY-14 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > Fix For: 1.0 > > > We should create AffineTransform?D classes that implement matrix-based affine > transforms. They should have simple methods for creating translations, > rotations, and scaling and calculating the inverse. > > Pull Request #1: https://github.com/apache/commons-geometry/pull/14 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16714824#comment-16714824
]
Gilles commented on GEOMETRY-14:
bq. get NUMBERS-80 sorted out
I'll take care of the fields rename, probably later today.
bq. when should a class not be a VALJO?
Whenever there is a reason for not complying with at least one of the ValJO
requirements. ;-)
Otherwise, it is always possible to start with a ValJO and relax the
requirements later on (at the cost of BC breaking perhaps) when a compelling
use-case is described.
Using {{of}} factory methods is just one requirement, that is good to follow
(because it allows overloading) whenever possible, even for non-ValJO classes.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16714718#comment-16714718
]
Matt Juntunen commented on GEOMETRY-14:
---
This is [finally] almost done. I have all of the functionality and tests in
place and I'm just polishing up the docs and making sure that the reports are
clean. The code is not currently using the commons-numbers {{Quaternion}} class
but I'm thinking I'll at least create a merge request so we can start reviewing
this code while we get NUMBERS-80 sorted out. There's quite a bit here.
I do have one question, though: when should a class _not_ be a VALJO? I
currently have most of the classes for this issue using the "of" VALJO factory
methods but I'm not entirely sure if they should be VALJOs. For example,
{{AxisAngleSequence}} contains enum references and primitive doubles. Should
this be a VALJO or not? I want to decide this now so the rest of the library
will be consistent.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.0
>
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16652819#comment-16652819
]
ASF GitHub Bot commented on GEOMETRY-14:
darkma773r closed pull request #14: GEOMETRY-14: Initial AffineTransform3D class
URL: https://github.com/apache/commons-geometry/pull/14
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/exception/NonInvertibleTransformException.java
b/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/exception/NonInvertibleTransformException.java
new file mode 100644
index 000..88748dd
--- /dev/null
+++
b/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/exception/NonInvertibleTransformException.java
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.geometry.euclidean.exception;
+
+import org.apache.commons.geometry.core.exception.GeometryException;
+
+/** Exception thrown when a transform matrix is not
+ * able to be inverted.
+ */
+public class NonInvertibleTransformException extends GeometryException {
+
+/** Serializable version identifier */
+private static final long serialVersionUID = 20180927L;
+
+/** Simple constructor accepting an error message.
+ * @param msg error message
+ */
+public NonInvertibleTransformException(String msg) {
+super(msg);
+}
+}
diff --git
a/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/exception/package-info.java
b/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/exception/package-info.java
new file mode 100644
index 000..d441d1d
--- /dev/null
+++
b/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/exception/package-info.java
@@ -0,0 +1,23 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+/**
+ *
+ *
+ * This package provides exception types for Euclidean space.
+ *
+ */
+package org.apache.commons.geometry.euclidean.exception;
diff --git
a/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/AffineTransform3D.java
b/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/AffineTransform3D.java
new file mode 100644
index 000..4f40c45
--- /dev/null
+++
b/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/AffineTransform3D.java
@@ -0,0 +1,569 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644713#comment-16644713 ] Gilles commented on GEOMETRY-14: bq. I'm not going to have any time available for at least a week. Thanks for letting me know. :) > AffineTransform?D Classes > - > > Key: GEOMETRY-14 > URL: https://issues.apache.org/jira/browse/GEOMETRY-14 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > > We should create AffineTransform?D classes that implement matrix-based affine > transforms. They should have simple methods for creating translations, > rotations, and scaling and calculating the inverse. > > Pull Request #1: https://github.com/apache/commons-geometry/pull/14 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644710#comment-16644710 ] Gilles commented on GEOMETRY-14: bq. Currently, I think I just want to keep it the way it is and maybe ponder if there are any better options. Since I cannot offer a concrete alternative, it's quite fine as an attempt to improve on the previous implementation, but since part of the design is not "mathematically pure" (because of the Cartesian system of coordinates being so high in the class hierarchy), I deem it necessary that you write a summary of the design decisions (with known advantages and shortcomings) so that we don't flip-flop every time someone thinks there is some "obvious" flaw in the code structure. bq. Rotation be a separate class that implements Transform from core but is not part of the AffineTransform hierarchy Why? It would also seem to be going away from the goal of "mathematically pure". > AffineTransform?D Classes > - > > Key: GEOMETRY-14 > URL: https://issues.apache.org/jira/browse/GEOMETRY-14 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > > We should create AffineTransform?D classes that implement matrix-based affine > transforms. They should have simple methods for creating translations, > rotations, and scaling and calculating the inverse. > > Pull Request #1: https://github.com/apache/commons-geometry/pull/14 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644363#comment-16644363
]
Matt Juntunen commented on GEOMETRY-14:
---
As far as the point/vector thing goes, I'm hesitant to change anything now
since a lot of work has gone into the current structure. You are right in that
there isn't much of a _need_ to have separate classes, although I still like it
the way it is. I think it makes algorithms very clear and the meaning of
variables very precise. If we go back to a single class that implements both
point and vector, then I feel like we'd be back where we were at the end of
MATH-1284 with the Cartesian?D classes being used everywhere. I'm not a fan of
that structure since I feel like it obfuscates the meaning of the code to have
a class name that's not either Point or Vector. So, do we want to be
mathematically pure or programmatically concise? Now that we've moved to a
VALJO system for these types and no one is calling {{new}} on anything, we may
actually have more options available in the design on this point. I'm not sure
yet. Currently, I think I just want to keep it the way it is and maybe ponder
if there are any better options.
{quote}However, do you see a real use-case where the composition of transforms
would need more than this method:
{quote}
Nope. The {{combine}} methods should do it.
{quote}Can the API of {{AffineTransform3D}} be discussed without including
rotations?
{quote}
No, I don't want to merge anything without that. I left it out for now so we
could discuss the less complicated parts of the API first. For the 3D case, I'm
planning on having {{Rotation}} be a separate class that implements
{{Transform}} from core but is not part of the {{AffineTransform}} hierarchy.
There will be methods that convert back and forth between them. I'm picturing
methods like this:
{code:java}
// AffineTransform3D
// apply a rotation to the current transform and return a new instance
public AffineTransform3D rotate(Rotation rot) {...}
// extract the rotation portion of the transform
public Rotation getRotation() {... }
// convert the given rotation to a matrix-based transform
public AffineTransform3D createRotation(Rotation rot) { ... }
{code}
I think I have a good idea of where to go on this issue now, so I'm going to
close my pull request and work on it some more. It might be a bit before I can
get another pull request in since I'm anticipating a fair amount of work and
I'm not going to have any time available for at least a week.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641524#comment-16641524
]
Gilles commented on GEOMETRY-14:
About {{Point}} and {{Vector}}, the question is simply to have (programming)
use-cases for both.
{quote}the difference is mathematical
{quote}
I like when the design can be close to the mathematical concepts. But you
argued that having
{code:java}
public class Vector3D extends Cartesian3D implements
MultiDimensionalEuclideanVector
{code}
and
{code:java}
public final class Point3D extends Cartesian3D implements
EuclideanPoint
{code}
was going to be more effective from a usage POV even though the class hierarchy
does not agree with the mathematics (a point exists independently of the
coordinate system).
So my (design) question is of the same order: If programming is allowed to be
a step away from mathematics, maybe (?) that a "point" class is not strictly
necessary (here).
As a basic user of a very small fraction of that code, I don't know (yet).
That's why I'm suggesting that, if possible, some real-use cases should be
presented for the concepts (a.o. _both_ "point" and "vector") that are
represented in the API.
If now is not a good time, then I can wait; but this is "for the record" of
trying to avoid issues as they seem to appear (at least to me). ;)
About affine transforms: I'm convinced that {{java.util.function}} is not going
to help then.
However, do you see a real use-case where the composition of transforms would
need more than this method:
{code:java}
public AffineTransform3D combine(AffineTransform3D transform) { /* ... */ }
public static AffineTransform3D combine(AffineTransform3D ... transforms) { /*
... */ }
{code}
together with the varargs static method shown above (as syntactic sugar)?
Note: I couldn't figure out the 3-arguments {{multiply}} method (in the PR).
Can the API of {{AffineTransform3D}} be discussed without including rotations?
Shall we just have
{code:java}
public Rotation extends AffineTransform3D { /* ... */ }
{code}
?
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641196#comment-16641196
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}What are the different use-cases? Having had a quick look at {{Point3D}}
and {{Vector3}}, they seem fairly similar in their API and fairly convoluted in
their inheritance hierarchy.
{quote}
It surprises me that this seems new since we've discussed the point/vector API
quite a bit. Are you asking what's the difference between the usage of
{{Point?D}} and {{Vector?D}}? If so, the difference is mathematical: points
represent locations in space and vectors represent translations and directions.
Not many operations are allowed on points but vectors come with the full range
of operations allowed on vector spaces in linear algebra. Transformations can
be applied to both types, so {{AffineTransform?D}} needs to support both.
{quote}When we wonder whether an {{AffineTransform3D}} _is-a_
{{UnaryOperator}} or {{UnaryOperator}}, there is some alarm
starting to ring...
{quote}
It's logically both. However, the language doesn't directly support this so we
need to figure something else out. I don't see anything wrong with that.
As a side note, I'm planning on making the {{AffineTransform?D}} classes
implement {{o.a.c.g.core.partitioning.Transform}} as well, which means that we
will also have the method {{apply(Hyperplane<>)}}.
{quote}re: transform sequences
{quote}
I think that users should nearly always want to combine transform sequences
into a single transform instead of applying multiple transforms in order. For
example, with the current implementation of {{AffineTransform3D}}, the number
of multiplications involved in transforming a point with multiple transforms
applied one after another is {{9nt}} where {{n}} is the number of points and
{{t}} is the number of transforms. When combining transforms together, the
{{t}} value drops out and this becomes {{9n + 36}}, where {{n}} is again the
number of points and the {{36}} value is the one-time cost of multiplying the
transform matrices together. So, even with the simplest case of applying two
transforms in order, the combination method becomes the better choice when {{n
> 4}}. The difference becomes even more pronounced as more transforms are
involved and {{n}} increases.
Also, the combination approach has the benefit that an inverse can be
calculated that undoes _all_ of the combined transformations. This cannot be
done easily with a simple sequence of transforms.
I say all of this to make the point that we may not be losing a lot if
{{AffineTransform?D}} does not implement {{UnaryOperator}}. The function
composition and chaining provided by the latter does not quite fit our use case.
{quote}Also, have you already looked at how e.g.
# existing classes such as {{Rotation}} fit with {{AffineTransform3D}}
# usage of {{Quaternion}} (from ["Commons
Numbers"|https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-quaternion/src/main/java/org/apache/commons/numbers/quaternion/Quaternion.java;h=86d7fdfa53d2b61bd07cebd05c02008f2809ebd9;hb=HEAD]){quote}
Yes, I have. I'm planning on getting the API sorted with translations and scale
operations before jumping into that.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641031#comment-16641031
]
Gilles commented on GEOMETRY-14:
{quote}The transform classes are used to transform both points and vectors
{quote}
What are the different use-cases?
Having had a quick look at {{Point3D}} and {{Vector3}}, they seem fairly
similar in their API and fairly convoluted in their inheritance hierarchy.
We may want to have a user guide explaining the design and how it is put to
use with concrete examples of when to use this vs that class/interface. It will
surely spare us puzzled faces later on.
When we wonder whether an {{AffineTransform3D}} _is-a_
{{UnaryOperator}} or {{UnaryOperator}}, there is some alarm
starting to ring...
{quote}Did you have any other alternatives in mind?
{quote}
In principle, there are two use-cases that arise from the above discussion:
# Expressing a sequence of {{AffineTransform3D}} operations
# Combining a sequence of {{AffineTransform3D}} operations
If the former is ever useful, then the {{UnaryOperator}} approach seems to
allow more flexibility in using the JDK API (stream, filter, ...).
If the second is necessary for performance reason, for example (IIUC) when the
same transform is to be applied to many points (or was it vectors? ;)), a
simpler (IMHO) API may be:
{code:java}
public static AffineTransform3D combine(AffineTransform3D ... transforms) {
AffineTransform3D c = identity();
for (int i = 0; i < transforms.length; i++) {
c = c.times(transforms[i]);
}
return c;
}
{code}
So perhaps, it is the right to setup "real-life" use-cases as you mentioned in
your roadmap post to the ML, in order to keep us in the right track (i.e.
trying to avoid API and performance mistakes).
Also, have you already looked at how e.g.
# existing classes such as {{Rotation}} fit with {{AffineTransform3D}}
# usage of {{Quaternion}} (from ["Commons
Numbers"|https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-quaternion/src/main/java/org/apache/commons/numbers/quaternion/Quaternion.java;h=86d7fdfa53d2b61bd07cebd05c02008f2809ebd9;hb=HEAD])
?
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640970#comment-16640970
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}Using it will bring all the advantages of a standard API.
{quote}
I agree with using the standard API here. However, there are a couple of slight
issues.
# The transform classes are used to transform both points and vectors, but we
can only choose one to be the type for UnaryOperator. It should probably be
points, but it seems weird to leave vectors out like that.
# The {{andThen}} and {{compose}} methods from {{java.util.Function}} don't
really provide the behavior we want when chaining transforms. The JDK versions
return new functions that invoke the original ones in the correct order. What
we want in our method is to multiply the transform matrices together to create
a new matrix that mathematically performs the same operations as if the
original matrices were applied in order. So, the end result is the same but the
internals (and performance) are quite different. I think we need a separate
method name to convey this concept. I previously proposed {{transform}} but
some other options might be {{build}}, {{combine}}, ...
{quote}Maybe, but caution still applies for anything that goes into the public
API. The fluent API is nice but we should explore the alternatives.
{quote}
Yes. I do quite like it, though, and I think it will get some good use. Did you
have any other alternatives in mind?
{quote}This is a can of worms, as it will prevent any simple implementation of
multi-threaded processing.
{quote}
I've refactored this in my working branch so that the classes are truly
immutable, ie all fields are final.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640904#comment-16640904
]
Gilles commented on GEOMETRY-14:
{quote}A.transform(B).transform(C) would logically perform A, then B, then C.
{quote}
With
[UnaryOperator|https://docs.oracle.com/javase/8/docs/api/java/util/function/UnaryOperator.html],
this would be expressed either as
{code:java}
A.andThen(B).andThen(C)
{code}
or as
{code:java}
C.compose(B).compose(A)
{code}
Using it will bring all the advantages of a standard API.
{quote}{{t.apply(p1.vectorTo(p2)).normalize()}} is more difficult to read.
{quote}
Maybe, but caution still applies for anything that goes into the public API.
The fluent API is nice but we should explore the alternatives.
{quote}I do not have the private fields set as final so that I can do things
like copying
{quote}
This is a can of worms, as it will prevent any simple implementation of
multi-threaded processing.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640846#comment-16640846
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}Yes, but {{apply(vec)}} is as clear and more concise, and now favored by
the JDK.
{quote}
That makes sense. I think the naming of these methods is going to be critical
to the ease of use of the API. How about this: the transform classes follow the
JDK convention and have {{apply}} methods, eg {{transform.apply(vec)}} and
{{transform.apply(pt)}}. We define _apply_ here to mean "take the calling
transform and apply it to the given argument." For combining/chaining
transforms, we use a _transform_ method, which we define as meaning "take the
calling object and transform it with the argument." We would then have
{{A.transform(B)}} mean "transform A with B", which would give us the correct
order of operations, eg {{A.transform(B).transform(C)}} would logically perform
A, then B, then C. We could also use this same definition of _transform_ in the
vector/point classes. For example, {{vec.transform(t)}} means "transform vec
with t."
{quote}Usual question: Why adding to the API?
{quote}
I want transforms to be able to be applied inline with other vector/point
methods. For example, {{p1.vectorTo(p2).transform(t).normalize()}} instead of
{{t.transform(p1.vectorTo(p2)).normalize()}}, which is more difficult to read.
{quote}Does that mean that the class is mutable?
{quote}
It is immutable from outside of the class. All of the methods like
{{translate}} return new instances. I do not have the private fields set as
final so that I can do things like copying the results of internal computations
back into an existing instance.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640689#comment-16640689
]
Gilles commented on GEOMETRY-14:
{quote}the API would be a bit more awkward, assuming that by A.compose(B) we
mean "perform B then perform A"
{quote}
It's not what I'd assume; so I see the possible confusion. ;)
Couldn't we leverage the [JDK
API|https://docs.oracle.com/javase/8/docs/api/java/util/function/UnaryOperator.html]?
I.e. have something like
{code:java}
public class AffineTransform3D implements UnaryOperator
{code}
{quote}{{transform.applyTo(vec)}} [because] they are applied _to_ points and
vectors.
{quote}
Yes, but {{apply(vec)}} is as clear and more concise, and now favored by the
JDK.
{quote}The vector and point classes have corresponding {{vec.apply(transform)}}
{quote}
Usual question: Why adding to the API?
Furthermore, this one is fairly counter-intuitive: to be consistent it should
have been {{vec.isAppliedToBy(transform)}}.
{quote}translate is an instance method and applies a translation to the current
transform.
{quote}
Does that mean that the class is mutable? :(
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640527#comment-16640527
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}The name {{multiply}} seems strange; wouldn't {{compose}} be more
appropriate?
{quote}
Yes, {{multiply}} does seem to expose the underlying matrix implementation. We
could do {{compose}} but then I think the API would be a bit more awkward,
assuming that by {{A.compose(B)}} we mean "perform B then perform A". For
example, if we want to perform a series of transforms in order {{A}}, {{B}},
{{C}}, and then {{D}}, we would need to do
{{D.compose(C.compose(B.compose(A)))}}. If we rename it to {{apply}} and define
{{A.apply(B)}} as "take A and perform B on it", then we can write the same
series of transforms a {{A.apply(B).apply(C).apply(D)}}. I feel like that's
cleaner and better matches the behavior of the other methods, like
{{translate}}.
{quote}{{tranform.apply(v)}} looks more natural than {{v.applyt(transform)}}.
{quote}
I used {{transform.applyTo(vec)}} since that's typically how one talks about
transforms operating, ie, they are applied _to_ points and vectors. The vector
and point classes have corresponding {{vec.apply(transform)}}.
{quote}Doesn't {{createTranslation}} duplicate {{translate}}?
{quote}
They are similar but slightly different. {{translate}} is an instance method
and applies a translation to the current transform. This involves a matrix
multiplication. {{createTranslation}} is a static factory method for creating a
brand new transform that performs a translation. The matrix for this can be
created directly; no matrix multiplication is involved. I would have liked to
have given them the same name but then the methods would conflict.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16639906#comment-16639906
]
Gilles commented on GEOMETRY-14:
I didn't look in detail; here are a few remarks:
* The name {{multiply}} seems strange; wouldn't {{compose}} be more appropriate?
* {{tranform.apply(v)}} looks more natural than {{v.applyt(transform)}}.
* Incremental building from the unit transform seems fine
* Doesn't {{createTranslation}} duplicate {{translate}}?
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636383#comment-16636383 ] Matt Juntunen commented on GEOMETRY-14: --- I just submitted a partial pull request for this. I'm primarily interested in getting feedback, so we don't necessarily need to merge this one in if it's not ready. > AffineTransform?D Classes > - > > Key: GEOMETRY-14 > URL: https://issues.apache.org/jira/browse/GEOMETRY-14 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > > We should create AffineTransform?D classes that implement matrix-based affine > transforms. They should have simple methods for creating translations, > rotations, and scaling and calculating the inverse. > > Pull Request #1: https://github.com/apache/commons-geometry/pull/14 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16636381#comment-16636381 ] ASF GitHub Bot commented on GEOMETRY-14: darkma773r opened a new pull request #14: GEOMETRY-14: Initial AffineTransform3D class URL: https://github.com/apache/commons-geometry/pull/14 This is an initial merge request for the work on GEOMETRY-14, primarily to gain feedback on the new transform architecture in 3D space before implementing for other dimensions. Rotations are not yet included since that will involve restructuring of the Rotation class as well. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > AffineTransform?D Classes > - > > Key: GEOMETRY-14 > URL: https://issues.apache.org/jira/browse/GEOMETRY-14 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > Labels: pull-request-available > > We should create AffineTransform?D classes that implement matrix-based affine > transforms. They should have simple methods for creating translations, > rotations, and scaling and calculating the inverse. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[ https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16625232#comment-16625232 ] Matt Juntunen commented on GEOMETRY-14: --- Working on this here: https://github.com/darkma773r/commons-geometry/tree/transforms > AffineTransform?D Classes > - > > Key: GEOMETRY-14 > URL: https://issues.apache.org/jira/browse/GEOMETRY-14 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > > We should create AffineTransform?D classes that implement matrix-based affine > transforms. They should have simple methods for creating translations, > rotations, and scaling and calculating the inverse. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
