commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Juntunen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
Date Wed, 10 Oct 2018 02:28:00 GMT

    [ 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)

Mime
View raw message