commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tanguy Yannick" <>
Subject RE: [math] Adding a new class to handle Matrix with 3 columns/rows
Date Thu, 28 Jul 2011 16:23:50 GMT
On 7/27/11 7:30 AM, Gilles Sadowski wrote:
>> Hello.
>>>>> In project SIRIUS (CNES), we have some need for a Matrix33 (3 
>>>>> columns,
>>>>> 3
>>>>> rows) object. It is very common to use this kind of matrix to
>>>>> rotation to a position vector (vector3D).
>>>>> The incompatibility between the Vector3D of geometry package and 
>>>>> the matrix/vectors of the linear package is a lack that we propose

>>>>> to fill by creating a "Matrix33" in the geometry.threed package.
>>>> Looks finie to me.
>> Except for the name: "Matrix33" -> "Matrix3D".

+1 : ok to call it Matrix3D.

>>> [...]
>>>>> We will also propose some new constructors to build gaps between 
>>>>> this new matrix and the matrix of linear package.
>>>> Yes, having a way to change from one view to the other is a clear
>>> Yes, we prefer to add a constructor from Array2DRowRealMatrix and a 
>>> getter (that returns a Array2DRowRealMatrix) than to implement the 
>>> whole interface RealMatrix
>> There are not that many methods. It's preferable to implement
>> lest there will be two API eveolving independently.

The key point here is that the matrix from linear package are not
compatible with Vector3D. 
-> This is the main point we wanted to solve by creating a new matrix
So we have imagined three solutions : 
a) inherit the RealMatrix, but we need to add a multiply(Vector3D v)
method and some other methods
b) create an adapter class which contains an Array2DRealMatrix : this
may be heavy because we need to implement other methods
c) create a rather small class with only a few methods that answer our
needs (multiplication with Vector3D, transposition, ...). This class
should also implement a specific constructor and a specific getter to
fill the gap with the RealMatrix.
The other advantage of the c) solution is that it allows to implement
faster operations. 


>> I'm sure that somebody will help implement the missing bits if
>>> (or inherit the AbstractMatrix).
>> At the moment, I tend to agree on this point, given what I've just 
>> observed with this benchmark:
>+1 - the difference is expected, since AbstractRealMatrix has to use
>getters/setters and Array2DRowRealMatrix can do direct array access.  I
guess to maximize reuse a) the array-based operations could be extracted
into a static utils class somewhere and used by both impls or b) the new
class could extend Array2DRowRealMatrix.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message