Affine transforms - matrix algebra

[Pavel Safrata]

On 11.7.2012 17:39, Martin Desruisseaux wrote:
> Le 11/07/12 16:57, Pavel Safrata a écrit :
>> If we are going this way, shouldn't we do also this?
>> * Rename 'concatenate' as 'prepend'
>> * Rename 'preConcatenate' as 'append'
> Yes, I think it would bring more uniformity in the method naming.
>
>> * Rename 'getConcatenation' as .. well .. 'getPrependage' :-)
> I missed that method... What would its function? Or are we are talking 
> about something like a 'getTransformCoefficients()' method?

This method is similar to concatenate (prepend) except that it is 
defined on parent Transform class and returns the result in a new 
Transform instance (allows for multiplicating arbitrary - possibly 
immutable - transfroms).

>
>
>> As a black-box transformation composing this makes sense. As a matrix 
>> algebra, it may be also confusing: tA.append(tB) means matrix 
>> multiplication 'B x A', does it sound good? Maybe yes, I'm not sure. 
>> Anyway, so far the best proposal I think.
> Yes, I realize that a risk of confusion may exist. We may need to 
> stress out in the javadoc that "append" is not "multiply". Indeed, if 
> the "append" method was defined in the parent Transform class and if 
> that parent was the base class of generic transformations (not just 
> linear transformations), then the "append" method would actually not 
> be implemented as a matrix multiplication except in the special case 
> of linear transformations.

I don't have any better idea. Writing a clear javadoc is probably the 
only thing we can do. As the methods will be defined only on Affine 
class, we should probably mention specifically the relationship with 
multiplication, maybe even a warning for J2D developers that this may 
work the other way than they're used to..

>
>
>>> I don't have experience in this area. But naively, it seems to we 
>>> that it would be better to be notified only after the full matrix 
>>> has been updated...
>> Yes, I would also pick this option. It's just that it would mean 
>> writing much more complicated (and a bit less effective) code so the 
>> question is whether or not you think it is important.
> I don't have a use case where I would like to listen to individual 
> coefficient changes. It seems to me that I would rather listen to 
> whatever property contains the Transform object as a whole. 
> Consequently, I don't think that the atomicity of Affine operations 
> would have much incidence (assuming that there is some way - other 
> than listening to individual coefficients - to be informed that the 
> matrix as a whole has changed).

Unfortunately I don't think there is a way to listen for changes on an 
object other than listening on all its properties. In my opinion this is 
quite a big issue and it's been bothering me for some time already. I've 
heard that some utilities are planned for that but still I want to file 
a feature request for some better mechanism, hopefully this email gives 
me the impulse to finally do it.

Anyway, I should probably not give up on the (quite obviously) better 
API just because of implementation complexity. Will try to make the 
changes atomic.

Thanks,
Pavel

>
>     Martin
>