Mark Dickinson <dicki...@gmail.com> added the comment: So work on the py3k-short-float-repr branch is nearing completion, and we (Eric and I) would like to get approval for merging these changes into the py3k branch before this month's beta.
A proposal: I propose that the short float representation should be considered an implementation detail for CPython, not a requirement for Python the language. This leaves Jython and IronPython and friends free to do as they wish. All that should be required for Python itself is that float(repr(x)) == x for (non-nan, non-infinite) floats x. Does this seem reasonable to people following this issue? If it's controversial I'll take it to python-dev. Eric's summarized his changes above. Here are mine (mostly---some of this has bits of Eric's work in too): - change repr(my_float) to produce output with minimal number of digits, on IEEE 754 big- and little-endian systems (which includes all systems we can actually get our hands on right now). - there's a new file Python/dtoa.c (and a corresponding file Include/dtoa.h) with a cut-down version of Gay's dtoa and strtod in it. There are comments at the top of that file indicating the changes that have been made from Gay's original code. - one minor semantic change: repr(x) changes to exponential format at 1e16 instead of 1e17. This avoids a strange situation where Gay's code produces a 16-digit 'shortest' integer string for a particular float and Python's formatting code then pads with an incorrect '0': >>> x = 2e16+8. # 2e16+8. is exactly representable as a float >>> x 20000000000000010.0 There's no way that this padding with bogus digits can happen for numbers less than 1e16. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1580> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
