Luc Maisonobe wrote:
Phil Steitz a écrit :
I noticed a breakage in one of my apps that uses
MatrixUtils#createRealMatrix(double[][], boolean). This method seems to
have been removed. I guess this is because DenseRealMatrix can't
support this. I understand the value of DenseRealMatrix, but I still
see value in the double[][]-backed RealMatrixImpl. Any objections if I
restore the method above, change the other factories to return
RealMatrixImpl instances as before and add createDenseMatrix()
methods? I would also be OK with deprecating the createRealMatrix()
methods and adding CreateXx methods for both versions.
I don't feel comfortable with this approach. The boolean parameter was
merely an optimization feature avoiding a copy. However, it implicitely
relied on one implementation only (RealMatrixImpl) and exposed an
internal array. As far as I understood, the factory methods in
MatrixUtils were used to hide the implementation. If they become
implementation-specific, I don't see the added value for factory methods
versus class constructors.
The problem is we now have multiple implementations so
createRealMatrix(..) may not make sense anymore. That is what I meant
by moving to createXx, etc. I guess on second thought I think we should
leave as is (in trunk) and deprecate the create methods.
Nevertheless, my concerns are minor ones. Feel free to bring these
methods back if you consider there is a need for them.
In the same spirit, I am currently testing another block layout using
blocks size in a range rather than fixed size and recursive layout. This
is roughly an implementation based on Chatterjee, Lebeck, Praveen and
Thottethodi paper "Recursive Array Layouts and Fast Matrix
Multiplication" (http://www.cs.duke.edu/~alvy/papers/matrix-tpds.pdf).
If the performances are good, I will use this layout for DenseRealMatrix.
Cool!
Phil
Luc
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
