[issue1580] Use shorter float repr when possible
Preston Briggs added the comment: In all this discussion, it seems that we have not discussed the possibility of adapting David Gay's code, dtoa.c, which nicely handles both halves of the problem. It's also free and has been well exercised over the years. It's available here: http://www.netlib.org/fp/ It'd probably have to be touched up a bit. Guido notes that, for example, malloc is called without checking the return value. Nevertheless, the core is what we're looking for, I believe. It's described in the paper: "Correctly rounded binary-decimal and decimal-binary conversions", David M. Gay It comes recommended by Steele and White (output) and by Clinger (input), in the retrospectives on their seminal papers. -- nosy: +preston ___ Python tracker <http://bugs.python.org/issue1580> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Preston Briggs added the comment: >> It'd probably have to be touched up a bit. > This may be an understatement. :-) Probably so. Nevertheless, it's got to be easier than approaching the problem from scratch. And considering that this discussion has been going on for over a year now, it might be a way to move forward. > In the first 50 lines of the 3897-line dtoa.c file, I see this warning: > > /* On a machine with IEEE extended-precision registers, it is > * necessary to specify double-precision (53-bit) rounding precision > * before invoking strtod or dtoa. [...] */ > > It seems to me that figuring out how and when to do this, and > writing and testing the appropriate configure/pyport/whatever > code, is already a nontrivial task. I would consider compiling the library with flags appropriate to forcing 64-bit IEEE arithmetic if possible. Another possibility is to explore gdtoa.c which is supposed to include code for extended precision, quad precision, etc. Added file: http://bugs.python.org/file13176/unnamed ___ Python tracker <http://bugs.python.org/issue1580> ___>> It'd probably have to be touched up a bit. > This may be an understatement. :-)Probably so. Nevertheless, it's got to be easierthan approaching the problem from scratch.And considering that this discussion has beengoing on for over a year now, it might be a way to move forward. > In the first 50 lines of the 3897-line dtoa.c file, I see this warning: > > /* On a machine with IEEE extended-precision registers, it is > * necessary to specify double-precision (53-bit) rounding precision > * before invoking strtod or dtoa.  [...] */ > > It seems to me that figuring out how and when to do this, and> writing and testing the appropriate configure/pyport/whatever > code, is already a nontrivial task. I would consider compiling the library with flags appropriate to forcing64-bit IEEE arithmetic if possible. Another possibility is to explore gdtoa.cwhich is supposed to include code for extended precision, quad precision, etc. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1580] Use shorter float repr when possible
Preston Briggs added the comment: This all started with email to Guido that y'all didn't see, wherein I wondered if Python was interested in such a thing. Guido said: Sure, in principle, please see the discussion associated with this change. I probably don't have all the required expertise today, but I am patient and persistent. I wouldn't be very fast either, 'cause I have other things on my plate. Nevertheless, it seems like an interesting project and I'm happy to work on it. If Mark or someone else wants to jump in, that's fine too. Preston Added file: http://bugs.python.org/file13199/unnamed ___ Python tracker <http://bugs.python.org/issue1580> ___This all started with email to Guido that y'all didn't see,wherein I wondered if Python was interested in such a thing.Guido said: Sure, in principle, please see the discussion associatedwith this change. I probably don't have all the required expertise today,but I am patient and persistent. I wouldn't be very fast either,'cause I have other things on my plate. Nevertheless, it seems likean interesting project and I'm happy to work on it. If Mark or someone else wants to jump in, that's fine too.Preston ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com