left/right inverses?

[cscherrer]

Just adding a note here (we don't have to dig in right now), that it would be great to also support left_inverse and right_inverse, since this comes up so often

[oschulz]

Good point, let's keep this issue as a reminder.

[sethaxen]

I agree, this would be useful to have. left_inverse and right_inverse could fall back to inverse, so that if a downstream user only needs to require that a function be right-invertible, then they would call right_inverse directly and support more functions.

[oschulz]

Also relates to #8, e.g. for square/sqrt.

[oschulz]

right-inverses could also be helpful components (building blocks) in pullback definitions, see example in JuliaObjects/Accessors.jl#46 (right_inverse(@optic(_.a) would be it's pullback, modulo ChainRulesCore boilerplate).

[ParadaCarleton]

@oschulz I see sqrt and square are defined as inverses, even though this isn't strictly correct; is the plan to allow partial inverses (e.g. trig/hyptrig) functions to be defined as inverse, or should I define a new function partial_inverse for this case? (We've come across it in TableTransforms.jl, where we need left inverses.)

[oschulz]

@ParadaCarleton , so far we haven't really had a use case for left/right inverses, but I guess now there is one with TableTransforms then. I think there's consensus that in principle we should add left/right inverses. Would you like to put a proposal together, maybe as a draft PR - just bare-bone initially, so we can discuss the API?

[aplavin]

Noticed interesting convergence, though arriving from quite a different direction.

In AccessorsExtra, I define the construct([T,] f1 => val1, f2 => val2, ...) function to create an object with the given values function. The result is an object of type T with f1(obj) == val1, f2(obj) == val2, ... .

In the general case, construct methods have to be defined for each set of functions that one wants to create an object from, such as

construct(Gaussian, area => 1, fwhm => 2)
construct(Complex, abs => 3, angle => 0.5)

However, invertible functions and basic types like (named)tuples are supported automatically. This means

julia> rinverse(f) = x -> construct(f => x)

is a right inverse for supported functions.

# just uses inverse() inside
julia> rinverse(log10)(3)
1000.0

# uses inverse() + creates namedtuple
julia> rinverse(@o log10(_.a))(3)
(a = 1000.0,)

I don't really have common usecases for right inverses to non-fully-invertible mathematical functions, so this rinverse only supports invertible functions + property or index accessors.

It can be seen from these examples that right_inverse is kinda "more general" than the full inverse and can naturally be applied to things like property accessors – not just mathematical functions.

[oschulz]

rinverse(f) = x -> construct(f => x)

Oh, this looks elegant @aplavin !

I tried running construct(log => 0.5) , but I get no method matching default_empty_obj(::typeof(log)) - how do I tell construct what to build?

[oschulz]

Works beautifully @aplavin ! :-)

[oschulz]

I've been thinking, if we offer left/right-inverses, should we allow room in the API and namespace for non-function inverses, and a more general package "InverseElements.jl" (or simply "Inverses.jl")?

Our current inverse(f) could mathematically (an inverse being in relation to a binary operation and a neutral element) be written as inverse_element(∘, identity, f). Such an API would then also allow for inverse_element(+, 0, 5) and so on. I don't think we need to pass the neutral element explicitly though, I think we can treat it as implied by the operation and the object.

So we could have a package InverseElements that defines inverse_element(op, object), it could depend on InverseFunctions and define inverse_element(::typeof(∘), f) = inverse(f).

But what about left_inverse and right_inverse? Should they be for functions only, then we'd also need left_inverse_element and right_inverse_element for the general case, or should we require passing op (so ∘ for functions) explicitly for left_inverse and right_inverse in general?