Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pari polroots gives division by zero sometimes #2418

Closed
sagetrac-cwitty mannequin opened this issue Mar 7, 2008 · 12 comments
Closed

pari polroots gives division by zero sometimes #2418

sagetrac-cwitty mannequin opened this issue Mar 7, 2008 · 12 comments

Comments

@sagetrac-cwitty
Copy link
Mannequin

sagetrac-cwitty mannequin commented Mar 7, 2008

I think the problem may be in how Sage calls polroots; in particular, I'm suspicious of the coercion from CC to pari.

sage: x = polygen(QQ)
sage: p = (x^50/2^100 + x^10 + x + 1).change_ring(ComplexField(106))
sage: len(p.roots())
50
sage: (p/2^100).roots()
---------------------------------------------------------------------------
<class 'sage.libs.pari.gen.PariError'>    Traceback (most recent call last)

/home/cwitty/my-sage/<ipython console> in <module>()

/home/cwitty/my-sage/polynomial_element.pyx in sage.rings.polynomial.polynomial_element.Polynomial.roots()

/home/cwitty/my-sage/gen.pyx in sage.libs.pari.gen._pari_trap()

<class 'sage.libs.pari.gen.PariError'>: division by zero (46)

Component: interfaces

Author: Alex Ghitza

Reviewer: John Cremona

Merged: sage-4.3.1.rc0

Issue created by migration from https://trac.sagemath.org/ticket/2418

@sagetrac-cwitty sagetrac-cwitty mannequin added this to the sage-4.3.1 milestone Mar 7, 2008
@craigcitro
Copy link
Member

comment:1

Actually, this is really just pari giving us an error:

? fp
%4 = (6.223015277861140000000000000 E-61 + 0.E-38*I)*x^50 + (0.E-38 + 0.E-38*I)*x^49 + (0.E-38 + 0.E-38*I)*x^48 + (0.E-38 + 0.E-38*I)*x^47 + (0.E-38 + 0.E-38*I)*x^46 + (0.E-38 + 0.E-38*I)*x^45 + (0.E-38 + 0.E-38*I)*x^44 + (0.E-38 + 0.E-38*I)*x^43 + (0.E-38 + 0.E-38*I)*x^42 + (0.E-38 + 0.E-38*I)*x^41 + (0.E-38 + 0.E-38*I)*x^40 + (0.E-38 + 0.E-38*I)*x^39 + (0.E-38 + 0.E-38*I)*x^38 + (0.E-38 + 0.E-38*I)*x^37 + (0.E-38 + 0.E-38*I)*x^36 + (0.E-38 + 0.E-38*I)*x^35 + (0.E-38 + 0.E-38*I)*x^34 + (0.E-38 + 0.E-38*I)*x^33 + (0.E-38 + 0.E-38*I)*x^32 + (0.E-38 + 0.E-38*I)*x^31 + (0.E-38 + 0.E-38*I)*x^30 + (0.E-38 + 0.E-38*I)*x^29 + (0.E-38 + 0.E-38*I)*x^28 + (0.E-38 + 0.E-38*I)*x^27 + (0.E-38 + 0.E-38*I)*x^26 + (0.E-38 + 0.E-38*I)*x^25 + (0.E-38 + 0.E-38*I)*x^24 + (0.E-38 + 0.E-38*I)*x^23 + (0.E-38 + 0.E-38*I)*x^22 + (0.E-38 + 0.E-38*I)*x^21 + (0.E-38 + 0.E-38*I)*x^20 + (0.E-38 + 0.E-38*I)*x^19 + (0.E-38 + 0.E-38*I)*x^18 + (0.E-38 + 0.E-38*I)*x^17 + (0.E-38 + 0.E-38*I)*x^16 + (0.E-38 + 0.E-38*I)*x^15 + (0.E-38 + 0.E-38*I)*x^14 + (0.E-38 + 0.E-38*I)*x^13 + (0.E-38 + 0.E-38*I)*x^12 + (0.E-38 + 0.E-38*I)*x^11 + (7.888609052210120000000000000 E-31 + 0.E-38*I)*x^10 + (0.E-38 + 0.E-38*I)*x^9 + (0.E-38 + 0.E-38*I)*x^8 + (0.E-38 + 0.E-38*I)*x^7 + (0.E-38 + 0.E-38*I)*x^6 + (0.E-38 + 0.E-38*I)*x^5 + (0.E-38 + 0.E-38*I)*x^4 + (0.E-38 + 0.E-38*I)*x^3 + (0.E-38 + 0.E-38*I)*x^2 + (7.888609052210120000000000000 E-31 + 0.E-38*I)*x + (7.888609052210120000000000000 E-31 + 0.E-38*I)
? polroots(fp)
  *** polroots: division by zero

I think that makes this ticket invalid ... Carl, does that seem reasonable to you? In particular, do you have any code you've written that we might fall back on if Pari fails like this?

@sagetrac-cwitty
Copy link
Mannequin Author

sagetrac-cwitty mannequin commented Jan 23, 2009

comment:2

I certainly don't think the ticket is invalid; it's definitely a bug in Sage (via Pari), even if it's not a bug in the Sage library code.

For this example, it presumably works to divide through by the leading coefficient (to get a monic polynomial) before handing off to Pari. Maybe that's a reasonable strategy in general?

Or, we could just report it as a bug to Pari upstream, and hope they fix it.

@aghitza
Copy link

aghitza commented Jan 3, 2010

comment:3

I've followed Carl's suggestion -- see the attached patch.

@aghitza
Copy link

aghitza commented Jan 3, 2010

Author: Alex Ghitza

@aghitza
Copy link

aghitza commented Jan 3, 2010

Attachment: trac_2418.patch.gz

@JohnCremona
Copy link
Member

comment:4

Positive review. The patch applies to 4.3 and all tests in rings/polynomial pass.

@JohnCremona
Copy link
Member

Reviewer: John Cremona

@rlmill
Copy link
Mannequin

rlmill mannequin commented Jan 13, 2010

comment:5
patching file sage/rings/polynomial/polynomial_element.pyx
Hunk #1 FAILED at 4281
1 out of 2 hunks FAILED -- saving rejects to file sage/rings/polynomial/polynomial_element.pyx.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh trac_2418.patch

@rlmill rlmill mannequin added s: needs work and removed s: positive review labels Jan 13, 2010
@aghitza
Copy link

aghitza commented Jan 13, 2010

comment:6

Robert,

The merging failure is due to the fact that this patch touches the same code as #6237, which just got merged (thank you!). It is a trivial rebase job, and I am attaching the rebased version. I kept the old version around so you can see that no other changes were made.

I'm not sure what the protocol is here. I'd normally go from needs_work to needs_review, but this doesn't really need review...

@aghitza
Copy link

aghitza commented Jan 13, 2010

rebased on 4.3.1.alpha1 and #6237, apply instead of the previous patch

@JohnCremona
Copy link
Member

comment:7

Attachment: trac_2418-rebased.patch.gz

I checked that this applies fine on top of 4.3.1.alpha1 + #6237, and tests pass, so positive review.

@rlmill
Copy link
Mannequin

rlmill mannequin commented Jan 14, 2010

Merged: sage-4.3.1.rc0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants