proposed language change to int/int==float (was: PEP0238 lament)

[Ken Seehof]

----- Original Message -----
From: "Guido van Rossum" <guido at python.org>
Newsgroups: comp.lang.python
To: <python-list at python.org>
Sent: Thursday, July 26, 2001 2:18 PM
Subject: Re: proposed language change to int/int==float (was: PEP0238
lament)


> [Guido]
> > >> >The important thing is that i//j will return the same value
> > >> >regardless if i and j ar ints or floats; ditto for the new i/j.
>
> [Grant]
> > >> If that's important, why won't the other math operators do it???
>
> [Guido]
> > >Huh?  They do (apart from unavoidable round-off errors).  1+2 ==
1.0+2.0.
>
> [Grant]
> > They compare equal with the "==" operator, but they are not
> > the same value:
> >
> > >>> 1+2
> > 3
> > >>> 1.0+2.0
> > 3.0
> > >>>
> >
> > ... unless 3 and 3.0 are "the same value".  In which case my
> > definition of that phrase is merely different than yours.
>
> [Guido]
> Well, they have the same *mathemtical* value, and Python does its
> darndest to treat them as equal everywhere.  For example, a dict with
> int keys can be indexed with corresponding float or complex values.
> Exceptions are operations that intrinsically require ints, e.g. list
> indexing.  (This would change under a unified numeric system though, I
> expect, unless inexact numbers are excluded from being used as
> sequence indices.)
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> --

This scares me.  The whole numeric unification thing seems to be hiding
all the intrinsically difficult properties of numbers.  Kind of like Windows
ME trying to hide all the intrinsically difficult properties of computers.

Hiding difficult properties usually makes those properties more difficult
in the long run, while appeasing beginners in the short run.  This is not
a good trade off.

Here's some questions that come to mind that have a "sweep the can
of worms under the rug" theme:

1. If inexact numbers are excluded from being used as sequence indices,
won't there be a tendency for programs to have more special case bugs?
The value of a variable in a calculation might be usually exact, but inexact
once in awhile.  So floats can be used as indices until there is a precision
error?  Yikes!  And I have a funny feeling in my stomach that this is just
the tip of the iceberg.  Floats may or may not turn out to be exact
depending
on details of a particular run.  This is a Bad Thing.  Integers are always
exact.  This is a good thing.

2. Wouldn't a function in an extension module that takes a number as an
argument be significantly more difficult to write, since it would have
figure out the actual runtime type of the number and deal with all the
different cases?  Right now, I just have to verify the type.  Seems like
even if you somehow solve the problem of breaking python code, you
will break extension code badly.  One thing I like about python is that
it is highly compatible with its extension language.  The further we get
from the current symmetry between python and C/C++ the harder it
will be to write extensions.  The same goes for case sensitivity BTW.

3. Why do you expect it to be wise to hide all the numeric issues under
a level of abstraction?  The issues will still exist, but will just be more
obscure.  Right now, we have a simple and explicit numeric system with
simple and well understood problems.  Trying to make it simpler for
beginners by adding complexity to the overall system won't work.

The basic fact is that all conceivable numeric systems suck badly for
different reasons, (including the one we currently have).  And for every
problem there is a solution that's even worse.  Just keep what we have.
It sucks less badly than all of the alternatives.  Even the / operator has
it's virtues.  It make integers a closed set with respect to all the basic
operators.  This is a Good Thing.  The grand unification of numbers is
the other way to try to create a closed set, so it's not surprising that the
1/2 debate eventually lead to it.  But it won't work because the different
kinds of numbers really are different and trying to stuff them into the
same set is inherently unnatural.  I'd accept 1/2 == 0.5 with 1//2 == 0
as the integer quotient operator, but going further than that is a mistake
IMHO.

Kinda-weird-that-computers-are-so-lousy-at-dealing-with-numbers-ly yrs,

- Ken

"Things should be made as simple as possible -- but no simpler."
- A. Einstein