Hi, > >> That's true. So are you suggesting I should write three specialized classes >> InvertibleRealLinearOperator, >> TransposableRealLinearOperator, >> InvertibleAndTransposableRealLinearOperator? > > not really, I think such a structuring would create more confusion and > problems in the long run than make up for the subtle differences that it > may model right now. > I agree. In fact, I'm now toying with the idea of removing InvertibleRealLinearOperator. I initially introduced this abstract class to handle preconditioners. In fact, if m is the preconditioner, instead of passing m to the solver (and calling m.solve(y)), I could just as well pass mInv = m^(-1) (and call mInv.operate(y)).
> > Together with the comment from Ted, I think this is the best way to go. > The isTransposable method may not be needed after all, I would be happy > with a checked exception in case someone uses operateTranspose and it is > not supported by the operator. > Like Ted, I like UnsupportedOperationException, and do not really like catching unchecked exceptions. I hope you do not dislike the isTransposable() option too much? Last question (***to native english speakers***): I'm not sure isTransposable() really means what I would like it to mean. What do you think of boolean isTranspositionSupported()? Likewise, is this name OK RealVector operateTranspose(RealVector) considering that application of the real linear operator a is called RealVector operate(RealVector). Thanks for your help, Sébastien > > Thomas > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
