On 7/28/11 9:23 AM, Tanguy Yannick wrote: > 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 > apply >>>>>> 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 > need. >>>> 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 > "RealMatrix" >>> lest there will be two API eveolving independently. >> +1 > 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 > class. > 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.
How, exactly, do you expect to be able to improve speed in a way that would not apply to Array2DRowRealMatrix? If there are faster implementations of the direct array-based operations we should make them available to both classes. Having an extra set of matrix ops to maintain just for 3x3 matrices does not sound like a happy prospect to me. Phil > > Yannick > >>> I'm sure that somebody will help implement the missing bits if > necessary. >>>> (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. >> Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
