Affine transforms - matrix algebra

[Pavel Safrata]

On 23.7.2012 15:20, Martin Desruisseaux wrote:
> Le 23/07/12 14:01, Pavel Safrata a écrit :
>> On 23.7.2012 12:09, Martin Desruisseaux wrote:
>> Unlike in J2D our Pts will have three coordinates, right? Or do we 
>> want transform2D and transform3D?
> Yes, I was thinking about 3D-points. Maybe it is not necessary to 
> support 2D-points, since the existing Java2D classes can fit that need...

The purpose of this discussion is for users to have all needed math in 
our transformations so they don't need to use other transformation 
libraries to do the basic math. An FX application will (and should) use 
FX transforms and they should provide all the necessary features; mixing 
the FX code with J2D transforms, that are unusable with our nodes, is 
not a nice thing to do. So if we don't provide the 2D case here, we need 
to have different reason :-)

>
>
>> 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?
> I didn't though about the fact that 'float' are used nowhere else in 
> JavaFX... This is a good point.
>
> Does JavaFX plans to support big geometries someday? For example 
> world-wide coast lines, in which case using 'float' instead of 
> 'double' make a huge difference on memory usage?

I'm afraid I don't see the big picture here. But maybe we can leave the 
'float' variants out for now (we can always add them later).

>
>
>> 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.
> My (maybe naive) understanding was that StrictMath reliably produces 
> stable results among all platforms, while Math allow some 
> platform-dependent flexibility. In our implementation of a map 
> projection library making extensive use of Math.sin and the like, I do 
> have noticed slight platform-dependent variations.

You are right, the javadoc claims so.

>
> Transform doesn't have to use the "ulps" wording; the actual question 
> is whatever Transform should allow hardward accelerations at the 
> expense of strict cross-platform stability. It may be worth to note 
> that if my understanding of java.lang.Math trigonometric functions is 
> not wrong, then this slight cross-platform variability already exists 
> in Transforms having a rotation calculated from an angle.

I agree that it sounds good to leave the door to hw acceleration open. 
For start it may be enough to just mention that possibility in the 
documentation, without specifying the exact error range. Vast majority 
of users won't probably be very concerned about invisible value nuances.

Thanks,
Pavel

>
>
>> 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).
> This interpretation works for me. Anyone else?
>
>     Martin
>