-
Notifications
You must be signed in to change notification settings - Fork 106
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
Conversation
ee390bf
to
8baecd3
Compare
|
||
-Laplacian(x) = b | ||
|
||
where b is a gaussian peak at the origin. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wrong
Code now works properly and gives a decent result. Ready for review. |
""" | ||
|
||
def forward(inp, out): | ||
out[:] = op(inp).asarray() |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
A comment regarding naming: The term |
I think it looks very good. Regarding the naming: I'm not sure I like |
I'll actually invite @SteveDiamond to please give some input here. What would you like the function currently called |
How about |
Good suggestion, I like it. Do we agree? |
I think |
I think it sounds like a good name. |
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.
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.
OK.
Sounds good to me.
I guess you mean the |
# 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requires
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 |
There was a problem hiding this comment.
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.
Fixed all comments. Merge? |
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. |
There was a problem hiding this comment.
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?
Some minor points, good for a merge after that. |
\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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
occasionally ("s", not "t")
Preliminary work on adding a CVX interface to ODL.
The backend is now available here: proximal-lang.org and on github: ProxImaL
Todo:
proximal
as an optional dependency to ODL.README.md
and to the full doc.