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 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.
A few more thoughts. If I understand correctly, you propose is to
separate the decomposition part in an interface with a decompose method
and the solver part as the interface returned by this decompose method.
We would have two parallel hierarchies of interfaces/classes:
interface DecompositionEngine {
public DecompositionSolver decompose(RealMatrix);
}
interface XYZEngine extends DecompositionEngine {
public void setThreshold(final double threshold) {
this.threshold = threshold;
}
public XYZDecomposition xyzDecompose(RealMatrix matrix) {
XYZDecomposition decomposition = new XYZDecompositionImpl();
decomposition.setThreshold(threshold);
decomposition.doWhatYouWantWithMatrix(matrix);
return decomposition;
}
public DecompositionSolver decompose(RealMatrix matrix) {
return xyzDecompose(matrix);
}
}
interface DecompositionSolver {
public RealVector solve(RealVector);
}
interface XYZDecomposition extends DecompositionSolver {
public void setThreshold(double threshold);
public RealMatrix getX();
public RealMatrix getY();
public RealMatrix getZ();
}
class XYZDecompositionImpl() implements XYZDecomposition {
}
This allows both dedicated use of a specific algorithm (XYZ) and the
extra methods it provides (setThrehold, getX ...) and use of generic
interfaces (DecompositionEngine, DecompositionSolver) and the generic
methods (solve, getInverse ...). It is however quite complex.
A simpler approach is to remove the umbrella interface
DecompositionEngine and the generic decompose method and retain
everything else (perhaps reusing the single name "decompose" for the now
independent methods with different return types). The
DecompositionSolver interface would be kept. This prevents use of a
generic engine.
An even simpler approach would be to completely remove the state
dependencies part by removing the decompose method and forcing
everything to be set up right at construction. I'm not sure you would
consider it addresses your second point.
Luc
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
