RFC: Defining inverse functions

[AayushSabharwal]

It would be useful to have a way to have mappings between functions and their inverses. One option would be to add to @register_symbolic but the concept of an inverse then is only really valid when registering single-argument functions.

We could keep the interface simple for now: Symbolics.inverse takes a function and returns its inverse. Users can either overload the function manually, or use @register_inverse f g which defined Symbolics.inverse(::typeof(f)) = g and Symbolics.inverse(::typeof(g)) = f.

Of course, this then leads to a discussion of left- and right- inverses. I like two options:

• a second ::Val{:left} or ::Val{:right} argument
• Symbolics.left_inverse and Symbolics.right_inverse

The difference is mostly cosmetic, but the second option would probably work better for extending to multivariate functions. @register_inverse f g defines all 3 dispatches, with the left and right inverse both pointing to the standard inverse method. @register_inverse f g :left defines only the left-inverse, and a similar macro syntax for the right-inverse. If the user wants to define the methods manually, then it is up to them to make sure they're consistent. The manual definition is mainly to support defining inverses of callable structs, which would require the struct itself instead of just the type.

[ChrisRackauckas]

Symbolics.left_inverse and Symbolics.right_inverse