floor() function and mathematical integers

[Dennis E. Hamilton]

I beg to differ.  While it is true that all floats above a certain magnitude
always express integral (i.e., whole-number) magnitudes, it is not the same
as to say they behave as integers.  In particular, the Peano axioms fail
with respect to arithmetic on the ones that are too-much greater than 1.
So, it is mute that ceil(x) = -floor(-x)) still, if x+1 is not different
than x.

It is because above a certain scale factor, the floats don't correspond
1-to-1 to mathematical integers any longer.  (And of course they never did
have a correspondence to even the rationals, let alone the reals!)  They
start leaving more and more of the integers out.  The key demonstration is
when a+1==a in the arithmetic of the computer system.

You are pointing at a problem I have been pondering.  Maybe you can help me
clarify it.  It is apparently one that being around computers doesn't
alleviate, although we have all the evidence we need for an empirical
demonstration!

Here's my hypothesis:  For the most part, we attribute integer-ness to the
numerals themselves, rather than to the *structure* consisting of the
objects and the operations over them.  Number theory doesn't do that, but in
ordinary language, I think people do.  I think it is a matter of confusing
the form with the function.  And, as software scientists, we do things to
promote that mis-attribution (and then are puzzled why people get upset
about radix-2 floating-point representation problems for values like 1/5).

I am not arguing, here, whether floor(x) as a real function is ill-defined,
though I think there is a case for that when x is a whole number but not "an
integer."  I do claim that these over-sized floats are *not* integers in the
sense that they do not honor the standard laws of arithmetic for integers in
the available floating-point arithmetic system.  (To say they do so
approximately is a concession, in my view, that we are talking about floats,
not integers.  Notice that, to be precise, I do not speak of floats as reals
at all.  If they were reals, we wouldn't be having this conversation.)

Am I making myself understood?  I am not looking for agreement, just whether
or not my perspective is understandable.

-- Dennis

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Tim Peters
Sent: Tuesday, May 15, 2001 22:08
To: python-list at python.org
Subject: RE: floor() function definition



> The Python real-number versions of these functions are very
> interesting for a way they can fail.  When x is too large in magnitude
> to be an exact integer, the result is an approximation in precisely
> the same way.
[I notice here that I was sucked into using the term "real-number" by the
language of the original question.  I will be more careful. -- orcmid:]

Every machine float of sufficiently large magnitude, with the sole exception
of +-infinity, *is* an exact integer.  Think about it:  every representable
finite non-zero float is of the form

    M * B**E

for some exact integers M, B and E, where B is usually fixed at 2, and if
there are P bits of precision then B**(P-1) <= abs(M) < B**P.  But every
number of that form is obviously an exact integer whenever E >= 0:  there is
no "fraction part" then, therefore it's an integer.  So floor() and
ceiling()
return "large" floats unchanged, because they're exact integers already.

[ ... ]

> ...
> Just the same, my inclination would be to raise an exception once
> floor(x) and ceil(x) can't be delivered as precise integers.

Python already does, but since there's no such case it's hard to notice the
absence of exceptions due to them <wink>.


--
http://mail.python.org/mailman/listinfo/python-list