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

[Bengt Richter]

On Fri, 27 Jul 2001 03:35:16 GMT, "Terry Reedy" <tjreedy at home.com> wrote:

>> [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.)
I think they should be, but IMHO linking exactness to representation
types will lead to trouble, unless you reserve float for numbers you
really have to approximate, and rework all floating point literals
so they don't cause artificial inexactness by being unnecessarily
represented as floats. I.e., convert 2.0 to an exact 2, not a float.
Convert 2.5 to rational 25/10, or 5/2, not a float. Etc. That throws
out a lot of good uses for exact floats though.
>
>If I write def(seq, n, k): return seq[3*n//k] and a call receives
>n=20.0 instead of 20, it would accord with the polymorphic rationale
>for new / and // to go ahead and return the item intended.  Or perhaps
>floored numbers should be marked as exact (if the marking is
>independent of type).
>
ISTM floor couldn't make an exact number out of an inexact one unless the
inexactness was known to be constrained to the halfopen interval above
the floor. OTOH, IMHO 20.0 should not be viewed as inexact just because it is
a conventional literal for a floating point representation of 20
(end of sentence ;-). So if it were exact, floor(20.0) would also be exact.

Here's another one. What if you were simulating white noise within an interval,
and you wanted to check on it by counting instances generated that fell in
sub-intervals. Scaling the sub-intervals to width 1.0 and using floor would
be a natural way of getting an index to bins for counting. So one way or
another, there has to be a way to make the floored values exact for the purpose
of indexing. Floor values really are integers, mathematically. They could be
returned as such in a unified number system. But if so, it would be incorrect
to call them exact just because they were integers. To say ok, we'll return
floats is no better. The point is exactness ought to be representation-independent.
floor(4.0 - inexactnessEpsilon) => 3 #not an exact integer because of its heritage.

For practical purposes, the common case ought to be easy to write and fast executing.
Here I think that means indexing should automatically do floor and and raise an
exception if it got inexact inputs. However, when you know you are generating indices
from inexact sources, there should be a way of explicitly coercing exactness on
any number, so you can use the result of floor etc where exactness is required.
If float is reserved for only inexacts, then floor should definitiely return an integer,
not a float, unless it had an inexact input. Blech. All this is implementation talk,
not language talk. exactness is a language key concept for numbers. float is a
foreign-function/foreign-data issue for the language, or perhaps an optimization hint,
but not central, IMHO.

Please see my Number Tree post for more on representation ;-)