commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Date Mon, 01 Aug 2011 14:55:28 GMT


----- 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 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
> 
> 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 re-code 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, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message