Affine transforms - matrix algebra

[Pavel Safrata]

Kirill,
we don't really need to discuss this because the element properties are 
already there (for years) so we cannot change that anyway.
Regards,
Pavel

On 12.7.2012 14:08, Kirill Prazdnikov wrote:
>
> Transformation matrix consist of four vectors. In case of affine, it 
> is coordinates of local orts + translation.
> Accessing this vectors is the most get/set use-case.
> I can not imagine where accessing individual matrix values could be 
> used (useful) at all.
>
> Does anybody uses it ?
>
> -Kirill
>
> On 12-Jul-12 15:23, Pavel Safrata wrote:
>> I like the get(row, col) method, I think we can introduce it in 
>> addition to the array conversions. Similarly we can add set(row, col, 
>> value). Both just convenience methods internally calling the actual 
>> property getters/setters.
>>
>> Pavel
>>
>> On 12.7.2012 11:05, Martin Desruisseaux wrote:
>>> The array methods may also be useful for working on matrix 
>>> coefficients using indices rather than hard-coded access to the mxx, 
>>> mxy, etc. properties. For example: when the affine may contain 
>>> scale, rotation, flip and translation but no shear, at least in the 
>>> 2D case (I think it works in 3D too), we can compute the scale 
>>> factors "as if there were no flip or rotation" by computing the 
>>> square root of the sum of the square of all values (except 
>>> translation) on a row or a column. Whatever we compute on rows or on 
>>> columns depend on whatever we want the scale factors to be expressed 
>>> relative to the axes of the source coordinate system or the target 
>>> coordinate system (this is not the same if there is a rotation). For 
>>> this kind of computation, looping over an array using indices - or 
>>> alternatively providing a Matrix.get(row, column) method - is 
>>> convenient.
>>>
>>>     Martin
>>>
>>>
>>> Le 12/07/12 08:35, Pavel Safrata a écrit :
>>>> Hi Kirill,
>>>> you are not right with the performance, the elements are (possibly 
>>>> invalid) properties so we need to call all the getters anyway, plus 
>>>> construct the array, so the performance is actually worse. But the 
>>>> use-case seems to be valid, especially if the other libraries 
>>>> support such conversion. I just wouldn't call it 'asArray' which 
>>>> suggests that the array will keep updating with the matrix changes 
>>>> but rather 'toArray'. To be consistent we need to use doubles 
>>>> instead of floats and we should also add a similar setter. So I 
>>>> propose:
>>>>
>>>> public double[] toArray()
>>>> public double[] toArray(double[] a)
>>>> public Affine(double[] matrix)
>>>> public void setTransform(double[] matrix)
>>>>
>>>> Where the first two will behave similarly as if it was a List of 12 
>>>> doubles, the latter two will throw IllegalArgumentException if 
>>>> length of the array is not 12.
>>>>
>>>> Regards,
>>>> Pavel
>>>
>>
>>
>