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.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
