Mark Dickinson <dicki...@gmail.com> added the comment: Another issue to consider, brought to my attention by Rick Regan:
Python's dtoa.c code likely misbehaves (i.e., returns incorrectly rounded results) if the FPU rounding mode is anything other than the round-half-to-even default. (This is also true of Gay's original dtoa.c, I suspect.) For example, the quick-return path in strtod does a single floating-point operation on exact arguments, so will end up behaving according to the FPU rounding mode. The long integer-arithmetic-based path will likely return round-half-to-even results, independently of the FPU rounding mode. It's debatable what Python should do if the FPU rounding mode is something other than round-half-to-even. It can either: - try to honour the FPU rounding mode, or - ignore the rounding mode completely, always doing round-half-to-even. I'd prefer the latter behaviour, for various reasons: - it maintains consistency across platforms - it's consistent with many other Python operations, that already do round-half-to-even regardless of FPU rounding mode---examples include float.fromhex and float.hex, true division of integers, the round() function... It seems possible that Python might one day want to be able to control the rounding direction of decimal <-> binary conversions, but when that day comes I don't think playing with the FPU rounding mode is going to be the best control mechanism. I don't regard this as a terribly serious issue, though: most normal users are unlikely to end up in a situation where the FPU rounding mode has changed unless they've been deliberately and knowingly messing with FPU settings. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9009> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
