The purpose of is_proximable / is_prox_accurate

[hakkelt]

In JuliaFirstOrder/ProximalOperators.jl#152 and #5 the function is_prox_accurate function was moved from ProximalOperators.jl to ProximalCore.jl and renamed to is_proximable. The current generic implementation for is_proximable is the following:

"""
    is_proximable(T::Type)

Returns `true` if the type `T` has a proximal operator that can be expressed in a closed formula.
    (i.e. `prox!` function is defined for the type `T`).
"""
is_proximable(::Type) = true
is_proximable(::T) where T = is_proximable(T)

is_prox_accurate previously didn't have a docstring, so this description was created for me and reflects my understanding of the function's purpose at the time. Working with IndPolyhedralOSQP, however, made me realize that this description is incorrect: "proximal operator has a closed formula" ≠ "it has a prox! function"!

The question is how to fix that. Shall I remove only the "(i.e., prox! function is defined for the type T)" part of the docstring, or is there a place for a deeper solution? While it can be argued that is_proximable is still valid, the term "proximable" is slightly ambiguous. I think both definitions of the "proximable function" are valid:

• Proximal operator exists if the minimization problem $\min_y f(y)+\frac{1}{2\lambda}|y-x|^2$ has a solution.
• Function is proximable if the proximal operator can be computed efficiently, typically in closed form or by a simple algorithm.

A possible solution for this problem might be the following:

• Rename is_proximable to has_closed_prox and remove the parenthesized note from the docstring.
• Introduce a new function has_prox with the default implementation:

has_prox(f::T) where T = hasmethod(prox, Tuple{T, Any})

Of course, I'm ok with simply fixing the docstring, but renaming the function and adding the new function might be a good addition if the goal is to provide an API for ProximalOperators that can be queried for mathematical properties programmatically. The ProximalOperators version (v0.17.0), which uses is_proximable, has not been released yet, so it is quite safe to do such renaming.

What do you think @lostella?

[lostella]

I’m fine with renaming the function, and introducing a new one for the purpose of indicating “closed form” or “prox-exactness”. The only issue I have with has_ is that all other predicates use the is_ form.

[hakkelt]

What about is_proximable = has a prox! function, is_prox_iterative = the prox doesn't have a closed form? This solution still has the ambiguity of "is_proximable", but no better names come to my mind.