calculus function fields about proximaloperators.jl HOT 4 CLOSED

Again, I don't think there's a clean way of obtaining what you're looking for in general: once you sum two functions of the same type, you're already screwed since they will have the same set of fields.

The way I see it, either

1. the fields you want to inspect reflect into some general property of functions, so that you can define the same property in terms of the property of the components, or
2. you have a sufficiently restricted set of cases, such as "f is the Sum of multiple functions, some of which are of SqrNormL2", in which case you can also do something like

for component in f.fs
    if typeof(component) <: SqrNormL2
        # do something about component.lambda
    end
end

from proximaloperators.jl.

It’s hard for me to see how this could be done: That lambda parameter is very specific to SqrNormL2, why do you need it? To get to some general property of functions? Maybe Lipschitz constant or convexity modulus?

from proximaloperators.jl.

One option, in case you have a restricted combination of possible types, is to define access methods like

get_lambda(f::SqrNormL2) = f.lambda

get_lambda(f::Sum{Tuple{SqrNormL2, T}}) where T = f.fs[1].lambda

since multiple dispatch is awesome. But again, depending on how many combinations are allowed you may need to complicate the above example.

from proximaloperators.jl.

I actually need the linear mappings (in order to compute direction for a linesearch) that are precomposed with logisticlosses and then the whole thing is summed with sqrNorml2s.
The multiple dispatch suggestion would work but it is still kinda ugly to separate into cases. That's why I was thinking maybe it would be easier for the calculus rules to be blind to how they are created.
I guess with calculus functions like sum it can be tricky since the summed functions may have overlapping fields. But in other cases like precompose I guess it can be done without issues. But then again I didn't think it through. Any way I'll go with your suggestion.

from proximaloperators.jl.