#14239: symbolic radical expression for algebraic number
-------------------------------------+-------------------------------------
Reporter: gagern | Owner: davidloeffler
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: number fields | Resolution:
Keywords: | Merged in:
Authors: Martin von Gagern | Reviewers: Marc Mezzarobba
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/14239 | 006fa24b1199b44a2963ee0c14896f5e4d9003b0
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gagern):
Replying to [comment:25 vbraun]:
> IMHO #16651 should be fixed instead of adding workarounds for #16651
elsewhere.
Even with #16651 fixed, there are several reasons why I'd consider the
detour via `NumberFieldElement` to be inferior to my approach here.
1. In case of no exact solution, `NumberFieldElement` will use an
approximation, while my idea here is to never loose precision. So you'd
have to either declare all uses of approximation in `NumberFieldElement`
to be undesired as well, or add some flag to suppress approximate
solutions. Or detect them after the fact, and hope I get it right this
time around.
2. In some cases, the degree used for the conversion to a number field
element is much bigger than that of the minimal polynomial. In
[https://gist.github.com/gagern/7fc8ebccfdff9b545771 one case] I've seen
the number field to have a dense defining polynomial of degree 24, while
the minpoly only had even degrees up to 6. This might of course well be
considered a bug in its own right.
3. My code can deal with a situation where the number of distinct roots
found by the symbolic solver does not equal the degree of the polynomial.
`NumberFieldElement` will give up in that situation. I don't know yet
whether we might encounter polynomials with multiple roots, and I don't
know how likely it is for the solver to find only a subset of all roots.
But with a too high degree and the use of `to_poly_solve=True` I consider
both likely.
4. I'm not sure I trust the root matching in
`ambient_field=ComplexField(53)`. There are cases where the different
roots cannot be distinguished in this field, and I believe that in these
cases the approach of “taking the closest root” is unreliable at best.
If you are confident that most of the issues raised above should be fixed
for `NumberFieldElement` as well, then I'll investigate options to share
code between both implementations.
--
Ticket URL: <http://trac.sagemath.org/ticket/14239#comment:26>
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.
