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