 Mail original 
>
>
> Message d'origine
> De : Phil Steitz [mailto:phil.steitz@gmail.com]
> Envoyé : jeudi 28 juillet 2011 18:32
> À : Commons Developers List
> Objet : Re: [math] Adding a new class to handle Matrix with 3
> columns/rows
>
>
> >> 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 arraybased 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
>
> Sorry I made a mistake about the performance of matrix multiplication
> (see below). Nethertheless, the problem of performance is secondary,
> since the first reason why we want to add a new Matrix3D class is
> that the generic implementation is not compliant with Vector3D from
> geometry.euclidian.threed package.
>
> Here are some observations we made about performance while operating
> small or big matrix.
>
> We made several tests because in our softwares, we use either small
> matrix (3x3 or 6x6) to handle position & velocity of a spacecraft or
> very big matrix (hundreds or thousands of lines & columns) in some
> orbit restitution tools.
> For 3x3 matrix, it's possible to remove the triple loop, by writing
> directly the 9 sums of products from A & B matrix coefficients. Of
> course, it's not possible for generic matrix. In our old software in
> Fortran, it could save about 17% compared to the generic "matmul"
> intrinsic fonction. We made some benchmark in Java and obtained a
> gain of about 25%. But the Commons Math implementation is still
> faster ! And Commons Math is twice as fast as the triple loop
> implementation.
> > So for small matrix, there's no need to recode matrix operations
>
> For very big matrix (ie : beyond 500 or 1000 rows/columns), the
> computation is faster if you transpose the second matrix and then
> multiply. The two inner loops are inversed and it allows a
> significant gain for very big matrix (about 40% compared to Commons
> Math for 1000x1000 matrix, and 50% compared to the classical triple
> loop). I guess that it's faster for the JVM to access the matrix
> coefficients in the computer's memory.
For large matrices, did you compare with BlockRealMatrix ? It was specially
designed to improve caching. This is the reason why when you build a matrix
using the various factory methods MatrixUtils.createRealMatrix (or createFieldMatrix),
there is a test about the dimension and either an Array2DRowRealMatrix or a
BlockRealMatrix is created. The current threshold has been set to 4096 elements,
but this was an almost arbitrary choice.
best regards,
Luc
>
> Best regards
>
> Yannick
>
> 
> To unsubscribe, email: devunsubscribe@commons.apache.org
> For additional commands, email: devhelp@commons.apache.org
>
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
