#14239: symbolic radical expression for algebraic number
-------------------------------------+-------------------------------------
Reporter: gagern | Owner: davidloeffler
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.2
Component: number fields | Resolution:
Keywords: | Merged in:
Authors: | Reviewers: Marc Mezzarobba
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/14239 | 039f4bf3bff139ce2630fe2fb8fd8f542096a498
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gagern):
I notice that in real world applications, the check for `self ==
QQbar(res)` takes excessively long. Example:
{{{QQ[x](16*x^6 - 392*x^4 + 133*x^2 + 900).roots(AA,
False)[-1].radical_expression()}}}
It gets stuck in several layers of `exactify`, but eventually the keyboard
interrupt ends up here:
{{{
File "sage/rings/qqbar.py", line 6798, in exactify
red_elt, red_back, red_pol = do_polred(newpol_sage_y)
File "sage/rings/qqbar.py", line 1645, in do_polred
new_poly, elt_back = poly._pari_().polredbest(flag=1)
File "gen.pyx", line 8048, in sage.libs.pari.gen.gen.polredbest
(sage/libs/pari/gen.c:42279)
File "c_lib.pyx", line 73, in sage.ext.c_lib.sig_raise_exception
(sage/ext/c_lib.c:872)
}}}
On the one hand, I wonder whether there is some better way to detect an
inexact conversion. I haven't looked enough at the internal structure of a
symbolic expression to know how to handle this.
On the other hand, I wonder why this comparison is taking so long. Or even
whether it is simply taking excessively long, or perhaps even got stuck
completely. Perhaps this is an indication of some more fundamental
problem. If you want to invastigate this, you can do so without checking
out this branch. Simply using the example above, the relevant operation is
the following:
{{{
a = QQ[x](16*x^6 - 392*x^4 + 133*x^2 + 900).roots(AA, False)[-1]
b = -1/1296*((9*I*sqrt(3)*(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) +
9*(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) -
37*I*sqrt(3)/(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) +
37/(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) +
18)*(9*I*sqrt(3)*(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) +
9*(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) -
37*I*sqrt(3)/(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) +
37/(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) - 12) -
3456)*sqrt(-9/2*I*sqrt(3)*(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) -
9/2*(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) +
37/2*I*sqrt(3)/(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) -
37/2/(2/9*I*sqrt(443)*sqrt(3) + 53/27)^(1/3) + 6)
a == b
}}}
Even as it stands, having the `as_radical_expression` method is better
than not having it. So this comment here should be no reason not to merge
the branch, in my opinion. On the other hand, I would very much welcome
input to make things work faster for complicated expressions like those
described above.
Barring any good ideas, I might eventually end up adding an optional
argument `exact` with a default value of `True`. Setting that to `False`
would skip this check, and therefore possibly return an approximate
symbolic ring element.
--
Ticket URL: <http://trac.sagemath.org/ticket/14239#comment:11>
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.
