[Python-Dev] Re: WYSIWYG decimal fractions
Guido van Rossum
Thu, 15 Mar 2001 06:55:56 -0500
I'll say one thing and then I'll try to keep my peace about this.
I think that using rationals as the default type for
decimal-with-floating-point notation won't fly. There are too many
issues, e.g. performance, rounding on display, usability for advanced
users, backwards compatibility. This means that it just isn't
possible to get a consensus about moving in this direction.
Using decimal floating point won't fly either, for mostly the same
reasons, plus the implementation appears to be riddled with gotcha's
(at least rationals are relatively clean and easy to implement, given
that we already have bignums).
I don't think I have the time or energy to argue this much further --
someone will have to argue until they have a solution that the various
groups (educators, scientists, and programmers) can agree on. Maybe
language levels will save the world?
That leaves three topics as potential low-hanging fruit:
- Integer unification (PEP 237). It's mostly agreed that plain ints
and long ints should be unified. Simply creating a long where we
currently overflow would be the easiest route; it has some problems
(it's not 100% seamless) but I think it's usable and I see no real
- Number unification. This is more controversial, but I believe less
so than rationals or decimal f.p. It would remove all semantic
differences between "1" and "1.0", and therefore 1/2 would return
0.5. The latter is separately discussed in PEP 238, but I now
believe this should only be done as part of a general unification.
Given my position on decimal f.p. and rationals, this would mean an
approximate, binary f.p. result for 1/3, and this does not seem to
have the support of the educators (e.g. Jeff Elkner is strongly
opposed to teaching floats at all). But other educators (e.g. Randy
Pausch, and the folks who did VPython) strongly recommend this based
on user observation, so there's hope. As a programmer, as long as
there's *some* way to spell integer division (even div(i, j) will
do), I don't mind. The breakage of existig code will be great so
we'll be forced to introduce this gradually using a future_statement
- "Kinds", as proposed by Paul Dubois. This doesn't break existing
code or change existing semantics, it just adds more control for
those who want it. I think this might just work. Will someone
kindly help Paul get this in PEP form?
PS. Moshe, please check in your PEPs. They need to be on-line.
--Guido van Rossum (home page: http://www.python.org/~guido/)