Re: [sympy] Solving Eqs with inverse-trig functions?

[Chris Smith]

Welcome to SymPy!

In the latest version of sympy (soon to be releases 0.7.2) you get

>>> solve(Eq(y,asin(x)),x)
[sin(y)]

/Chris

[Aaron Meurer]

This works in the development version, and will work in the next
version (to be released some time next month):

In [1]: solve(Eq(y,asin(x)),x)
Out[1]: [sin(y)]

Aaron Meurer

On Fri, Aug 24, 2012 at 7:43 PM, G B <g.c.b....@gmail.com> wrote:
> I'm brand new to sympy, but I've noticed that solve(Eq(y,sin(x)),x) returns
> [asin(y)], but solve(Eq(y,asin(x)),x) barfs.
>
> Is there a way for me to work around that? I'm running 0.7.1, python 2.7.
>
> Thanks--
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sympy/-/9V50C7UVgbUJ.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.

[G B]

Excellent, thank you!  I've pulled down the latest version from git and I'm getting the same results.

Don't know how hard this is to resolve, but you might want to extend it to cover atan2 as well:

solve(Eq(theta,atan(y/x)),x)     ==> [x*tan(theta)]

solve(Eq(theta,atan2(y,x)),x)   ==> barf

Should those return the same results?

[Aaron Meurer]

I think this is doable. We just need to extend the algorithm to
handle inverses of multi-argument functions.

By the way, we also should think of an API to let functions define
their own inverses which would be recognized by solve(). That would
be better than the dict that lives in solvers.py, line 2123.

Aaron Meurer

> https://groups.google.com/d/msg/sympy/-/twjyNFVsneAJ.

[Joachim Durchholz]

Am 25.08.2012 06:56, schrieb Aaron Meurer:
> I think this is doable. We just need to extend the algorithm to
> handle inverses of multi-argument functions.
>
> By the way, we also should think of an API to let functions define
> their own inverses which would be recognized by solve(). That would
> be better than the dict that lives in solvers.py, line 2123.

Sounds like the approach to go.

The inversion API looks nontrivial to me:

1) I don't know how solve() deals with ambiguous inverses like sqrt(x)
or complex logarithm. However, if we provide an inversion API, it should
include information about the kind of ambiguity involved.

2) For multi-argument functions, there are multiple kinds of inverses.
z = atan2 (x, y) could be inverted for x, y, or (x,y).
I'm not sure how this should be dealt with, mostly because I know far
too little about solve(). I guess it depends on what kinds of inverses
solve() ever needs, and whether it can deal with equation systems or
just single equations, and what kinds of tasks the algorithms inside
solve() are suited for.

[G B]

I agree it probably is cleaner to have the functions responsible for their own inverses, and also agree that it will require some thought to handle the ambiguities. In particular the cases where the ambiguities don't lead to a finite solution set (inverting asin, for example?). I know some CASes will return solutions with an additional parameter to handle that case.

In the specific case of atan2, I think there's a short term solution in the sense that atan2(y,x) can be seen as a form of atan(y/x). Perhaps, at least temporarily, it can be treated as nested operations for the sake of inversion which saves us the headache of dealing separately with the 3 cases Joachim enumerates?

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.

[Joachim Durchholz]

Am 25.08.2012 11:14, schrieb G B:
> In the specific case of atan2, I think there's a short term solution
> in the sense that atan2(y,x) can be seen as a form of atan(y/x).
> Perhaps, at least temporarily, it can be treated as nested operations
> for the sake of inversion which saves us the headache of dealing
> separately with the 3 cases Joachim enumerates?

I agree that short-term solutions for the atan2 case are possible.
However, there's still the question how to define the concept of the
inverse for a multi-parameter function.
I don't know whether it's a pressing problem for solve() as it is today.
I'm pretty sure it's going to be relevant some time in the future, so
whatever we do now, we should at least have spend a few thoughts on the
multi-parameter case, even if it's only to reach the conclusion "we have
no clear path laid out for that".

[Aaron Meurer]

Right, we need to be careful about infinite solutions. solve()
currently doesn't handle them, but it one day will.

I think the solution is to just have it return a Set object. Sets are
pretty advanced by now so that they can represent things like log(x) +
n*pi*I or asin(x) + 2*n*pi, for n integer. If there is just one
inverse, it can just return a singleton set. For now, solve() will
just have to pick one element or something until we make it capable of
returning Set objects itself.

As for multiargument functions, we can model it against fdiff, which
also handles multiple arguments.

We might also think of other ways that we could let users extend solve
via API. For example, something like the LambertW is the inverse of
x*exp(x). Obviously we could set the inverse of LambertW and make
solve(LambertW(x) - y, x) work, but how could we make solve(x*exp(x) -
y, x) work, without modifying the solve code (yes, I know this already
works, but I mean imagine for a function like LambertW that isn't
implemented already).

Aaron Meurer