Hi Thomas, and thanks for digging into that! > > looking at the rationale behind RealLinearOperator I understand this > class is used to calculate either: > > y = A x > y = A^T x > Not exactly. For the time being, RealLinearOperator only provides the method RealVector operate(RealVector), which performs y = A.x.
I agree with you that any linear operator is "transposable" (don't even know whether this word makes sense in english). However, RealLinearOperator have been implemented for operators which are *not* known in closed-form. In other words, I do not know how to access efficiently the (i, j) coefficient, but I *do* know how to compute efficiently A.x. There might be some cases where computing A'.x would still be difficult. I do not have an example here, but that's the reason why initially RealVector operateTranspose(RealVector) was not put in the RealLinearOperator abstract class. > > The specialized class InvertibleRealLinearOperator further allows for the > calculation of: > > y = A^-1 x > right. > > @Alt1: you ask about operators which are both invertible and > transposable, but the two properties do not collide imho, at least as > long as you do not want to calculate something like y = A^T^-1 x > That's true. So are you suggesting I should write three specialized classes InvertibleRealLinearOperator, TransposableRealLinearOperator, InvertibleAndTransposableRealLinearOperator? > > And in that case, wouldn't it be better to create a RealLinearOperator > object with A^T as parameter? > Not sure I really follow, but I already thought of passing *two* RealLinearOperators to the LSQR solver, which requires A and A^T. However, LSQR would be out of the IterativeLinearSolver hierarchy in that case, since the typical signature in this hierarchy is RealVector solve(RealLinearOperator, RealVector), and LSQR would require RealVector solve(RealLinearOperator, RealLinearOperator, RealVector) > > @Alt2: if the solve method relies on an operator to provide > operateTranspose than it should be checked on compile time imho. > Agreed. I do not like the "tagging interface option". > > Assuming that any matrix A should be transposable, I would opt for > alternative 3 and provide the operateTranspose method. Do you have a > case where an operator would not be transposable? > > Thomas > I've actually started playing around with this option. Added RealVector operateTranspose(RealVector) to the RealLinearOperator abstract class. This method would be defined as "optional" in the Javadoc, with the option to throw an UnsupportedOperationException. I also thought about boolean isTransposable() to check at execution time that operateTranspose() has indeed been implemented. Not sure this method is absolutely necessary, though. Would be glad to read your thoughts! Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
