Config option part II

[schmidtjonathan]

Following our discussion in the last software meeting (see #509), the question arises how to call a config option that controls whether or not products of linops.Matrix operators are contracted or not. More concretely:

import numpy as np
from probnum import linops

A = np.random.rand(2, 4)
B = np.random.rand(4, 3)

A_op = linops.Matrix(A)
B_op = linops.Matrix(B)

# Case 1 (as is):
A_op @ B_op  # ~~> ProductLinearOperator(factors=(A_op, B_op))

# Case 2 (we want this as an optional alternative):
A_op @ B_op # ~~> linops.Matrix(A @ B)

Same applies to the case in which A_op XOR B_op is a linops.InverseLinearOperator.

One proposal would be to inherit the name lazy_linalg due to the fact that this option does literally control lazy vs. non-lazy evaluation (Case 1 vs Case 2 from above). I.e. lazy here means that computations are not evaluated immediately but only at the point where the result is queried.

The existing lazy_linalg would be substituted by a different option which controls whether linops are created with dense numpy arrays or as sparse linops, e.g. linops.Scaling(some_vector) vs. linops.Matrix(np.diag(some_vector)).
We could e.g. call this option dense_markov_transition_matrices.

[schmidtjonathan]

@JonathanWenger , @pnkraemer , @nathanaelbosch , I would be grateful for your opinions! :)

[mmahsereci]

Thanks @schmidtjonathan , just a friendly reminder to put the code snippet with the bug/ original motivation somewhere such that we create a habit to document and work backwards from concrete features requests that allow us to backtrack in the future.

[schmidtjonathan]

I'm not entirely sure what you mean by "putting the code snippet somewhere" . Do you mean that I should transform this discussion into an issue?

[mmahsereci]

The code snipped above describes the functionality you would like to see added and intends to facility a discussion around how this should be done. But it does not describe why it should be done. Could you add an example which showcases why the current functionality is not enough, e.g., an example which is slow because of the current way linear operators are executed, or any example that prompted you to think about adding this functionality in the first place. Working backwards like this is important for long term maintenance, otherwise it is quite hard to backtrack and make changes in 1 year time :) You can add the code snipped to a new issue (preferably) and we link it here, or just add it to this discussion.

[schmidtjonathan]

Thank you for taking the time to explain your request, @mmahsereci !
See #509

[schmidtjonathan]

Decision:
new option that controls lazy vs. immediate Matrix @ Matrix operations: lazy_matrix_matrix_matmul (default = True)
(existing) option that controls whether or not LinearOperators are created / used in the first place: matrix_free_linalg (default = False)