commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joni Salonen" <joni.salo...@gmail.com>
Subject Re: [math] Q-R -decomposition
Date Sat, 01 Apr 2006 07:38:28 GMT
On 3/30/06, Phil Steitz <phil.steitz@gmail.com> wrote:
> Great!  The first thing to do is to open a Bugzilla ticket and attach
> the code to it, with that apache license in the class file headers
> (look at any apache java class for an example).   Ideally, you should
> also develop and include a test class.  Your main method could be the
> start of this.  Have a look at the RealMatrix test classes for
> examples.  We can talk further about design here on the list.   From a
> quick glance at your code, it looks like you have just implemented the
> decomp algorithm statically (which is a great start) and we should
> talk about how to structure the API, class name, numerical stability,
> and package placement.
>
I have created some tests now and included them in the bugzilla ticket.

It would seem most natural to implement QR in math.linear because
that's where the rest of the linear algebra related stuff is.
Initially I thought the algorithm, as it doesn't require state as
such, could be included in the RealMatrix or RealMatrixImpl class,
like the LU decomposition. But I'm not sure if that would be pushing
too many responsibilities to one class. What is your view on this?

I also had a look at Jama yesterday. There they defer the explicit
generation of the Q part of the decomposition until the user calls
getQ(), which I guess has a computational advantage over calculating
the whole decomp if the user of the API only needs R. This of course
implies that the algorithm has a state and it's most natural to
implement it as a class of its own.

>From the release plan I read that the QR-decomposition will be needed
for linear regression. Does that mean that it will be used mainly for
least-squares fitting? In that case both Q and R are needed most of
the time, so having the algorithm in a separate class is not strictly
necessary..

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message