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
Perl_my_atof does not "correctly round" #9639
Comments
From chris.hall@highwayman.comThis is a bug report for perl from chris.hall@highwayman.com, Decimal to binary conversion is hard. The requirements of IEEE-754 are difficult to achieve, requiring One of the requirements is that when working to at least 17 The standard also requires the conversion to be "correctly rounded". The following demonstrates that the conversion Perl_my_atof2() (in my @p = (0x3FEF, 0xFFFF, 0xFFE0, 0x0000) ; printf "0x%04X_%04X_%04X_%04X -> %s -> 0x%04X_%04X_%04X_%04X\n", In this case the problem is that the decimal digits 99999999976716936 For completeness, the values around the test value are: 0x3FEF_FFFF_FFDF_FFFF == 0.999999999767169245323827908578 (approx) NB: the above is just one example of the failure of Perl_my_atof2(). NB: The existing code will do OK with numbers with 15 or fewer It appears that Perl_my_atof2() exists in order to: (a) cope with character set and locale issues, (b) provide a consistent, system independent, syntax for numbers, (c) avoid some overflow issues on certain machines My recommendation would be to ditch all the attempt to do the decimal It appears that Perl's syntax for decimal numbers accepts '.' as well I note that Kernighan & Richie ('The C Programming Language', 2nd Ed) Flags: This perlbug was built using Perl 5.10.0 in the Fedora build system. Site configuration information for perl 5.10.0: Configured by Red Hat, Inc. at Fri Nov 28 19:14:03 EST 2008. Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Locally applied patches: @INC for perl 5.10.0: Environment for perl 5.10.0: |
From @ysthOn Sun, January 25, 2009 11:26 am, Chris Hall wrote:
While the above is true, I think the original drive to replace the I also thought there was (d) avoid rounding and other bugs in some |
The RT System itself - Status changed from 'new' to 'open' |
From @nwc10On Sun, Jan 25, 2009 at 12:52:08PM -0800, Yitzchak Scott-Thoennes wrote:
I don't remember any issues with rounding bugs. The only bug was that the Personally I always felt that a wrapper that sanitised input to avoid Nicholas Clark |
From module@renee-baecker.de
So this ticket can be closed? |
From chris.hall@highwayman.comOn Sat Jan 31 07:07:54 2009, reneeb wrote:
I don't think so. The problem is that the "alternative solution" (the current I didn't find any earlier bug report, so you may take a view on the Nevertheless, the current implementation is not fit for purpose. Someone who fully understands the expected semantics, especially wrt When I grep Perl_my_atof2() and S_mulexp10() (in 5.10.0 source) I get: $ grep Perl_my_atof2 * $ grep S_mulexp10 * I was not expecting to see these used outside numeric.c -- and I regret -- |
From @nwc10On Sat, Jan 31, 2009 at 07:07:55AM -0800, reneeb via RT wrote:
I didn't say that :-) I didn't actually say what we should do next. I don't know. (I was just adding to the ticket what I remembered about the decisions that Nicholas Clark |
From @dcollinsnPerl 5.10.0: Perl 5.20.0 and blead: I do believe this ticket can be closed. |
From [Unknown Contact. See original ticket]Perl 5.10.0: Perl 5.20.0 and blead: I do believe this ticket can be closed. |
From @cpansproutOn Tue Jun 07 17:22:45 2016, dcollinsn@gmail.com wrote:
Are you sure the difference is not just due to different default configuration values on the different versions of perl? Could you do a bisect? -- Father Chrysostomos |
From @cpansproutOn Tue Jun 07 17:51:47 2016, sprout wrote:
Never mind. I see your follow-up note in ticket #43811. -- Father Chrysostomos |
From @cpansproutOn Tue Jun 07 17:52:42 2016, sprout wrote:
Er, I meant #53784. -- Father Chrysostomos |
Migrated from rt.perl.org#62746 (status was 'open')
Searchable as RT62746$
The text was updated successfully, but these errors were encountered: