[Python-Dev] Minutes from the Numeric Coercion dev-day session

[Tim Peters]

[Guido, to David Ascher]
> ...
> One thing we *could* agree to there, after I pressed some people: 1/2
> should return 0.5.

FWIW, in a show of hands at the devday session after you left, an obvious
majority said they did object to that 1/2 is 0 today.  This was bold in the
face of Paul Dubois's decibel-rich opposition <wink>.  There was no consensus
on what it *should* do instead, though.

> Possibly 1/2 should not be a binary floating point number -- but then
> 0.5 shouldn't either, and whatever happens, these (1/2 and 0.5) should
> have the same type, be it rational, binary float, or decimal float.

I don't know that imposing this formal simplicity is going to be a genuine
help, because the area it's addressing is inherently complex.  In such cases,
simplicity is bought at the cost of trying to wish away messy realities.
You're aiming for Python arithmetic that's about 5x simpler than Python
strings <0.7 wink>.

It rules out rationals because you already know how insisting on this rule
worked out in ABC (it didn't).

It rules out decimal floats because scientific users can't tolerate the
inefficiency of simulating arithmetic in software (software fp is at best
~10x slower than native fp, assuming expertly hand-optimized assembler
exploiting platform HW tricks), and aren't going to agree to stick physical
constants in strings to pass to some "BinaryFloat()" constructor.

That only leaves native HW floating-point, but you already know *that*
doesn't work for newbies either.

Presumably ABC used rationals because usability studies showed they worked
best (or didn't they test this?).  Presumably the TeachScheme! dialect of
Scheme uses rationals for the same reason.  Curiously, the latter behaves
differently depending on "language level":

> (define x (/ 2 3))
> x
2/3
> (+ x 0.5)
1.1666666666666665
>

That's what you get under the "Full Scheme" setting.  Under all other
settings (Beginning, Intermediate, and Advanced Student), you get this
instead:

> (define x (/ 2 3))
> x
2/3
> (+ x 0.5)
7/6
>

In those you have to tag 0.5 as being inexact in order to avoid having it
treated as ABC did (i.e., as an exact decimal rational):

> (+ x #i0.5)
#i1.1666666666666665
>

> (- (* .58 100) 58)   ; showing that .58 is treated as exact
0
> (- (* #i.58 100) 58) ; same IEEE result as Python when .58 tagged w/ #i
#i-7.105427357601002e-015
>

So that's their conclusion:  exact rationals are best for students at all
levels (apparently the same conclusion reached by ABC), but when you get to
the real world rationals are no longer a suitable meaning for fp literals
(apparently the same conclusion *I* reached from using ABC; 1/10 and 0.1 are
indeed very different beasts to me).

A hard question:  what if they're right?  That is, that you have to favor one
of newbies or experienced users at the cost of genuine harm to the other?