sin(x)/cos(x)

[robin hankin]

hello. Sage 5.9:

sage: solve(sin(x)/cos(x)==1,x,to_poly_solve="force")
[]



I find this unexpected because pi/4 is a solution, and sage seems to
indicate that there are no solutions.


Sage can handle the equation if I do some preprocessing:

sage: solve(tan(x)==1,x,to_poly_solve='force')
[x == 1/4*pi + pi*z219]







--
Robin Hankin
Uncertainty Analyst
hankin...@gmail.com

[Michael Orlitzky]

On 06/11/2013 04:43 PM, robin hankin wrote:
> hello. Sage 5.9:
>
> sage: solve(sin(x)/cos(x)==1,x,to_poly_solve="force")
> []
>
>
>
> I find this unexpected because pi/4 is a solution, and sage seems to
> indicate that there are no solutions.
>
>
> Sage can handle the equation if I do some preprocessing:
>
> sage: solve(tan(x)==1,x,to_poly_solve='force')
> [x == 1/4*pi + pi*z219]
>

Try to_poly_solve=True.

[robin hankin]

OK Michael, thanks for this.

But my problem was

solve(sin(x)/cos(x)==1,x,to_poly_solve="force")


returns an empty solution set, implying that there are no solutions
when in fact there are. Surely this is misleading?

Worthy of a bug report? IDK

best wishes

Robin

> --
> You received this message because you are subscribed to the Google Groups "sage-support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-support...@googlegroups.com.
> To post to this group, send email to sage-s...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-support?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.

[Michael Orlitzky]

On 06/11/2013 07:26 PM, robin hankin wrote:
> OK Michael, thanks for this.
>
> But my problem was
>
> solve(sin(x)/cos(x)==1,x,to_poly_solve="force")
>
>
> returns an empty solution set, implying that there are no solutions
> when in fact there are. Surely this is misleading?
>
> Worthy of a bug report? IDK

I didn't realize 'force' was a valid value for to_poly_solve, so yeah,
it's a bug. The solve() function is fairly easy to confuse, but I would
open a ticket for it just so it doesn't get forgotten.

[robin hankin]

OK thanks for this, bug reported [at least, I think it is. I
couldn't see it on trac].

Now what about this:


sage: solve(sin(x) + cos(x) == cos(2*x),x,to_poly_solve=True)
[x == 2*pi*z264, x == 2*pi*z268 + 1/6004799503160661*I - 355/452, x ==
2*pi*z266 + 1/1125899906842624*I - 355/226, x == 2*pi*z270 +
1/9007199254740992*I + 1065/452]


After the first, the solutions are not actually solutions of the
equation. Is this reportable or have I misunderstood what solve() is
supposed to do?



Robin

[Michael Orlitzky]

On 06/11/2013 10:44 PM, robin hankin wrote:
> OK thanks for this, bug reported [at least, I think it is. I
> couldn't see it on trac].
>
> Now what about this:
>
>
> sage: solve(sin(x) + cos(x) == cos(2*x),x,to_poly_solve=True)
> [x == 2*pi*z264, x == 2*pi*z268 + 1/6004799503160661*I - 355/452, x ==
> 2*pi*z266 + 1/1125899906842624*I - 355/226, x == 2*pi*z270 +
> 1/9007199254740992*I + 1065/452]
>
>
> After the first, the solutions are not actually solutions of the
> equation. Is this reportable or have I misunderstood what solve() is
> supposed to do?
>

The solve() function is fairly easy to confuse =)

Open a ticket!

[kcrisman]

On Tuesday, June 11, 2013 10:44:38 PM UTC-4, robin wrote:

OK thanks for this,  bug reported [at least, I think it is.   I
couldn't see it on trac].

 No

Unfortunately, the bug tracker from the notebook does *not* automatically create Trac tickets.  (Actually, this is sort of good, since many of them are really just support requests.  But it's unfortunate we can't have the process more automated.)   But I did create http://trac.sagemath.org/sage_trac/ticket/14736 since this is worth investigating; the solutions with 'force' should include all solutions with True.

[Stephen Montgomery-Smith]

On 06/11/2013 09:44 PM, robin hankin wrote:
> OK thanks for this, bug reported [at least, I think it is. I
> couldn't see it on trac].
>
> Now what about this:
>
>
> sage: solve(sin(x) + cos(x) == cos(2*x),x,to_poly_solve=True)
> [x == 2*pi*z264, x == 2*pi*z268 + 1/6004799503160661*I - 355/452, x ==
> 2*pi*z266 + 1/1125899906842624*I - 355/226, x == 2*pi*z270 +
> 1/9007199254740992*I + 1065/452]
>
>
> After the first, the solutions are not actually solutions of the
> equation. Is this reportable or have I misunderstood what solve() is
> supposed to do?

Just in case people hadn't spotted it, it also missed some solutions:
-pi/4, 3*pi/4 and -pi/2, plus 2*pi*integer. And I think that is all of
them (even including complex solutions).

[kcrisman]

Here is a workaround.  It's not ideal, but does work.

sage: sage: solve((sin(x)+cos(x)==cos(2*x)).trig_expand(),x,to_poly_solve=True)

[sin(x) == cos(x) - 1, x == -1/4*pi + 2*pi*z571, x == 3/4*pi + 2*pi*z569]

sage: solve(_[0],x,to_poly_solve=True)

[x == 2*pi*z581, x == -1/2*pi + 2*pi*z583]

Unfortunately, the Maxima list confirmed what I suspected on this - namely, that this might be the only way to do it.  See also http://trac.sagemath.org/sage_trac/ticket/14738.

It looks like to_poly_solve is calling algsys, which is using approximate methods and thus giving bogus results.

You might try:

         sols: solve( [ trigexpand( sin(x)+cos(x)=cos(2*x) ), sin(x)^2+cos(x)^2=1 ], [sin(x),cos(x)] )

To get explicit results (rather than sin(x)=...), you can then use %solve:

          map(lambda([eq],%solve(eq,x)), sols);

 

[kcrisman]

Here is a workaround.  It's not ideal, but does work.

sage: sage: solve((sin(x)+cos(x)==cos(2*x)).trig_expand(),x,to_poly_solve=True)

[sin(x) == cos(x) - 1, x == -1/4*pi + 2*pi*z571, x == 3/4*pi + 2*pi*z569]

The reason *this* doesn't work right away is because we were abusing Python lists - we modified the list while iterating over it.  In fact, I may personally be to blame for that code... anyway, at least this is easy to fix; the rest will require some hacking.