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

Doctest failure in sage/rings/polynomial/polynomial_element.pyx on Solaris #14436

Closed
jpflori opened this issue Apr 10, 2013 · 8 comments
Closed

Comments

@jpflori
Copy link

jpflori commented Apr 10, 2013

sage -t devel/sage/sage/rings/polynomial/polynomial_element.pyx
**********************************************************************
File "devel/sage/sage/rings/polynomial/polynomial_element.pyx", line 1054, in sage.rings.polynomial.polynomial_element.Polynomial.inverse_mod
Failed example:
    parent(poly)([ 0.0 if abs(c)<=1e-14 else c for c in poly.coeffs() ])
Expected:
    1.0
Got:
    1.02140518266e-14*x^2 + 1.0
**********************************************************************
1 item had failures:
   1 of  16 in sage.rings.polynomial.polynomial_element.Polynomial.inverse_mod
    [1375 tests, 1 failure, 84.4 s]
----------------------------------------------------------------------
sage -t devel/sage/sage/rings/polynomial/polynomial_element.pyx  # 1 doctest failed
----------------------------------------------------------------------
Total time for all tests: 88.1 seconds
    cpu time: 75.4 seconds
    cumulative wall time: 84.4 seconds

It looks like there is more numerical noise than expected.
Changing 1e-14 to 1e-13 might be a sensible solution.

CC: @jdemeyer

Component: porting: Solaris

Keywords: solaris numerical noise

Reviewer: Jeroen Demeyer

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

@jpflori
Copy link
Author

jpflori commented Apr 10, 2013

comment:1

I've not looked at the code, so I don't know if we really expect the coefficients rounded to zero to be less than 1e-14, or if that's just an arbitrary bound which looked close enough to zero.

@jdemeyer
Copy link

Attachment: trac_10508_doctest.rebased.patch.gz

@jdemeyer
Copy link

Author: Jeroen Demeyer

@jpflori
Copy link
Author

jpflori commented Apr 10, 2013

comment:3

Please note this happened with ATLAS 3.10.1.p0 from #10508 which may be used in the linear algebra step of the algorithm.

And the bound seems quite random, at least there is no justification for this choice, nor a precise error bounding stated anywhere.

@jdemeyer
Copy link

Changed author from Jeroen Demeyer to none

@jdemeyer
Copy link

comment:4

Replying to @jpflori:

Please note this happened with ATLAS 3.10.1.p0 from #10508

In that case, the problem is already fixed by a patch on that ticket.

@jdemeyer
Copy link

Reviewer: Jeroen Demeyer

@jdemeyer jdemeyer removed this from the sage-5.10 milestone Apr 10, 2013
@jpflori
Copy link
Author

jpflori commented Apr 10, 2013

comment:6

Oh yeah, really sorry about that...
I completely forgot to install the Sage library patches on this system...

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

2 participants