#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):
For `NumberFieldElement` I wonder whether it would be better to not use an
approximate solution, but instead convert to `QQbar` and then embed that
into `SR`. Only if there exists no radical solution, to be sure. Visually
it would look the same: numbers get printed as an approximation.
Mathematically, though, things would be exact.
There might be downsides, of course. Some computations might fail because
they aren't defined for algebraic numbers. Some others might take
considerably longer. And there would be no reasonable way to deprecate
current behavior, because we have to return one or the other, there seems
to be no reasonable way in between. How would one go about discussing a
possible change like this?
In any case, that would be a different ticket, since this one here is
about the incorrect rationals, which I'll try to review this weekend.
Converting to `QQbar` would also require #5355 to be addressed first.
--
Ticket URL: <http://trac.sagemath.org/ticket/16651#comment:14>
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.
