[Python-Dev] RE: [Python-numerics]Re: WYSIWYG decimal fractions

[Tim Peters]

[Guido]
> I'll say one thing and then I'll try to keep my peace about this.

If this was one thing, you're suffering major roundoff error <wink>.

> 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.

Agreed.

> Using decimal floating point won't fly either,

If you again mean "by default", also agreed.

> for mostly the same reasons, plus the implementation appears to
> be riddled with gotcha's

It's exactly as difficult or easy as implementing binary fp in software; see
yesterday's link to Cowlishaw's work for detailed pointers; and as I said
before, Cowlishaw earlier agreed (years ago) to let Python use REXX's
implementation code.

> (at least rationals are relatively clean and easy to implement, given
> that we already have bignums).

Oddly enough, I believe rationals are more code in the end (e.g., my own
Rational package is about 3000 lines of Python, but indeed is so general it
subsumes IEEE 854 (the decimal variant of IEEE 754) except for Infs and
NaNs) -- after you add rounding facilities to Rationals, they're as hairy as
decimal fp.

> 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?

A per-module directive specifying the default interpretation of fp literals
within the module is an ugly but workable possibility.

> 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
>   disadvantages.

Good!

> - 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 only "number unification" PEP on the table does not remove all semantic
differences:  1.0 is tagged as inexact under Moshe's PEP, but 1 is not.  So
this is some other meaning for unification.  Trying to be clear.

>   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).

I think you'd have a very hard time finding any pre-college level teacher who
wants to teach binary fp.  Your ABC experience is consistent with that too.

>  But other educators (e.g. Randy Pausch, and the folks who did
> VPython) strongly recommend this based on user observation, so there's
> hope.

Alice is a red herring!  What they wanted was for 1/2 *not* to mean 0.  I've
read the papers and dissertations too -- there was no plea for binary fp in
those, just that division not throw away info.  The strongest you can claim
using these projects as evidence is that binary fp would be *adequate* for a
newbie graphics application.  And I'd agree with that.  But graphics is a
small corner of education, and either rationals or decimal fp would also be
adequate for newbie graphics.

>   As a programmer, as long as there's *some* way to spell integer
>   division (even div(i, j) will do), I don't mind.

Yes, I need that too.

>   The breakage of existig code will be great so we'll be forced to
>   introduce this gradually using a future_statement and warnings.
>
> - "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?

I will.

> PS.  Moshe, please check in your PEPs.  They need to be on-line.

Absolutely.