#13055: loss of precision via SR
------------------------------------+---------------------------------------
Reporter: dsm | Owner: burcin
Type: defect | Status: new
Priority: major | Milestone: sage-5.1
Component: symbolics | Resolution:
Keywords: numerical_approx | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
------------------------------------+---------------------------------------
Description changed by dsm:
Old description:
> 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.
New description:
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#comment:1>
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.
