I meant "compilation problem"...
Le 9 septembre 2011 09:37, Sébastien Brisard
<sebastien.bris...@m4x.org> a écrit :
> OK, thank you Luc. We are still doing some refactoring in the linear
> package. If this induces compilation of the ode package, I'll let you
> know.
> Sébastien
>
> 2011/9/9 Luc Maisonobe <luc.maison...@free.fr>:
>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
