[Python-Dev] PEP239 (Rational Numbers) Reference Implementation and new issues (original) (raw)

Tim Peters tim.one@comcast.net
Wed, 02 Oct 2002 21:31:11 -0400

[Guido]

... Not clear at all. ABC did this, and we found that a common problem was that a program doing numeric stuff would run very slowly (i.e. the opposite of failing noisily).

Time for my yearly repetition of that I believe that, at least for me, many (perhaps most, but not all) of the surprises in ABC were due to that "floating-point literals" (like 6.02e23) were also treated as exact rationals.

... The problem with a fuzz variable is that there's only one, and library modules may end up fighting over the right value for what they are trying to accomplish. Making it a per-module variable causes the opposite set of problems.

Knuth defines a much more sophisticated notion of "fuzzy comparison" for floats (TAoCP Vol 2). That never caught on either. I'm never clear on what people think they're solving with suggestions like these -- binary floating-point is so horrendously at odds with "common sense" regardless that it solves nothing. In APL there was a particular reason for it, in order to create arrays of booleans from whole-array comparison operators efficiently, but that didn't make it a useful scalar gimmick there either, and in my brief APL days the damn fuzz destroyed more careful numeric algorithms than it helped for that reason.

I'm all for adding rationals to the language -- but I'd like them segregated until we have a lot more experience with how they behave.

They behave most like precocious children with voracious appetite .