commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <gsterijev...@gmail.com>
Subject Re: [MATH] Re: Pivoting QR Decomposition: Take Two!
Date Thu, 06 Oct 2011 00:06:02 GMT
I am sympathetic to this point of view [one class two algorithms-Ted's
point], but it seems like a step into the C world. Could we not accomplish
the same through some factory method? We can have two classes, but the user
might only get a reference to the abstract base. The other reason is that
the implementations are quite dissimilar. The current QRDecomposition class
works on the transpose of the A matrix. Luc's implementation works on the
data matrix in the original shape. Furthermore, the solver classes exhibit
differences imposed by pivoting and the transpose vs non transpose
difference.

I am also of the mind we should keep both classes. Speed is a big issue,
especially if one is making the case (as Luc has) that java is competitive
to fortran. I do think it might be a good idea to refactor (if possible) the
Marquardt class. The decomposition is identical.

Does it make sense to push the code for further comments or should I attach
it and the tests to this email thread?

-Greg

On Wed, Oct 5, 2011 at 3:46 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> Actually, I think it really would be nicer for the user to have one class
> that internally decides which implementation to use.  The user doesn't see
> this as two classes.  They see it as a single operation (QR decomposition)
> that might have a little different behavior (default slow and featureful,
> optionally faster).
>
> On Wed, Oct 5, 2011 at 1:38 PM, Gilles Sadowski <
> gilles@harfang.homelinux.org> wrote:
>
> > From what I understand, the user will know whether he needs speed or the
> > more flexible (but less efficient) alternative.
> > Thus it is fine to have two implementations in separate classes: The user
> > instantiates the one he needs.
> > We could name them "PivotingQRDecomposition" and "FastQRDecomposition" in
> > order to emphasize their expected usage.
> > Any potentially duplicated code should go in a new
> > "AbstractQRDecomposition"
> > which the other two will inherit from.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message