Petar Mlinarić

I just tried, and `grep -rn '\.inner([^), ]*)' src/pymor` gives 79 results where `inner` is used with a single argument. Some can be easily converted to use the `product` argument,...

> I would rather not add a different caching mechanism to pyMOR. Is there a particular reason to not use pyMOR's caching? pyMOR's caching only works for immutable objects, right?...

How about implementing it as [`_sv_U_V`](https://github.com/pymor/pymor/blob/1bb68340ad4b0597a442ef086dd8c1cb23b27e90/src/pymor/reductors/bt.py#L43-L49)?

> Another option would be to change the `LTIModel.gramian` method, [...] It seems it used to be this way, but then we moved these Gramians to reductors for some reason...

> If these Gramians are more related to BT then they are to the `Model` itself, I would keep the code in the `bt` module. Right, that was one of...

So, I found it easier to add caching directly, as was there for `_sv_U_V`. I'm not sure how would one go about implementing a cachable `Gramian` class, I guess there...

Yes, you're right, there is nothing stopping a user from changing `self.mu`. The `GenericBTReductor` could be immutable and then `V` and `W` could be properties returning `_V` and `_W`. But,...

I remember @sdrave explained to me in an offline discussion the motivation for viewing greedy methods as pyMOR algorithms instead of reductors, but I forgot the details... I guess it...

> I like this modularity and would not fancy a `GreedyCoerciveRBReductor` (and all further combinations) or a `CoerciveRBSuperReductor` with tons of options for selecting and controlling various basis generation algorithms....

> For instance, one might distinguish between 'projectors' (which would correspond to my current idea of reductors) and 'reduction schemes'. > [...] > From my perspective, `rb_greedy` is _not_ a...