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