Ted Dunning a écrit :
> Is there really any point in separating out the QRSolver? Is it because we
> expect multiple QR decomposition implementations that could share the same
> solving code?
>
> If that is really necessary, why not just have AbstractQRDecomposition that
> has a solve method?
>
> Then the user sees this:
>
> RealVector solution = new QRDecomposition(... args... ).solve(constant);
>
> This is even simpler and makes much more sense to the user.
This is how the API was about two days ago ...
The fact is decomposition is not always used for solving linear systems,
it may be used for other purposes. Of course, LU and QR decomposition
are mostly used for decomposition but eigen decomposition and SVD are
mostly used for other purposes (they may even not use the matrices
themselves but only the largest or smallest eigen/singular values).
Separation really makes sense for them, so for global consistency
separation has been the rule for all.
The former API also had a bad mixing between decomposition and solve
states (and numerous IllegalStateException declaration because of that).
This was the starting point for separating decomposition from solving.
It is not the case anymore, though, partly due to this layered approach.
Reuniting decomposition and solving is possible. However, given that
EigenDecomposition is already almost 1600 lines long and will certainly
grow longer if we implement completely MRRR, I would prefer keep solve
features separate.
The drawbacks are the two objects the user needs to build, as you noted,
and also that some optimization cannot be done anymore. For example the
QRSolver now relies directly on Q and R matrices, not only on internal
structures and Householder vectors as before, which formerly allowed to
avoid building the matrices for solving.
Luc
>
> On Fri, Dec 5, 2008 at 2:25 AM, <luc.maisonobe@free.fr> wrote:
>
>> RealVector solution = new QRSolver(new QRDecomposition()).solve(constant);
>>
>>
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
