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

[Guido van Rossum]

bokr at accessone.com (Bengt Richter) writes:

> 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.

Hm...  We did that in ABC, and it was my idea, and it didn't work out
there.  See another post of mine.

> 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.

Good point.

> 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.

Big "if", see above.

> 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.

So use int(floor(x)).

> 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.

*Conceptually*, exactness is independent from representation.
*Practically*, I think it makes sense to represent all exact numbers
as (unbounded precision) ints or rationals, and all inexact numbers as
doubles.

> 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.

Unclear.  That would be breaking with tradition in Python; it would
probably cause lots of off-by-one errors.  Scheme requires exact
indices, and declares that inexactness is contagious, except maybe in
some special cases, e.g. multiplying an inexact number by an exact
zero *may* return an exact zero in Scheme.  (But there should be an
exception to this exception if the inexact number was infinity, as can
happen with Python floating point on most platforms.)

> 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.

Right -- floor of a rational should return an exact integer.

But note that we don't have a floor function in Python now -- all we
have is math.floor(), and the math functions are defined to always
return a float.

> 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 ;-)

Please see the Scheme docs:

http://www.swiss.ai.mit.edu/ftpdir/scheme-reports/r5rs-html/r5rs_8.html#SEC50

--Guido van Rossum (home page: http://www.python.org/~guido/)