#13055: loss of precision via SR
-------------------------+--------------------------------------------------
Reporter: dsm | Owner: burcin
Type: defect | Status: new
Priority: major | Milestone: sage-5.1
Component: symbolics | Keywords: numerical_approx
Work issues: | Report Upstream: N/A
Reviewers: | Authors:
Merged in: | Dependencies:
Stopgaps: |
-------------------------+--------------------------------------------------
By going via SR we can lose precision when using numerical_approx:
{{{
sage: p
3.1415926535897932384626433832795028841971693993751058209749
sage: parent(p)
Real Field with 200 bits of precision
sage: SR(p)
3.1415926535897932384626433832795028841971693993751058209749
sage: SR(p).n()
3.14159265358979
sage: parent(SR(p).n())
Real Field with 53 bits of precision
}}}
The information is still there, though (as is obvious from the fact the
string produced has all those extra digits):
{{{
sage: SR(p).pyobject()
3.1415926535897932384626433832795028841971693993751058209749
sage: parent(SR(p).pyobject())
Real Field with 200 bits of precision
}}}
This might not seem that significant -- we could interpret "n" as always
defaulting to 53 bits unless specified otherwise -- but it can cause some
headaches when trying to get hold=True to behave nicely. I'd prefer that
f(1.2345678901234567890) give the same answer as f(1.2345678901234567890,
hold=True).n(), especially now that we typically get the precision from
the parent.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13055>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
