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?
>
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:
RealVecto
FWIW, I like the calling pattern with the static DecompositionSolver
too...
RealVector solution =
DecompositionSolver.solve(constant, new QRDecompositionImpl(matrix));
-sujit
On Fri, 2008-12-05 at 10:37 +0100, [EMAIL PROTECTED] wrote:
> - "Phil Steitz" <[EMAIL PROTECTED]> a écrit :
>
- "luc maisonobe" <[EMAIL PROTECTED]> a écrit :
> - "Phil Steitz" <[EMAIL PROTECTED]> a écrit :
>
>
> > Looks good. Just one last question / suggestion. In the
> > DecompositionSolver, why to we keep the argumentless decompose()
> > methods
> > and the matrix as an instance variabl
- "Phil Steitz" <[EMAIL PROTECTED]> a écrit :
> Looks good. Just one last question / suggestion. In the
> DecompositionSolver, why to we keep the argumentless decompose()
> methods
> and the matrix as an instance variable? The argumentless methods just
>
> delegate to the ones that ta
Luc Maisonobe wrote:
Phil Steitz a écrit :
Luc Maisonobe wrote:
Luc Maisonobe a écrit :
Phil Steitz a écrit :
There are a couple of things about the decomposition API that are
starting to bug me. Apologies for not having raised them until now,
since they apply t
Phil Steitz a écrit :
> Luc Maisonobe wrote:
>> Luc Maisonobe a écrit :
>>
>>> Phil Steitz a écrit :
>>>
There are a couple of things about the decomposition API that are
starting to bug me. Apologies for not having raised them until now,
since they apply to LU as well as the
Luc Maisonobe wrote:
Luc Maisonobe a écrit :
Phil Steitz a écrit :
There are a couple of things about the decomposition API that are
starting to bug me. Apologies for not having raised them until now,
since they apply to LU as well as the new Eigen decomp.
1) I don't like the state de
Luc Maisonobe a écrit :
> Phil Steitz a écrit :
>> There are a couple of things about the decomposition API that are
>> starting to bug me. Apologies for not having raised them until now,
>> since they apply to LU as well as the new Eigen decomp.
>>
>> 1) I don't like the state dependencies bleedi
Phil Steitz a écrit :
> There are a couple of things about the decomposition API that are
> starting to bug me. Apologies for not having raised them until now,
> since they apply to LU as well as the new Eigen decomp.
>
> 1) I don't like the state dependencies bleeding into the decomposition
> in
There are a couple of things about the decomposition API that are
starting to bug me. Apologies for not having raised them until now,
since they apply to LU as well as the new Eigen decomp.
1) I don't like the state dependencies bleeding into the decomposition
interfaces - i.e., having the in
11 matches
Mail list logo
