Hi.
> Sounds like it would be nice to have both implementations in the same class
> with a "usePivoting(boolean)" method to select which is used. I would
> recommend pivoting as the default since it gives fewer surprises and more
> diagnostic information to the naive user.
>
> Except for the extra indexing costs, a pivoting implementation should be
> about twice as costly as a non-pivoting implementation. If you don't do the
> pivoting by indirection, this could be significantly more due to copying.
>
> I haven't had instances where I would have much cared, but it would be nice
> to have the option for extra speed if I needed it.
>
> On Wed, Oct 5, 2011 at 10:52 AM, Luc Maisonobe <luc.maison...@free.fr>wrote:
>
> > 4. Implement the best algorithm as "QRDecomposition" in ("linear"), and
> >> remove duplicate code ("LevenbergMarquardt" will call the
> >> implementation
> >> in "linear"; if replacing the LM currently internal version makes some
> >> test fail, we should worry and look for the bug either in LM or in the
> >> new QR or in the tests).
> >>
> >
> > I'm not sure one implementation only is always feasible. The one I put in
> > Levenberg-Marquardt is perhaps more suited to some cases because of
> > pivoting, but I'm quite sure it is not as efficient as the classical one
> > which is really fast (I always used it as an example in conferences to show
> > that Java can be as fast as fortran in some application, because it is as
> > fast as lapack with ATLAS blas on matrices up to about 1000 rows and
> > columns).
>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.
I don't see that there would be any benefit in reviving a "QRDecomposition"
interface.
However, it would be nice to create another one:
---CUT---
public interface DecompositionSolverProvider {
DecompositionSolver getSolver();
}
---CUT---
which all "...Decomposition" would implement (all of them already provide
this "getSolver" method).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
