#18593: Relative tolerance in French Sage book
-------------------------------------+-------------------------------------
Reporter: rbeezer | Owner:
Type: defect | Status: positive_review
Priority: trivial | Milestone: sage-6.8
Component: documentation | Resolution:
Keywords: french book | Merged in:
doctest tolerance | Reviewers: Marc Mezzarobba
Authors: Rob Beezer | Work issues:
Report Upstream: N/A | Commit:
Branch: u/rbeezer | bf5b521bcbba59895cfae220284a3bc6ec05d12e
/tolerance-french-book | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by cpernet):
One should not expect the numerical garbage to be reproducible when
changing architectures: even if basic operations are compliant with the
IEEE norm, the way they are scheduled (by the compiler or programmer)
impacts the numerical noise.
Looking at the condition number (1222), we can assume that up to 3 digits
can be lost. So the bug was indeed that the tolerance was probably set to
a too low value.
I ran directly the LAPACK degesv implementation of GotoBLAS-2.11 on
various architectures and got the following values:
x = [-1.5000000000000067 ,-0.50000000000000389 ,2.7500000000000098] for
Intel Haswell, SandyBridge and Westmere, AMD K8,
x = [-1.4999999999999918 ,-0.49999999999999678 ,2.7499999999999911] for
AMD Bulldozer
x = [-1.5000000000000135 ,-0.50000000000000855 ,2.7500000000000213] for
AMD K10
--
Ticket URL: <http://trac.sagemath.org/ticket/18593#comment:5>
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.
