#14738: Several related solve fixes or better doc related to keywords
-------------------------+--------------------------------------------------
   Reporter:  kcrisman   |             Owner:  burcin   
       Type:  defect     |            Status:  new      
   Priority:  major      |         Milestone:  sage-5.11
  Component:  symbolics  |          Keywords:           
Work issues:             |   Report Upstream:  N/A      
  Reviewers:             |           Authors:           
  Merged in:             |      Dependencies:           
   Stopgaps:             |  
-------------------------+--------------------------------------------------
 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)

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14738>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

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


Reply via email to