commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Matrix decomposition API
Date Tue, 02 Dec 2008 21:00:11 GMT
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
> interfaces - i.e., having the interface contract include the requirement
> that decompose() be called before the getters.  Logically, the
> decomposition interfaces should just *be* the getters, which is now the
> case for EigenDecomposition, but not LU (where the interface includes
> the decompose method).   The state dependency is an implementation
> artifact that should not be included in the decomposition interface.
> 2) It would seem natural for decompose return a decomposition, rather
> than void.
> I am not sure if there is an efficient way to address both of these,
> since the caching and incremental computation in the current impls is
> sort of essential.  At a minimum, we should probably remove the
> advertised exceptions and decompose methods from the interfaces.
> Here is one idea that may or may not work.  It would make the API a
> little more complicated, but if we split the implementation classes into
> decomposers and decompositions, with decompose producing a
> decomposition, the decompositions would be able to handle state
> transparently to users.

I will try to introduce this.
Thanks for the advice.

> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message