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. > > > > > > > > > >
