to_poly_solve inconsistency for periodic functions

[Duc Trung Ha]

Hola,

I was wondering about following eerie behavior of "solve" function:

On the one hand, "force" value of "to_poly_solve" option seems to be more
powerful as for periodicity of solutions:

sage: solve(tan(x)==1,x,to_poly_solve=True)
[x == 1/4*pi]
sage: solve(tan(x)==1,x,to_poly_solve="force")
[x == 1/4*pi + pi*z275]

On the other hand, "True" value of "to_poly_solve" occasionally gives out
better outputs:

sage: solve(sin(x)/cos(x)-1,x,to_poly_solve=True)
[x == 1/4*pi + pi*z299]
sage: solve(sin(x)/cos(x)-1,x,to_poly_solve="force")
[]

However, "tan(x)==1" appears to me as an equivalent form of
"sin(x)/cos(x)-1==0".

Is this a bug or is it covered somewhere else?
Duc Trung Ha
Sage Version 4.8, Release Date: 2012-01-20
Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz
Ubuntu 11.10

[kcrisman]

On Saturday, April 7, 2012 1:49:22 PM UTC-4, Duc Trung Ha wrote:

Hola,          
               
I was wondering about following eerie behavior of "solve" function:
               
On the one hand, "force" value of "to_poly_solve" option seems to be more
powerful as for periodicity of solutions:
               
sage: solve(tan(x)==1,x,to_poly_solve=True)
[x == 1/4*pi]
sage: solve(tan(x)==1,x,to_poly_solve="force")
[x == 1/4*pi + pi*z275]
               
On the other hand, "True" value of "to_poly_solve" occasionally gives out
better outputs:
               
sage: solve(sin(x)/cos(x)-1,x,to_poly_solve=True)  
[x == 1/4*pi + pi*z299]
sage: solve(sin(x)/cos(x)-1,x,to_poly_solve="force")    
[]            
               
However, "tan(x)==1" appears to me as an equivalent form of
"sin(x)/cos(x)-1==0".
 

That's interesting.  I think that from our viewpoint, since we rely pretty heavily on Maxima's `to_poly_solve` package at that point, the "right" answer would be to

 1)  find Maxima commands that would do the same thing (you'll have to look a tiny bit at the source code for solve, available at http://hg.sagemath.org/sage-main/file/c239be1054e0/sage/symbolic/expression.pyx#l7560 and further)

 2) test them in the latest (5.27) Maxima

 3) then pass it on to the Maxima list and in particular Barton Willis, the author of this package, who would certainly be interested in anything that would improve it.

My guess is that in the first case, to_poly_solve has a way of converting tan to something clever that then gets solved, but in the second case doesn't and so returns the empty set of solutions ('force' makes to_poly_solve the only way we try to solve an equation).

If you could do this, I'm sure they would find it quite useful!  Thanks.

[Duc Trung Ha]

OK, I WILL try & strive to do my best...

BTW By "Maxima list" is meant Maxima Google support group or something else?

[kcrisman]

On Sunday, April 15, 2012 5:09:59 PM UTC-4, Duc Trung Ha wrote:

OK, I WILL try & strive to do my best...

BTW By "Maxima list" is meant Maxima Google support group or something else?

They have their own sourceforge list.

http://www.math.utexas.edu/mailman/listinfo/maxima 

[Duc Trung Ha]

Alright, here is a message I posted to Maxima's mail-list:

Hola,
 
I am sorry if this would come as a completely stupid question but I was really
amazed at this Maxima's behavior:
 
When I searched for solution of goniometric equation `tan(x) = 1`::
 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(%i22) to_poly_solve(tan(x) = 1, x);
                                                   %pi
                                    - 2 %pi %z30 - ---
                                                    2
(%o22)                %union([x = - ------------------])
                                            2
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
answer was given to me. On the other hand, when I entered what I consider an
equivalent form of the very same equation:
 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(%i23) to_poly_solve((sin(x)/cos(x)) - 1 = 0, x);
                                                                   %pi
                                                    - 4 %pi %z40 - ---
                      %pi (8 %z40 + 1)                              2
(%o23) %union(%if(cos(----------------) # 0, [x = - ------------------],
                             4                              2
                                                                        3 %pi
                                           %union()), [x = 2 %pi %z38 - -----])
                                                                          4
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
output came out. After a brief inspection one can unravel that this solution is
in fact identical, however, denoted in very much less elegant & transparent
way.

This may cause some serious troubles to external programs exploiting Maxima's
functionality. For instance, I discovered this issue while using Sage's `solve`
command -- original bug can be viewed at
https://groups.google.com/forum/?hl=en&fromgroups#!topic/sage-support/ys3CASZ3vrs
 
Similarly, `solve` also is not capable of recognizing `sin/cos` form of `tan`::
 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(%i24) solve(tan(x) = 1, x);
 
solve: using arc-trig functions to get a solution.
Some solutions will be lost.
                                        %pi
(%o24)                             [x = ---]
                                         4
(%i25) solve((sin(x)/cos(x)) - 1 = 0, x);
(%o25)                         [sin(x) = cos(x)]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
Is it somehow possible to alter the output for equivalent forms of such
well-known goniometric functions and thus fix this pseudo-bug?
 
---
Duc Trung Ha

 I've been given these replies:

You can use trigreduce to convert sin(x)/cos(x) to tan(x).  But I agree
that it would be nice if solve(sin(x)/cos(x)=1,x) gave a reasonable answer.
 Besides to_poly_solve, another way to handle trigonometric equations more
systematically is to put them in exponential form, e.g.
rectform(solve(exponentialize(...), ...)).  But the result can be ugly in
some cases.
 
As for to_poly_solve, it's unreasonable to expect in general that
equivalent solution sets will be syntactically identical. That is a very
hard problem (actually unsolvable in general), though over time, more and
more cases will be handled nicely.
 
            -s 

 
Professor Barton Willis (who maintains to_poly_solve) gave me this answer:

Appending 'simpfuncs = ['expand] helps somewhat; try  to_poly_solve(sin(x)/cos(x) = 1, x, 'simpfuncs = ['expand]);

I made no particular effort to make to_poly_solve (usually) find syntactically identical solution sets to semantically identical equations. That simply
wasn't a design goal. Although it might seem easy to do write a pre-processor that would do things such as sin(x)/cos(x) --> tan(x), it's not so
easy to do this in a way that doesn't make some answers much much more complicated, or to do it without introducing spurious solutions.

 Most days, I'm happy when nobody locates an abject bug in to_poly_solve :)

Thanks for the interest in to_poly_solve.

--bw

To which it was responded thus:

I think it should be this way.  Maxima doesn't automatically convert
sin(x)/cos(x) to tan(x).  I don't think to_poly_solve should magically
do that either.

Although it would be nice for %union and %if were smarter so that %if
would know that cos(%pi/4*(8*%z40+1)) is never zero.  Then we'd just
have %union of two values of x.  And it would be nice to see that they
differ by just an integral multiple of %pi so that they could be
combined into one.

Ray

It seems to me, that Maxima is doing its work properly, just some solutions are given in rather inelegant way which consequently confuses Sage in giving empty set of solutions... Am I correct with this hypothesis?

[Duc Trung Ha]

Okay, I'm sorry I didn't realize the spaces get messy after copy-paste. Here's a link to original discussion:
http://comments.gmane.org/gmane.comp.mathematics.maxima.general/37853