Home Original page

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

Tim Peters tim.one at comcast.net
Wed Oct 2 21:31:11 EDT 2002 
[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 <wink>.
More information about the Python-list mailing list