-
-
Notifications
You must be signed in to change notification settings - Fork 515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[with positive revew] automatic precision extension for long decimal literals does very strange things #962
Comments
Attachment: 962.patch.gz Initial version |
comment:4
I posted an initial patch which fixes some of the major issues. I would like others to comment on it to make sure the final version of this patch does the "right thing" since it will break lots of doctests. |
comment:5
Here is the behavior of the above examples after the patch:
|
comment:6
Actually, I think that all of the last three examples should give 53 (that is, leading zeroes shouldn't affect the precision). I think that matches the rules for significant figures I learned in grade school... |
comment:8
NOT YET -- note that I think many doctests will (and should) break after applying this patch, so this isn't being posted to actually include in the next release. It's being posted for feedback. After people like it, then Mike will post an additional patch that fixes all failing doctests. I also think I agree with Carl witty's remark above about significant figures. |
comment:11
Patch updated that now gives the following results:
|
comment:12
Attachment: 962-2.patch.gz Looks good to me! Thank you for making so many changes at my request. |
comment:13
This causes the following doctest failures:
I will post a patch in a bit fixing this. |
comment:14
Excellent! I read through 962-doctests.patch (yes, I really did), and I only saw one issue: on real_mpfr.pyx line 21, we will need to change:
to
|
comment:15
The patches should be applied in this order:
|
Attachment: 962-doctests.patch.gz |
comment:16
Merged in 2.8.15.alpha2. |
Long decimal literals become floating-point numbers whose precision depends on the length of the input literal in characters. See this script for some of the confusing (and, in my opinion, wrong) behavior that results.
Component: basic arithmetic
Issue created by migration from https://trac.sagemath.org/ticket/962
The text was updated successfully, but these errors were encountered: