On 3/30/06, Phil Steitz <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
