Opened 8 years ago
Last modified 7 years ago
#14738 new defect
Several related solve fixes or better doc related to keywords
Reported by: | kcrisman | Owned by: | burcin |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | symbolics | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
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 becauseto_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 mainsolve?
doc (maybe it's okay inx.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 useto_poly_solve
; comparesage: 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)
Change History (6)
comment:1 Changed 8 years ago by
comment:2 Changed 8 years ago by
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.
comment:3 Changed 8 years ago by
- Milestone changed from sage-5.11 to sage-5.12
comment:4 Changed 7 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:5 Changed 7 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:6 Changed 7 years ago by
- Milestone changed from sage-6.3 to sage-6.4
Note: See
TracTickets for help on using
tickets.
Aack! What the heck?
but
We are totally abusing
list.remove()
here.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.