#13055: Better default precision for .n() method
--------------------------------------------+------------------------
Reporter: dsm | Owner: burcin
Type: defect | Status: new
Priority: major | Milestone: sage-6.4
Component: symbolics | Resolution:
Keywords: numerical_approx, sd40.5 | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
--------------------------------------------+------------------------
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.
--
Comment (by jdemeyer):
I doubt that this is a bug. How would you guess the default precision for
the `.n()` method?
--
Ticket URL: <http://trac.sagemath.org/ticket/13055#comment:7>
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.
