You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2009/02/07 20:34:32 UTC
[math] RealMatrixImpl, DenseRealMatrix and MatrixUtils factory methods
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] RealMatrixImpl, DenseRealMatrix and MatrixUtils factory
methods
Posted by Phil Steitz <ph...@gmail.com>.
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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] RealMatrixImpl, DenseRealMatrix and MatrixUtils factory
methods
Posted by Luc Maisonobe <Lu...@free.fr>.
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.
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.
Luc
>
> ---------------------------------------------------------------------
> 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