commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [MATH] Re: Pivoting QR Decomposition: Take Two!
Date Thu, 06 Oct 2011 00:14:38 GMT
I think that a factory style is fine.  Sadly, CM uses constructor style a
lot and it may be hard to change that expectation.  I suppose that the QRD
constructor can call some other factory and just delegate to the results.
 Looks ugly but keeps the constructor style.  If losing the constructor
style is allowable then the factory is a great option.

Whether the two implementations exist in one class or two should be an
implementation detail that the user really doesn't see much or care about.
 No need to hide it, but absolutely no reason to put it in their face,
either.

Pushing WIP code is always good.

On Wed, Oct 5, 2011 at 5:06 PM, Greg Sterijevski <gsterijevski@gmail.com>wrote:

> 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