Affine transforms - matrix algebra

[Pavel Safrata]

Hello,
looks like we reached the agreement on a (well documented) 
append/prepend terminology with the original proposal semantics reversed.

Before I post the final proposal, following changes need to be discussed:

We need to add manual transformation methods to Transfrom class. This is 
very important, I can't believe I've forgotten them..
     public Point3D transform(Point3D point)
     public Bounds transform(Bounds bounds)
Any other?

Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, 
MAT_3D_3x4, MAT_3D_4x4, do you agree?

Keep the methods accepting arrays recognizing their types according to 
their length and add
     public Affine(double[] array, MatrixArrayType type, int beginIndex)
     public void setToTransform(double[] array, MatrixArrayType type, 
int beginIndex)
     public void append(double[] array, MatrixArrayType type, int 
beginIndex)
     public void prepend(double[] array, MatrixArrayType type, int 
beginIndex)
Do you agree? Or would you prefer different set of array-accepting methods?

Regarding the getRow/getColumn: we again face the problem whether to 
return 3 or 4 elements. Consistently with the toArray, I propose
     VectorArrayType = { VAT_2D, VAT_3D }
     public double[] getRow(int row, VectorArrayType type),
     public double[] getRow(int row, VectorArrayType type, double[] array)
     public double[] getColumn(int col, VectorArrayType type),
     public double[] getColumn(int col, VectorArrayType type, double[] 
array)
Do you agree?

Thanks,
Pavel

On 21.7.2012 2:52, Martin Desruisseaux wrote:
> Hello Jim
>
> No worry, I don't think that anyone felt sent off. I think that 
> peoples know that emails can give all kind of impression not always 
> accurate.
>
> I wasn't aware that a concept of transformation chains could be 
> associated to nodes. Given that this chain is in reverse order 
> compared to the one I was familiar with, I understand the difference 
> in interpretation of "append". I agree that consistency is important. 
> I have no problem with any choice, but I would just like the 
> explanation about transformation chains (in the JavaFX sense) to 
> appear somewhere in the javadoc, for helping some developers 
> (including myself) to do the right association in their mind.
>
>     Thanks and regards,
>
>         Martin
>
>
>
> Le 21/07/12 02:02, Jim Graham a écrit :
>> When I wrote my first reply in this thread I tried to warn people 
>> that I was coming back from vacation to a long thread and I hadn't 
>> double checked all of the math that was being proposed, so I was 
>> commenting from a general perspective that wasn't necessarily in 
>> agreement or conflict with the current proposal at the time.  I hope 
>> that I didn't send people off on a wild goose chase based on my list 
>> of points that may have come from a negative "we shouldn't do this or 
>> that" kind of perspective.
>>
>> To switch things around, let me make some positive statements of 
>> something that I would find acceptable and which I think may have 
>> actually been formally proposed here (but I didn't "do the math" to 
>> verify that).
>>
>> I believe that the following produce equivalent transforms:
>>
>> --------------
>> Node.getTransforms().add(new Scale(sx,sy));
>> Node.getTransforms().add(new Translate(tx,ty));
>> ---
>> t = new java.awt.geom.AffineTransform();
>> t.scale(sx, sy);
>> t.translate(tx, ty);
>> ---
>> t = new java.awt.geom.AffineTransform();
>> tmp = new java.awt.geom.AffineTransform();
>> tmp.setToScale(sx, sy);
>> t.concatenate(tmp);
>> tmp.setToTranslate(tx, ty);
>> t.concatenate(tmp);
>> ---
>> Node n...;
>> Group g = new Group(n);
>> g.setScale(sx, sy);
>> n.setTranslate(tx, ty);
>> --------------
>>
>> We also have the fact that "preConcatenate()" is mathematically 
>> reversed, and also inside-out from the perspective of what is being 
>> manipluated, as compared to concatenate().
>>
>> So, if "appendFoo(...)" was essentially equivalent to:
>>
>> - Node.getTransforms().add(new Foo(...));
>> - t.foo(...);
>> - t.concatenate(tmp.setToFoo(...));
>>
>> and "prependFoo(...)" was essentially equivalent to:
>>
>> - Node.getTransforms().add(0, new Foo(...));
>> - we don't have a Java2D reverse for t.foo();
>> - t.preConcatenate(tmp.setToFoo(...));
>>
>> then I could be happy.  It may not have complete unambiguity in an 
>> absolute sense, but it would at least establish an internal 
>> consistency and harmony of naming conventions with respect to the 
>> JavaFX Node transform attributes and with the prior art in the Java 
>> geometry family (AffineTransform)...
>>
>> I feel that append, while we can argue the semantics of what it might 
>> mean mathematically, sounds like the more natural verb of the two 
>> forms of methods (comparing appendFoo to prependFoo), and in general 
>> it is the set of methods that they probably want to be using if they 
>> come from Java2D, or if they are writing code that takes a transform 
>> from somewhere else that defines their "transformation context" and 
>> they want to work within that (if you prepend, then you override the 
>> context someone set up for you, if you append, then you take their 
>> context and work relative to it).
>>
>> Is that what was being proposed before I came in and stomped on the 
>> discussion?
>>
>>             ...jim
>>
>