Affine transforms - matrix algebra

[Pavel Safrata]

On 23.7.2012 12:09, Martin Desruisseaux wrote:
> Le 23/07/12 11:11, Pavel Safrata a écrit :
>> We need to add manual transformation methods to Transfrom class. This 
>> is very important, I can't believe I've forgotten them..
> I noticed that those methods were missing, but I though that it was on 
> intend :)
>
>> public Point3D transform(Point3D point)
>>     public Bounds transform(Bounds bounds)
>> Any other?
> I think that the following one is very important for performance reasons:
>
> void transform(double[] srcPts, int srcOffset, double[] dstPts, int 
> dstOffset, int numPts);
>
> with semantic identical to the one currently in the Java2D 
> AffineTransform. 

Unlike in J2D our Pts will have three coordinates, right? Or do we want 
transform2D and transform3D?

> The other variants working on float arrays and the ones mixing 
> float/double arrays would also be useful. Alternatively, methods 
> working on java.nio.Float/DoubleBuffer instead than arrays would also 
> be okay if performances are the same (this would avoid the need for 
> src/dstOffset and numPts arguments).

I'm not sure about the floats. I don't mind adding those methods but is 
it OK for us to work with floats here and nowhere else? Shouldn't we 
then allow for floats at least for all the other arrays in Affine class?

>
> Maybe it would be worth to phrase the javadoc in a way that leave room 
> for slight implementation-dependant differences in the numerical 
> results. For example the javadoc of Math.sin said "The computed result 
> must be within 1 ulp of the exact result". I think that something 
> similar for the transform methods (the number of ulp is yet to be 
> determined) would be useful in order to leaves room for 
> hardward-accelerated implementations. I'm thinking especially about 
> the "fused add-multiply" operation found on many modern processor, 
> which doesn't produce exactly the same result than multiplication 
> followed by addition in Java. It would be nice if Transform 
> implementations were allowed to use such operations on platforms that 
> support it, despite the slight difference in numerical results.

To me this sounds a bit frightening. I may be wrong but I believe that 
the "ulps" are there to deal with representability of certain numbers in 
floating-point types but not with different math engines producing 
different results - I believe the results may be up to one ulp wrong but 
are reliably stable among all platforms. I'm a bit afraid that providing 
unstable results would violate at least some unwritten conventions. But 
I'm not an expert here, I might be wrong.

>
>
>> Rename the MatrixArrayType constants to MAT_2D_3x2, MAT_2D_3x3, 
>> MAT_3D_3x4, MAT_3D_4x4, do you agree?
> I don't really have better idea at this time... I wonder if we could 
> find a way to merge with the VAT_* constants...

We may use MAT for the getRow/getCol - it would specify from what matrix 
the col/row will be taken (each pair of values would provide similar 
behavior except for one of them allowing to read the last line).

Thanks,
Pavel

> Martin
>