Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4E69C0B2.8060204@free.fr>
Date: Fri, 09 Sep 2011 09:30:58 +0200
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.15) Gecko/20110419 Thunderbird/3.1.9
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] use the more general super-type RealMatrix in place of
 Array2DRowRealMatrix in package ode?
References: 
 <CAGRH7Hq15zR9+YUWqFYCQQ0ZGFyvCDMMk4ru3Nmduua5pBOriQ@mail.gmail.com>
	<4E6919E1.3010905@free.fr>
	<CAGRH7HqYVkRkHTjGQA391GADknoipjHiPz9MA38TcpqcfTAzVQ@mail.gmail.com>
	<CAJwFCa1nBi-j+UBZsPc_ra9fU4=zzna25e+jT8LG=rHvnRrF1Q@mail.gmail.com>
 <CAGRH7HoKQ=3bS6RJ-LsfqfQEyGeitSUhPuEKqy_oq6oQS=s_uQ@mail.gmail.com>
In-Reply-To: 
 <CAGRH7HoKQ=3bS6RJ-LsfqfQEyGeitSUhPuEKqy_oq6oQS=s_uQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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.dunning@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.brisard@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-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