Sorry Ted, I was not very clear in my explanations.
solve does return a RealMatrix. Internally, it builds BlockRealMatrix, though.
The issue is that Luc needs the underlying double[][] array in this
ODE application. This you could easily get if the returned matrix were
a Array2DRowRealMatrix, and you could have something along the lines
{code}
RealMatrix x = decomposition.getSolver().solve(new
Array2DRowRealMatrix(b, false));
if (x instanceof Array2DRowRealMatrix){
return x.getDataRef();
} else {
return new Array2DRowRealMatrix(x.getData(), false);
}
{code}
but this hack is of no use here, since it turns out that the
decomposition solver being used here *always* returns a
BlockRealMatrix (as an Array2DRealMatrix). So basically, deep copy of
x through x.getData() will *always* occur. That's what is worrying me.
I hope I do make my point, now.
Sébastien
2011/9/9 Ted Dunning <ted.dunn...@gmail.com>:
> Why doesn't solve just return a RealMatrix? Why does it insist on returning
> an Array2DRowRealMatrix?
>
> Does the user really care?
>
> 2011/9/8 Sébastien Brisard <sebastien.bris...@m4x.org>
>
>> Hi Luc,
>> thanks for your detailed explanations attached to the MATH-659. I'm
>> worried about the changes I have applied to the code, now. Here is
>> what I've done. I've replaced the following line
>> {code}
>> return new Array2DRowRealMatrix(decomposition.getSolver().solve(b), false);
>> {code}
>> with
>> {code}
>> RealMatrix x = decomposition.getSolver().solve(new
>> Array2DRowRealMatrix(b, false));
>> return new Array2DRowRealMatrix(x.getData(), false);
>> {code}
>>
>> decomposition is in fact an instance of QRDecompositionImpl.Solver,
>> whose method solve(RealMatrix) returns a BlockRealMatrix, not an
>> Array2DRowRealMatrix, hence the ugly last line. This code seems to be
>> correct (unit tests still pass), but I'm worried about the efficiency,
>> especially if initializeHighOrderDerivatives is called very often.
>> What do you think should be done?
>>
>> Best regards,
>> Sébastien
>>
>> ---------------------------------------------------------------------
>> 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
