Opened 8 years ago

# Several related solve fixes or better doc related to keywords

Reported by: Owned by: kcrisman burcin major sage-6.4 symbolics N/A

### Description

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
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)

### comment:1 Changed 8 years ago by kcrisman

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.

Last edited 8 years ago by kcrisman (previous) (diff)

### comment:2 Changed 8 years ago by kcrisman

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.

Last edited 8 years ago by kcrisman (previous) (diff)

### comment:3 Changed 8 years ago by jdemeyer

• Milestone changed from sage-5.11 to sage-5.12

### comment:4 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.1 to sage-6.2

### comment:5 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.2 to sage-6.3

### comment:6 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.3 to sage-6.4
Note: See TracTickets for help on using tickets.