Opened 10 years ago
Closed 10 years ago
#995 closed defect (fixed)
[with patch] Generalize polynomial .roots() method by adding optional ring= parameter for result ring
Reported by: | cwitty | Owned by: | cwitty |
---|---|---|---|
Priority: | major | Milestone: | sage-2.8.12 |
Component: | basic arithmetic | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | Work issues: | ||
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
<wstein> Better might be to improve the roots function so that it can take an optional ring as input. e.g., f = x^3 + 1 (over QQ say), then f.roots(ComplexField(200)) would give the roots in that field. What do you think? <cwitty> I like it. I like it a lot. f.roots(RealField(200)), f.roots(AA), f.roots(RealIntervalField(200)) ... <wstein> Yep. And it could be intelligent, but when it doesn't know what to do just return f.change_ring(R).roots(...) But in many cases it could use that f is defined over a better ring than R, e.g., QQ, to find the roots to lots of precision.
Attachments (2)
Change History (6)
Changed 10 years ago by
Changed 10 years ago by
comment:1 Changed 10 years ago by
- Milestone changed from sage-2.9.1 to sage-2.8.12
- Summary changed from Generalize polynomial .roots() method by adding optional ring= parameter for result ring to [with patch] Generalize polynomial .roots() method by adding optional ring= parameter for result ring
comment:2 Changed 10 years ago by
It works great in almost all cases, but
sage: R.<x> = ZZ[] sage: f = 2*x-3 sage: f.roots(ZZ) [(3/2, 1)]
Perhaps this is due to the default behavior of roots() over Z, not the new code (which is really nice).
comment:3 Changed 10 years ago by
The bug Robert found here is now #1100. (It's not caused by this patch.)
comment:4 Changed 10 years ago by
- Resolution set to fixed
- Status changed from new to closed
applied to 2.8.12.rc0
Note: See
TracTickets for help on using
tickets.
This adds a ring= argument for the univariate polynomial .roots() method, so that you can find the complex roots of a polynomial given over QQ (along with many other possibilities). Along with that change, we change the default root-finding algorithm for polynomials over RR and CC to numpy instead of Pari; this is vastly faster, but occasionally slightly less accurate, and does not give exactly the same answers on different architectures.
These patches depend on the patch from #1096; without it, some of the doctests will fail.
These patches pass -testall on my 32-bit and 64-bit x86 Linux boxes, but have not been tested on other platforms; it's possible that the floating-point answers will vary more than allowed by the doctests.