Tim Peters added the comment: Guido, right, for that to work reliably, double->str and str->double must both round correctly on the platform doing the repr(), and str->double must round correctly on the platform reading the string.
It's quite easy to understand why at a high level: a simple (but tedious) pigeonhole argument shows that there are more representable doubles than there are possible 16-digit decimal outputs. Therefore there must exist distinct doubles (say, x and y) that map to the same 16-digit decimal output (in fact, there are cases where 7 consecutive doubles all map to the same correctly-rounded 16-digit decimal string). When reading that back in, there's no room for error in deciding which of {x, y} was /intended/ -- the str->double conversion has to be flawless in deciding which of {x, y} is closest to the 16-digit decimal input, and in case x and y are equally close, has to apply 754's round-to-nearest/even rule correctly. This can require exact multi-thousand bit arithmetic in some cases, which is why the 754 standard doesn't require it (thought to be impractically expensive at the time). > which would really turn the educational issue into an educational > nightmare, trying to explain why two numbers both print the same > but compare unequal Well, newbies see that in, e.g., spreadsheets every day. You generally have to work to get a spreadsheet to show you "all the digits"; in some spreadsheets it's not even possible. "Not all digits are displayed" should be within the grasp of must students without suffering nightmares ;-) __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com