Rename solvers package and move functionals

[mehrhardt]

Why are functionals part of solvers, e.g. odl.solvers.L1Norm? To me functionals should probably have their own category (or at least some non-contradicting category).

[adler-j]

Well the rationale was that we use them with solvers, but your point is actually quite valid, it would feel more natural to access them as odl.functionals.L1Norm.

What do we feel about such a change @aringh, @kohr-h?

[aringh]

The rationale is what @adler-j wrote. I have no strong opinion in the question, but moving sounds like a good idea :-)

[kohr-h]

Part of the rationale was to not clutter the top-level namespace more than necessary. Let me give you some details about this.

The overall structure of ODL currently looks like this:

odl
 |
 |-- set  *
 |-- space  *
 |-- operator  *
 |-- discr  *
 |-- trafos
 |-- tomo
 |-- solvers
 |-- phantom
 |-- util
 |-- deform
 |-- ufunc_ops

Everything with a * at the end is considered part of the "core" in the sense that all names that are exposed in any of those modules (including submodules) in __all__ are available at top level. Therefore you can write odl.IdentityOperator instead of going down to odl.operator.default_ops.

However, one namespace can only hold a certain amount of names before it gets hopelessly cluttered. For that reason, all the subpackages have their own namespaces that are not added to the top level. For example, you need to type odl.trafos.FourierTransform -- it actually resides in odl.trafos.fourier but for convenience it's imported up to odl.trafos, not all the way to odl though.

Now, in the case of functionals, there are so many that they would lead to a significant amount of clutter if we would simply dump them to top level. Therefore I'm not in favor of making them part of the core in that sense.
The alternative would be to put them into their own subpackage functional (without "s") together with the prox stuff and all that. I'm not so sure about that either, much of it is strongly related to convex optimization, and taking it out of that context feels wrong. There is also the silent assumption that all functionals are convex which clearly makes more sense if you put them together with other convex optimization stuff.

What we could alternatively think about would be a rename of solvers to optim or something like that. That would at least remove the association "everything in here is a solver", which is not true anyway.

[kohr-h]

Any new insights here? I just want to mention that there's a related unsolved (although closed) issue #637, namely where to put concrete operators that depend on substantial parts of the library. For example operators that use the Fourier transform (not mentioning names here) which itself depends on a fair amount of stuff.

So one way of doing these two things together would be to add a subpackage like oplib or so, where we just add implementations of all kinds of operators (and functionals then) that do not fit well elsewhere due to dependence on stuff.

What do we think about that?

[adler-j]

I need to think more about this, but I feel that the two most promising options would be

• Rename solvers to optim, to show the generality better
• Move the functionals to a top level of ODL, i.e. odl.functionals.L1Norm

I am personally against having "arbitrary" operators mixed up with the functionals in the same library since this would (at least to me) be somewhat confusing.

[adler-j]

Do we have any further discussion on this? I agree that this naming is perhaps bad and we should think about it before 1.0

[kohr-h]

I'm all for the change to optim anyway.

Regarding placement: I think an intermediate solution would be to keep the structure as-is and just do from .optim import default_functionals as functionals in the top-level __init__.py to make them available as odl.functionals.L1Norm and such.

[mehrhardt]

I like the answer of @kohr-h. Then the code is still structured well and can be accessed easily in an intuitive manner.