+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 <gsterijev...@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.dunn...@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 <gsterijev...@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.dunn...@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 < > > > > gil...@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. > > > > > > > > > > > > > > >
