#16651: Buggy to_poly_solve option
-------------------------------------+-------------------------------------
Reporter: gagern | Owner:
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-6.3
Component: symbolics | Resolution:
Keywords: | Merged in:
Authors: Volker Braun | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/vbraun/buggy_to_poly_solve | 6fb6bee3a7ef1f692656f615f9361c9e52afeec1
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gagern):
Replying to [comment:12 kcrisman]:
> This was because of comment:7:ticket:6642. Basically, the problem is
that Barton's `to_poly_solve` stuff depends on `algsys` which does not
guarantee exact solutions, though it very often gives them. But in order
for that doctest to work we made that change, as you can see by reading
the full set of comments on the ticket.
Must have been asleep when reading that ticket, sorry. So the way I
understand it now, the `to_poly_solve=True` was introduced specifically to
allow for approximate solutions. There is no example of a polynomial
equation where `to_poly_solve=True` would find an ''exact'' solution that
`to_poly_solve=False` missed, right?
In that case, I might as well remove the whole `to_poly_solve=True` stuff
from my commit, since I'd filter out inexact solutions in any case.
--
Ticket URL: <http://trac.sagemath.org/ticket/16651#comment:13>
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.
For more options, visit https://groups.google.com/d/optout.
