So I go offline for a couple of days to entertain guests and have my
body kicked around in a dance class, and I have 25 messages discussing
Python's numeric model waiting for me...
I was hoping that Tim would chime in, but he's apparently taken the
weekend off -- very much out of character. :-)
I like the idea of a PEP to rework the numeric model. I think that
Moshe, being a mathematician by training, will make a good editor. I
think that this has a snowball's chance in hell to make it into Python
2.1 however -- there are many deep issues, and it's a bad idea to
experiment too much in the released version of the language.
Some of the issues are more usability issues than of a mathematical
nature. For example, Tim has conjectured that using binary floating
point will always be a problem for the "unwashed masses" -- the only
thing they might understand is decimal floating point, not rational
numbers. There are at least two issues here:
(1) As long as the internal representation is not the same as what is
commonly printed, there will be surprises -- with rationals just
as much as with floating point. There are issues with decimal
floating point too, but they are only the issues having to do with
loss of precision in the calculation (e.g. 1.0 - 1e-20 yielding
1.0) and not with loss of precision in the printing, where most of
the "bug reports" we get seem to concentrate.
(2) Rational numbers have the unpleasant property of growing
unboundedly during many innocent calculations, thereby using up
exorbitant amounts of memory and slowing down the calculation --
often mysteriously, because what is displayed is truncated.
Another issue that I might bring up is that there are no inexact
numbers (each floating point number is perfectly exact and rational)
-- there are only inexact operations. I'm not sure what to do with
this though.
If we take its meaning literally, the isreal() function should only
return true for numbers for which isrational() is also true:
mathematically speaking, real numbers that aren't also rational don't
have an easy finite representation, since they are numbers like
sqrt(2) or pi.
I'll leave it to Tim to explain why inexact results may not be close
to the truth.
Tim may also break a lance for IEEE 754.
Finally, the PEP doesn't talk about how the numeric model can be
extended, and how other numeric types can be blended in. E.g. I've
heard of wild floating point representations that make multiplication
and division really cheap but addition a pain, rather than the other
way around; some people may want to have long ints implemented using
the GNU mp library, and so on. Such custom types should be supported
as well as native types -- like they are now.
--Guido van Rossum (home page: http://www.python.org/~guido/)
PS. The "1.isreal()" problem is a non-problem. This question is only
interesting to ask about variables.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4