Against PEP 240

[Paul Moore]

On Wed, 30 May 2001 09:05:23 +0200, "Alex Martelli" <aleaxit at yahoo.com> wrote:
>A "traditional floating-point fan" must be somebody with experience
>enough to make the concept of syntax decoration easy.  The "other
>side" just wants 7.35 to MEAN 7.35, no more, nor less, and would
>most likely be hard put to understand the differences between that
>being a floating-point decimal number, or a rational -- in EITHER
>case, 7.35 would MEAN 7.35, the key issue.

My view is that the various notations have significantly different
*conceptual* meanings in people's minds. A lot of the difficulties arise with
the fact that the internal representations used in computers don't always
match up with those concepts.

Specifically, I think of 7.35 as a *decimal*, and 735/100 as a *fraction* (or
rational, if I'm feeling precise :-)) They are not the same in my mind - not
least because 1.0/3.0 is not exactly representable as a decimal, whereas 1/3
is an exact fraction.

I'm comfortable with this difference, and ideally I would prefer Python to
have a separate rational literal form (as some other languages do) and keep
the decimal literal form (7.35) for a decimal internal representation of some
form. That way, the literal forms work like my intuition does.

Oddly, I have no concrete concept which matches with exponential form
(0.735e1). This form feels like a "scientific" notation, for specialist
purposes (I'd never use it for money, for example).

On the other hand, *all* of the literal notations are solidly decimal. Using a
binary internal representation introduces a distinct mismatch between concept
and implementation. Just because computer scientists are used to it, doesn't
make it accessible to the general user (and saying that you need training to
understand the complexities of binary floating point is the worst sort of
elitism...)

Suffixed representations (7.35F, 123456789123456789L, etc) feel to me like
"specialised" forms - and as such have a built-in warning that something
subtle is going on (which argues against the "L" suffix on longs - it's the
"normal" integers which need the warning, that they overflow - as well as
arguing *for* having a suffix for literals which denote binary forms).

[out of context unattributed quote - sorry]
>> A naive user might expect an exact result.

The point is that the users are *not* naive. They just don't have a grounding
in all of the subtleties of the way computers make a mess of perfectly simple
and logical calculations :-) It's not naive to expect 0.1 * 10.0 to equal 1.0.
Especially as many of the people involved are *perfectly* aware that 1.0/3.0
cannot be represented exactly, and so doing the calculation (1.0/3.0) * 3.0
has subtle issues.

Needing specialist training in the implementation of numbers in a computer is
*not* naivety - it's a failing in the way computer languages work. 

Paul