[QoL] Add Identity() as default linear in Sparsity prox

[MorganSchmitz]

Is your feature request related to a problem? Please describe.
opt.proximity.SparseThreshold requires a linear operator as input I think it'd be good to have a default set up.

Describe the solution you'd like
opt.linear.Identity would be the natural choice.

Are you planning to submit a Pull Request?

• Yes
• No

[sfarrens]

@MorganSchmitz This is a nice idea, but since linear is a positional argument it would mean changing every call to this class in every package that uses it.

An alternative would be to include a new linear operator object (e.g. just called Threshold) that uses Identity by default.

If this will work for you I can make a PR for this.

[MorganSchmitz]

Ah, I see the issue with just adding a default...

I am not sure I understand your suggested workaround though. Do you mean creating a whole new proximity operator that acts the exact same way as SparseThreshold, but comes with a default identity ``linear operator''?

If so, couldn't this get confusing for new users, who would not be sure which of the two they should use?

I guess another workaround would be to also add a default to weights, just set to 0. That way, a SparseThreshold instanciated with no parameters would just be identity, while still allowing for the (I'm guessing common) use case of passing on weights, but no linear operator? While not breaking any code that already relies on SparseThreshold.

[sfarrens]

@MorganSchmitz Yes, that should work fine, but I think it might be better to make None the default for weights so that an error (or warning) can be raised if nothing is provided. My only concern being that users might forget get to set the weights and thus the proximity operator is not really doing anything.

[chaithyagr]

If we plan to fix the cost operation, based on CEA-COSMIC/pysap-mri#80 , doesnt that mean we can remove linear_op from SparseThreshold and expect the call to cost function be fixed?
Although I understand that this is legacy code and the movement must be comparatively slower.

[sfarrens]

@chaithyagr Indeed. I will probably hold off opening a PR for this until we have a clear plan for how we want to handle the cost contribution from proximity operators.

[chaithyagr]

Yes makes sense..