#16222: Faster exactification using numeric minpoly
-------------------------------------+-------------------------------------
Reporter: gagern | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.3
Component: number fields | Resolution:
Keywords: | Merged in:
Authors: Martin von Gagern | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/16222 | 491dcc4884823cab627f318ea63f0e2504f9f7c2
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Changes (by gagern):
* commit: => 491dcc4884823cab627f318ea63f0e2504f9f7c2
Comment:
These modifications are not ready for inclusion yet, they need some
discussion first.
1. How to get the symbolic expression from `expression_conversion` into
`AlgebraicNumber_base`.
Right now, I use direct access to an underscore-prefixed variable called
`_symbolic_expression`. I'm not sure whether that is acceptable. If cross-
module interfaces should avoid using underscores, we'll have to look for
alternatives. But I rely on the fact that the expression really describes
the number in question, so this certainly isn't a variable the user should
be allowed to tweak. So I don't know a better way yet.
2. Default state of that variable.
Right now, I have a class variable which defaults to `None` and instance
variables which will override this when required. Alternatives would be
setting an instance variable in some (as of now non-existant) constructor,
or avoding a default value altogether and using `hasattr` instead. I
simply wrote what I'd do in my own code, but if there is a sage convention
to write things differently, I'll gladly comply.
3. When to compute the minpoly.
I now do the computation on demand, hoping that expressions cannot be
legally modified after their creation. If they can be modified, we might
want to do the minpoly computation when we do the conversion from symbolic
to algebraic. Likewise if you have reasons to believe that minpoly
computation should not make that conversion noticably slower than it
already is.
4. Test case dependency.
I just noticed that my current doctest depends on ticket:14239, but that
should be easy to fix. If you have a favorite example, let me know, but
otherwise I'll come up with something.
5. The `_more_precision` loop.
I have more trouble testing that `_more_precision` codepath inside
`_exact_symbolic`. Can anyone come up with a situation where identifying
the correct root would need more than default precision but where numeric
minpoly computation would still succeed? If not, what shall we do? Shall
we deactivate that whole loop, and simply return without taking action if
we find more than one root which could match?
6. How to obtain the roots.
Is `p.roots(self.parent(), False)` the right thing to do, or is this too
high-level, should I use something more basic here?
----
New commits:
||[http://git.sagemath.org/sage.git/commit/?id=bb01e0b15e1a4e7e1e112faa25abbcd6d6c06238
bb01e0b]||{{{Drive-by fix to minpoly documentation.}}}||
||[http://git.sagemath.org/sage.git/commit/?id=491dcc4884823cab627f318ea63f0e2504f9f7c2
491dcc4]||{{{Faster exactification using numeric minpoly.}}}||
--
Ticket URL: <http://trac.sagemath.org/ticket/16222#comment:2>
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.
