#13055: Better default precision for .n() method
-------------------------------------+-------------------------------------
Reporter: dsm | Owner: burcin
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-
Component: symbolics | duplicate/invalid/wontfix
Keywords: numerical_approx, | Resolution:
sd40.5 | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by jdemeyer):
Losing precision is a ''feature'' of the `.n()` method, that's what it
does. The `x.n()` method asks for a ''numerical approximation'' of `x` to
a precision of 53 bits. This is easily explained. I also like the fact
that neither the implementation nor the user should need to worry about
what `x` is, the output is a real/complex number with 53 bits of
precision.
If you think that `.n()` is wrong, what should `(2/3).n()` return then?
The only possible answer which doesn't lose precision is the rational 2/3.
--
Ticket URL: <http://trac.sagemath.org/ticket/13055#comment:12>
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.
