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

[Tim Peters]

[Tim]
> 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.

[Guido]
> "Want to", no.  But whether they're teaching Java, C++, or Pascal,
> they have no choice: if they need 0.5, they'll need binary floating
> point, whether they explain it adequately or not.  Possibly they are
> all staying away from the decimal point completely, but I find that
> hard to believe.

Pascal is the only language there with any claim to newbie friendliness
(Stroustrup's essays notwithstanding).  Along with C, it grew up in the era
of mondo expensive mainframes with expensive binary floating-point hardware
(the CDC boxes Wirth used were designed by S. Cray, and like all such were
fast-fp-at-any-cost designs).

As the earlier Kahan quote said, the massive difference between then and now
is the "innocence" of a vastly larger computer audience.  A smaller
difference is that Pascal is effectively dead now.  C++ remains constrained
by compatibility with C, although any number of decimal class libraries are
available for it, and run as fast as C++ can make them run.  The BigDecimal
class has been standard in Java since 1.1, but, since it's Java, it's so
wordy to use that it's as tedious as everything else in Java for more than
occasional use.

OTOH, from Logo to DrScheme, with ABC and REXX in between, *some* builtin
alternative to binary fp is a feature of all languages I know of that aim not
to drive newbies insane.  "Well, its non-integer arithmetic is no worse than
C++'s" is no selling point for Python.

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

> I never said otherwise.

OK, but then I don't know what it is you were saying.  Your sentence
preceding "... strongly recommend this ..." ended:

    this would mean an approximate, binary f.p. result for 1/3, and
    this does not seem to have the support of the educators ...

and I assumed the "this" in "Randy Paush, and ... VPython strongly recommend
this" also referred to "an approximate, binary f.p. result for 1/3".  Which
they did not strongly recommend.  So I'm lost as to what you're saying they
did strongly recommend.

Other people in this thread have said that 1./3. should give an exact
rational or a decimal fp result, but I have not.  I have said 1/3 should not
be 0, but there are at least 3 schemes on the table which deliver a non-zero
result for 1/3, only one of which is to deliver a binary fp result.

> It just boils down to binary fp as the only realistic choice.

For 1./3. and 0.67 I agree (for backward compatibility), but I've seen no
identifiable argument in favor of binary fp for 1/3.  Would Alice's users be
upset if that returned a rational or decimal fp value instead?  I'm tempted
to say "of course not", but I really haven't asked them <wink>.