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:28:21 GMT
+1 from me as well.  They are a lot of what makes guava so nice to use.

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

> What is the group's feeling on factory classes? +1 from me (obviously)
>
> On Wed, Oct 5, 2011 at 7:14 PM, Ted Dunning <ted.dunning@gmail.com> wrote:
>
> > 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