Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add as_cvx_operator and example #494

Merged
merged 5 commits into from
Aug 17, 2016
Merged

Add as_cvx_operator and example #494

merged 5 commits into from
Aug 17, 2016

Conversation

adler-j
Copy link
Member

@adler-j adler-j commented Jul 14, 2016

Preliminary work on adding a CVX interface to ODL.

The backend is now available here: proximal-lang.org and on github: ProxImaL

Todo:

  • Decide on style. Is this good?
  • Naming. This does not actually use CVX, but uses "proximal", which happens to be a not that good name for us. What should we name this?
  • Add proximal as an optional dependency to ODL.
  • Add documentation on the existence of this interface, both to README.md and to the full doc.

@adler-j adler-j force-pushed the cvx_interface branch 3 times, most recently from ee390bf to 8baecd3 Compare July 14, 2016 13:28

-Laplacian(x) = b

where b is a gaussian peak at the origin.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wrong

@adler-j
Copy link
Member Author

adler-j commented Jul 26, 2016

Code now works properly and gives a decent result. Ready for review.

"""

def forward(inp, out):
out[:] = op(inp).asarray()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use the out parameter


# --- Set up the inverse problem --- #

# Note that proximal is not aware of the problem scaling
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to be clarified. What I'm aiming at is that proximal is fully discrete and does not know of scalings for the norms etc, hence this may be missleading since users would assume grad is the same as the gradient in ODL, etc.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The gradient is a linear operator, right? So would it be possible to use the gradient from ODL by wrapping it in the same way as ray_transform -> cvx_ray_transform?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but then we would need to add asarray and shape to ProductSpaces, which is perhaps about time.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even after that, the norm operators would still differ.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true... so if it cannot be fixed maybe a clarifying comment about it is enough

@ozanoktem
Copy link
Contributor

A comment regarding naming: The term proximal is, as already mentioned by @adler-j, not suitable since we use it for other purposes. Since Python is case sensitive, we could perhaps consider using ProxImaL? Another alternative is CVXproximal.

@aringh
Copy link
Member

aringh commented Jul 28, 2016

I think it looks very good.

Regarding the naming: I'm not sure I like ProxImal. It still feels to easily confused with what we call proximal operators, if we have a method called as_ProxImal_operator. Then I think as_cvx_proximal_operator or something like that would be better (although it is not technically cvx. However, I guess the basic idea was first implemented here https://github.com/mfopt/mf_cvxpy, which is still called cvx)

@adler-j
Copy link
Member Author

adler-j commented Jul 31, 2016

I'll actually invite @SteveDiamond to please give some input here. What would you like the function currently called as_cvx_operator to be named? As mentioned above, the word "proximal" is already taken in ODL, so the obvious as_proximal_operator cannot be done.

@SteveDiamond
Copy link

How about as_prox_lang_operator? We call it the ProxImaL modeling language.

@adler-j
Copy link
Member Author

adler-j commented Aug 1, 2016

Good suggestion, I like it. Do we agree?

@ozanoktem
Copy link
Contributor

I think as_prox_lang_operator, as suggested by @SteveDiamond, is ok but not ideal. Since I cannot come up with a better alternative, I support using this suggestion.

@aringh
Copy link
Member

aringh commented Aug 2, 2016

I think it sounds like a good name.

@kohr-h
Copy link
Member

kohr-h commented Aug 9, 2016

I think the code is nice and simple, a good sign that ODL is extensible and does not lock in anybody. And I'm glad to see progress in the integration with ProxImaL.

Todo:

Decide on style. Is this good?

What alternatives do you have in mind? If you mean the interface, it's very similar to the SciPy linear operator interface, so we're consistent, which is good.

Add proximal as an optional dependency to ODL.

OK.

How about as_prox_lang_operator? We call it the ProxImaL modeling language.

Sounds good to me.

A comment regarding naming: The term proximal is, as already mentioned by @adler-j, not suitable since we use it for other purposes. Since Python is case sensitive, we could perhaps consider using ProxImaL? Another alternative is CVXproximal.

I guess you mean the import proximal statement in the beginning? I agree that this can lead to confusion with our internal proximal sub-package. Since we seem to have settled with prox_lang as infix in the function name, why don't we avoid the conflict by import proximal as prox_lang?

# The implementation of the ray transform to use, options:
# 'scikit' Requires scikit-image (can be installed by
# running ``pip install scikit-image``).
# 'astra_cpu', 'astra_cuda' Require astra tomography to be installed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requires

@kohr-h
Copy link
Member

kohr-h commented Aug 15, 2016

Since this is 80 % examples, they should be clear and have good comments. Therefore I was a bit picky there. Interface looks fine to me, and the selection of examples is also good.

@@ -11,8 +11,7 @@ Next release

New features
------------
- First implementation of a deformation model based on linearized deformations using displacement
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was moved to a 0.4.0 release in another PR.

@adler-j
Copy link
Member Author

adler-j commented Aug 17, 2016

Fixed all comments. Merge?

@ozanoktem
Copy link
Contributor

Yes, go ahead and merge :-)

>>> 1 / np.sqrt(3) # exact result
0.577350269189

this is not the case in proximal, where the norm depends on the number of discretization points. Hence a scaling that is correct for a problem in ODL needs not be correct in proximal. This also changes the definition of things like the operator norm.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you change all occurrences of "proximal" to "ProxImaL" where applicable?

@kohr-h
Copy link
Member

kohr-h commented Aug 17, 2016

Some minor points, good for a merge after that.

@adler-j adler-j merged commit a0f723e into master Aug 17, 2016
@adler-j adler-j deleted the cvx_interface branch August 17, 2016 09:01
\text{prox}_f(v) = \arg\min_x f(x) + (1/2)||x - v||_2^2


proximal is also occationally used instead of ProxImaL, then refering to the proximal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

occasionally ("s", not "t")

@kohr-h kohr-h removed the merge? label Sep 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants