Le 09/09/2011 04:05, Sébastien Brisard a écrit :
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.
Yes, this is exactly the point.
In fact, this is also internal code user never sees. the matrices here
correspond to an internal state that is changed a very large number of time.
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.
Don't worry. As I wrote in the comment on this issue, this class is
under scrutiny for other changes due to other issues. I don't like
either being forced to use an Array2DRowRealMatrix. In fact I already
tried to remove them some months ago but failed, I had to go back to
this signature. I will make another attempt. As I may well change
completely the way the internal state is updated, I hope this will
naturally simplify things.
For now, just leave the multi step integrators classes alone (all
classes with Adams, Nordsieck and Multistep in their names, as well as
BDF when it will be committed later on), you would waste your time on them.
Luc
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
