Against PEP 240

[Alex Martelli]

"Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
news:lymI7ZA$z2E7EwyU at jessikat.demon.co.uk...
> I am strongly opposed to the intent of PEP 240. I would prefer the
> literal floats to remain. Let those that want infinite precision pay the
> price by adding an 'R' to their literals. This PEP seems purely biassed
> towards the needs of naive programmers and I feel that is wrong; this
> whole industry has grown up with the old style (and coped quite well).

Historically, this latest assertion is not really correct.  In "this
whole industry" (of programming), an extremely significant and important
role was played by the language COBOL.  Some claim that the dollar
value of existing Cobol programs (not sure how they estimate that --
by cost of development and maintenance, or by what they make or save
for the firms owning and operating the programs) is larger than the
value of all programs in all other existing languages added together.

In Cobol, when you write 7.35, it doesn't magically transmogrify
into 7.3499999999999996.  Banks, auditors, and other accounting-
oriented types (including a vast majority of customers) get quite
understandably upset at languages whose default behavior is that --
looks like somebody stole a small but non-zero fraction of a cent.
Handling exact financial calculations with floating-point numbers
is delicate and subtle.  Cobol, and the entire financial backbone
of "this whole industry", are predicated on the idea that when
one writes 7.35 one MEANS 7.35, NOT "whatever the machine can in
fact represent, in a way that's comfortable to IT, that is very
close (but most likely NOT exactly equal) to 7.35".  How comfy the
MACHINE is ain't really the customer's top concern.

PL/I (another language of historical importance), SQL (a very
widespread language indeed), and others, try to compromise
between the needs of accounting and those of scientists and
engineers.  Depending on how a field/column/variable is
declared, 7.35 may mean EITHER 7.35 or 7.3499999999999996.

In Python, having no declarations, we have to choose one or
the other, of course.  Your claim that "the whole industry"
invariably chooses the latter is demonstrably false, since
Cobol, PL/I, and SQL *ARE* very much a part of "the whole
industry".  Rexx is also based on 7.35 meaning exactly 7.35,
neither more nor less; it was the premier scripting language
for both IBM mainframes and (I'm told) Amiga computers.  I'm
not sure what various dialects of Lisp, Scheme, Prolog, Erlang,
Haskell, and other non-classic languages do, but I'd bet that
SOME of them take 7.35 as meaning 7.35 (aka 147/20, an exact
rational number).  I even suspect other scripting languages
behave similarly, though I don't recall precisely.

"The whole industry" is not JUST made up of Fortran, Pascal,
and C and its descendants.  It's a BIG world out there, after
all.  And for MOST users who have not already been brainwashed
by a strongly-floating-point-oriented language, the idea that
7.35 means 7.35 and not 7.3499999999999996 has *VERY* strong
appeal indeed.  It would seem to me the burden of proof should
be on those who claim the contrary, rather than a burden of
syntax stay forever on the backs of most users to have to say
"7.35 ***AND I REALLY TRULY HONESTLY MEAN _IT_ AND NOT SOME
_OTHER_ NUMBER, SO HELP ME GUIDO***!!!".


> If naive users are to be the only designers we'll end up badly.

Anybody who thinks he knows what he's doing when floating
point is involved IS either naive, or Tim Peters (well, it
COULD be W. Kahan I guess, but I don't think he writes here).

http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf quotes
Gosling's well-known "95% of the folks out there are
completely clueless about floating-point" and claims it's
likely MORE than 95% -- a good fraction of the text is
showing (indirectly) that the reader (and, likely, Dr
Gosling too) is in that "more than 95%".  I'm in there,
too.  http://http.cs.berkeley.edu/~wkahan/Triangle.pdf, too.

Oh, read ALL Kahan has written, and if you emerge still
thinking you KNOW what you're doing when floating point
is involved, you're either Tim Peters, or the world champ
of hubris.  I've taught numerical computing as a university
professor, I've made a (very good) living as a consultant
on supercomputing issues, I've been (and am) the numerics
(inter alia) guru in this firm, and I *STILL* tripped over
some of Kahan's challenges.  I'm second to none in my
hubris (spot the self-referential tinge here:-), but still
I've had to admit: I *DON'T* always know what I'm doing
when floating point is involved.  I'm part of that "more
than 95%" (and so is Gosling).  I'm "a naive user" (of
the trickiest of floating-point's darned subtleties).

I'm not sure that if people such as me and Gosling were
"the only designers" we'd end up ALL that badly -- as
long as NO floating point was involved (or we had a
Peters or Kahan on hand for a consultation:-).  The key
issue is making *SURE*, *DARN* sure, that floating point
gets involved only when it *NEEDS* to be.  And that means
that floating point must NOT be the *DEFAULT* (as in
Fortran, Pascal, C) but only appear *ON A SYNTACTICALLY
EXPLICIT REQUEST FOR IT*.  "Slinging floating point
around implicitly and by default considered harmful"...!-)


Alex