[
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<Point3D>}} or {{UnaryOperator<Vector3D>}}, 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)
