More inverses?

[aplavin]

Do you consider inverses to two-argument Julia Base functions in scope of this package? For example:

inverse(f::Base.Fix1{typeof(+)}) = Base.Fix2(-, f.x)
inverse(f::Base.Fix1{typeof(^)}) = Base.Fix1(log, f.x)
# and so on

Originally, this came up in JuliaObjects/Accessors.jl#46, but can be useful elsewhere as well.

[oschulz]

I think this would fit in InverseFunctions, in principle. How many of these do you think there would be?

[oschulz]

I had a closer look at JuliaObjects/Accessors.jl#46 - I think the Fix1/Fix2 inverse defined there would fit nicely in InverseFunctions. And deg2rad and so on we should definitely add as well.

We should change our current definition square(x) = x^2 to const square = Base.Fix2(^,2) while we're at it.

@devmotion any objections?

[devmotion]

We should change our current definition square(x) = x^2 to const square = Base.Fix2(^,2) while we're at it.

I'm not sure if this should be done. There are other possible choices such as abs2 or involving literal_pow (which x^2 is lowered to usually), so it's not clear to me that your suggestion should be preferred.

[oschulz]

I'm not sure if this should be done.

Oh, you're right - sorry, Base.Fix2(^,2) would be slow of course, since it couldn't be optimized as usual. But maybe we should make our square an alias of abs2 or so?

I any case we could certainly define things like

inverse(f::Base.Fix2{typeof(^)}) = Base.Fix2(^, inv(f.x))

right? The list of inverses proposed in JuliaObjects/Accessors.jl#46 is quite finite, I don't think they would bloat InverseFunctions too much (and can't be defined outside of it without type piracy, of course).

[sethaxen]

square and abs2 are not equivalent for non-real numbers.

[oschulz]

square and abs2 are not equivalent for non-real numbers.

True. Maybe best we keep square for now.

[devmotion]

For real numbers, I think the arguably most natural choice would be

leftinverse(::typeof(sqrt)) = abs2

I am aware that it does not work in general (and I was sure someone would mention it 😄) but it would be nice to be able to use it for Real inputs. I mean, in general functions may depend on the input types (e.g. sqrt of negative real numbers throws an error whereas it works for complex numbers with negative real part), so why shouldn't we have a definition for the Real case specifically?

[oschulz]

leftinverse(::typeof(sqrt)) = abs2

Maybe we should continue that one on #10? :-)

[oschulz]

I like the symmetry of

inverse(f::Base.Fix1{typeof(^)}) = Base.Fix1(log, f.x))
inverse(f::Base.Fix2{typeof(^)}) = Base.Fix2(^, inv(f.x))

and so on for +, -, * and / we'd get from @aplavin's proposal.

[sethaxen]

I am aware that it does not work in general (and I was sure someone would mention it 😄) but it would be nice to be able to use it for Real inputs. I mean, in general functions may depend on the input types (e.g. sqrt of negative real numbers throws an error whereas it works for complex numbers with negative real part), so why shouldn't we have a definition for the Real case specifically?

This raises the point that it might not be sufficient to know the name of the function to define the inverse. One might also need to know the domain, as defined by the type of the input. Of course, some inputs may not store their constraints in their type, so the inverse may depend on the value itself.

[sethaxen]

Or put another way, different methods of the same function may require different inverses, and those inverses may not be different methods of the same function.

[aplavin]

In the context of Accessors.jl, the #9 version probably makes most sense.

sqrt(4) == 2
sqrt(-4)  # throws
(@set sqrt(x) = 2) == 4
(@set sqrt(x) = -2)  # better if throws as well

But this loses the nice symmetry, and requires defining separate function for these inverses to perform argument checks.

[oschulz]

This raises the point that it might not be sufficient to know the name of the function to define the inverse. One might also need to know the domain, as defined by the type of the input.

That's a whole different level, though. :-)

[devmotion]

I like the symmetry of

inverse(f::Base.Fix1{typeof(^)}) = Base.Fix1(log, f.x))
inverse(f::Base.Fix2{typeof(^)}) = Base.Fix2(^, inv(f.x))

The main problem is that this is incorrect and problematic in the same sense as sqrt and square. Even more problematic, even leftinverse and rightinverse would not fix the problem here:

If one considers the maximum support on the real line in all cases, then f = Base.Fix2(^, 2) is a left inverse of g = Base.Fix2(^, 1/2) (f(g(x)) = x for all x >= 0) but not a right inverse (g(f(-1)) != -1). However, this also shows that f = Base.Fix(^, 1/2) is a right inverse of g = Base.Fix(^, 2) but not a left inverse. So neither of the following definitions

inverse(f::Base.Fix2{typeof(^)}) = Base.Fix2(^, inv(f.x)) # incorrect e.g. if `f.x = 2` or `f.x = 1/2`
leftinverse(f::Base.Fix2{typeof(^)}) = Base.Fix2(^, inv(f.x)) # incorrect e.g. if `f.x = 2`
rightinverse(f::Base.Fix2{typeof(^)}) = Base.Fix2(^, inv(f.x)) # incorrect e.g. if `f.x = 1/2`

would be correct in general.

[aplavin]

f = Base.Fix2(^, 2) is a left inverse of g = Base.Fix2(^, 1/2) (f(g(x)) = x for all x >= 0) but not a right inverse (g(f(-1)) != -1)

What definition of the right inverse do you use here?
For g:X->Y the right inverse is f:Y->X so that for all y in Y we get g(f(y)) = y. The -1 example is not in Y, and as I understand the right inverse definition doesn't "care" what happens there.

Still I agree it may be cleaner to throw an exception in f when the argument is outside of the range of the corresponding g: see my previous comment. This requires defining a few separate functions to only serve as inverses, but maybe there is nothing really wrong with it...