----- Mail original ----- > > > -----Message d'origine----- > De : Phil Steitz [mailto:phil.ste...@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-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
