Opened 9 years ago

Closed 9 years ago

# [with patch] Generalize polynomial .roots() method by adding optional ring= parameter for result ring

Reported by: Owned by: cwitty cwitty major sage-2.8.12 basic arithmetic

### 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.
```

### comment:1 Changed 9 years ago by cwitty

• 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

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.

### comment:2 Changed 9 years ago by robertwb

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 9 years ago by cwitty

The bug Robert found here is now #1100. (It's not caused by this patch.)

### comment:4 Changed 9 years ago by mabshoff

• Resolution set to fixed
• Status changed from new to closed

applied to 2.8.12.rc0

Note: See TracTickets for help on using tickets.