Jean-Paul Pelteret

I think that's fair enough. I started using this in an outside project pre-documentation, so I was simply surprised that it did not work "as expected". I'm happy to adjust...

@luca-heltai Ping (relates to our desired implementation of wrappers for `LinearOperator`s and linear algebra in general).

> If you need to represent that, we would have to create a new representation and classes that support that. > The same with non-commutative algebras --- they require a...

@certik @isuruf Thanks for being willing to consider this as a future enhancement. I had originally got the impression that it really wasn't a viable option, so I appreciate that...

Thanks a lot for the tips @certik . I've skimmed over them, but will take a deeper look again when I'm thinking about giving an implementation a go.

> For expressions, we have a wrapper that implements the operator overloading: Ah, thank you for this reminder. @isuruf mentioned the `Expression` class at some point but I'd forgotten about...

Ok I will do so. For the purposes of review I would be happy to split the implementation into smaller PR's.

I'm busy looking through the code right now, but I have a small comment about the way that the linear operators are being used. I don't think that we envisioned...

This is the set of calls that lead to the construction of the final linear operator: - `operator-`: https://github.com/dealii/dealii/blob/master/include/deal.II/lac/linear_operator.h#L463 - negation of second operator: https://github.com/dealii/dealii/blob/master/include/deal.II/lac/linear_operator.h#L505-L532 In the negation (scaling by...

I don't think that's going to work (at least, not without some refactoring if it is at all possible). There are constructors for the `TrilinosPayload` that build these maps rather...