commons-issues mailing list archives

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


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:
Nope. The {{combine}} methods should do it.
{quote}Can the API of {{AffineTransform3D}} be discussed without including rotations?
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:
// 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) { ... }
 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:
>             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:

This message was sent by Atlassian JIRA

View raw message