Several related solve fixes or better doc related to keywords

[kcrisman]

We have to do a little overhauling of solve. I'm just collating some here - all have something to do with options.

• First,

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] 

This is because to_poly_solve does indeed use some inexact methods, as we know. But

• Secondly, we need to make it more clear exactly what explicit_solutions does, at least in the main solve? doc (maybe it's okay in x.solve?).

(1)  "solve?" gives me  " solve(sin(x)==x,x,explicit_solutions=True)" 
as an example which returns an empty list of solutions. 
But x=0 surely counts as an explicit solution?  I guess my 
interpretation of an empty list as "there cannot possibly be any 
solutions of this form" 
can't be right.  Can we add a legal disclaimer along the lines of "an 
empty list does not guarantee the absence of solutions"? 

• Another one:

Trying     "solve(sin(x)==x,x,to_poly_solve=True)"  gives me an 
unhelpful error message about indexing.  What does this message mean 
and how can I mitigate it? 

This is a problem in how we use to_poly_solve; compare

sage: solve(abs(1-abs(1-x)) == 10, x)
[abs(abs(x - 1) - 1) == 10]
sage: _[0]
abs(abs(x - 1) - 1) == 10
sage: Y = _._maxima_().to_poly_solve(x).sage()
sage: Y
[[x == -10], [x == 12]]

where you need to index twice to get the solution.  However, 

sage: solve(sin(x)==x,x)
[x == sin(x)]
sage: _[0]
x == sin(x)
sage: Y = _._maxima_().to_poly_solve(x).sage()
sage: Y
[x == sin(x)]

• Yet another one in which the keywords aren't behaving as we expect.

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*z539, x == 3/4*pi + 2*pi*z537]
sage: solve((sin(x)+cos(x)==cos(2*x)).trig_expand(),x,to_poly_solve='force')
[x == 2*pi*z553 + 1/1125899906842624*I - 355/226,
 x == 2*pi*z557 + 1/9007199254740992*I + 1065/452,
 x == 2*pi*z555 + 1/6004799503160661*I - 355/452,
 x == 2*pi*z551]

Neither of these is optimal!

• There are also some typos (such as "univarite" or something), and it should be very clear in the examples (not just in the input block) that certain keywords really only obtain with single expressions.

---

Fixing at least some of these would be enough to close this ticket, as long as the rest were moved forward to another one. Related but sadly not the same is #10750 (additional args are not handled uniformly)

Component: symbolics

Issue created by migration from https://trac.sagemath.org/ticket/14738

[kcrisman]

comment:1

Aack! What the heck?

sage: for eq in X:
....:     print eq._maxima_().to_poly_solve(x).sage()
....:     
[[x == 3/4*pi + 2*pi*z637], [x == -1/4*pi + 2*pi*z639]]
[[x == 2*pi*z647], [x == -1/2*pi + 2*pi*z649]]

but

sage: for eq in X:
    Y = eq._maxima_().to_poly_solve(x).sage()
....:     X.remove(eq)
....:     
sage: X
[sin(x) == cos(x) - 1]

We are totally abusing list.remove() here.

sage: L = [1,2,3]
sage: for l in L:
    L.remove(l)
....:     
sage: L
[2]

Yikes. See e.g. this stackoverflow question; we should not be changing a list while iterating over it. See Python spec and this very clear answer on stackoverflow.

[kcrisman]

comment:2

As to the first one, it sounds like setting algexact:true would be one way to avoid this, though at the cost of horrendously ridiculous stuff.