commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject [math] Matrix decomposition API
Date Sat, 29 Nov 2008 23:51:25 GMT
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.


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

View raw message