Config option naming

[schmidtjonathan]

In the context of PR #479 , a new configuration option prefer_dense_arrays is established, which controls whether or not LinearOperators are used (wherever possible) instead of dense arrays, in order to speed up (lazify) linalg-based computations.
For now, the option is only used in the statespace.IBM (integrated Brownian motion process), but its use will be extended rather sooner than later.
Since this option is one that might be relevant beyond the scope of statespace, filtsmooth, etc. , I wanted to ask for your opinions regarding naming and default value.
@pnkraemer and me would propose:

name = prefer_dense_arrays
default = True

If you have an opinion on this, feel free to propose changes. Otherwise we would merge this in the following couple of days.

[schmidtjonathan]

@JonathanWenger @marvinpfoertner @nathanaelbosch FYI

[JonathanWenger]

So to me there are two parts with linear operators:

• their arithmetic is lazy
• they provide memory-efficient matrix-vector products

In that way lazy_linops is somewhat of a misnomer, since it is not the linear operator itself that is lazy (its action is computed immediately if you execute A @ x, but rather the arithmetic.

How about one of the following options:

• prefer_linops
• lazify_with_linops
  and clearly write into the config docstring the properties of linear operators.

[schmidtjonathan]

I also like lazy_linalg, for the alliteration alone. 😄 Even though, I get your point, @pnkraemer , I also prefer lazy_linalg over lazy_linops.

prefer_linops is also nice, but less expressive, probably.

[schmidtjonathan]

How about we vote? (You should be able to edit my comment, just add your initials after the ":")

• prefer_linops :
• lazy_linalg : JS
• lazify_with_linops : JS
• matrix_free_linalg : JW, MP

[marvinpfoertner]

How do you guys feel about matrix_free_linalg? I think this describes exactly what we want to say while also using established terminology

[pnkraemer]

I see all your points. I would say my concern (that *_linalg sounds like it belongs only to probnum.linalg) is weaker than the concern with *_linops (because this does not really fit the scope of what is happening -- linear operators may be more general than that) or *_arithmetic` (I see that this might not 100% capture linop-vector interaction).

In light of this, I am fine with both lazy_linalg, and matrix_free_linalg.