-
Notifications
You must be signed in to change notification settings - Fork 10
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
Homogenize Regularizer Interface #66
Comments
One idea we had in regards to the shape/size keyword is to move it out of the regularization terms and into the solvers. Then the prox! call can be invoked with a reshaped array. For the reg. terms that just perform element-wise this has no effect and the other terms we have atm would apply the reshape anyways. A default value for the shape could then be size(A,2) or size(AHA, 1) respectively and if multidimensional solutions are wanted then a user can supply the (for example image) size |
Interesting idea. But I do think there is some logic to keeping the shape in the regularizers. E.g., if you have 5D data, say, 3 spatial and 2 other dimensions, it might make sense to have the flexibility to have a 2D TV along those extra dimensions, or, instead, do an LLR along the last to concatenate. I had in mind to change the LLR code to take the full reshape size and a |
yes, if only a subset of dimensions is to be considered, we should use the |
Just to keep track of things: There are a few inconsistencies between regularizers that we should maybe fix. To get a list started:
LLRRegularization
takes the image size as the parametershape
, i.e. without extra (time) dimension. In contrast,TVRegularization
takes the full matrix size.LLRRegularization
is applied along the last dimension, whileTVRegularization
takesdims
as a parameter.The text was updated successfully, but these errors were encountered: