You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tanguy Yannick <Ya...@cnes.fr> on 2011/08/01 15:23:29 UTC
RE: [math] Adding a new class to handle Matrix with 3 columns/rows
-----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.
Best regards
Yannick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by Tanguy Yannick <Ya...@cnes.fr>.
>
>> 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
You are right, BlockRealMatrix is even more efficient : 4x faster than
our implementation, and 6x faster than the Array2DRowRealMatrix for big
Matrix...
Yannick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Adding a new class to handle Matrix with 3 columns/rows
Posted by lu...@free.fr.
----- 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