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 closedform. 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, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
