#16222: Faster exactification using numeric minpoly
-------------------------------------+-------------------------------------
Reporter: gagern | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.4
Component: number fields | Resolution:
Keywords: | Merged in:
Authors: Martin von Gagern | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/16222 | 998534a33a502a86518f6c541f99cac1ffacdaa5
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by vdelecroix):
Replying to [comment:14 gagern]:
> But some of them for worse:
>
> {{{
> line 360, sage_input(n, verify=True):
> Expected: AA(2)
> Got: v = sqrt(AA(2))
> v*v
>
> line 7881, sage_input(n):
> Expected: QQbar(sqrt(AA(2))) + 1
> Got: v = sqrt(QQbar(3))
> QQbar(sqrt(AA(2))) + v/v
> }}}
Not really for worse. The previous doctests assumed that at some point in
the code `.exactify()` would have been called. Within your branch
{{{
sage: rt2 = sqrt(AA(2))
sage: n = rt2^2
sage: sage_input(n)
v = sqrt(AA(2))
v*v
sage: n.exactify()
sage: sage_input(n)
AA(2)
}}}
The thing is that when comparisons are done we still want exactification
to be done.
> Here are a few more realistic ways how we could make that case
distinctions in a way that might make sense. I'm not completely happy with
any of them.
>
> 1. Only do the algdep approach if at least one number in the descriptor
dag originated from a symbolic expression
> 2. Limit the reconstruction of symbolic expressions to fewer operations,
mainly elementary arithmetic operations
> 3. Give control to the user: make exactification using algdep not part
of the normal exactification procedure, but instead the result of an
explicit method invocation
> 4. Try to detect exactifications which are likely very slow using the
standard approach, e.g. indicated by the expected size of the minpoly for
some union field, and try algdep only on those
Option 3 is definitely needed.
I am against option 1. First of all it would ignore things like
{{{
sage: QQbar(2).sqrt() + QQbar(3).sqrt()
}}}
Moreover we do not want to keep the origin of the objects.
For options 2 and 4 there is a right balance to find.
--
Ticket URL: <http://trac.sagemath.org/ticket/16222#comment:15>
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.
