floor() function and mathematical integers

[Tim Peters]

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

Sure, but neither do they never behave as integers.  I don't feel a need to
reduce the truth to a single line.  In 754 arithmetic, an operation on large
floats gives exactly the same result as an operation on unbounded reals would
if and only if the operation doesn't set the "inexact" flag -- there's
nothing fuzzy about it.

> In particular, the Peano axioms fail with respect to arithmetic on
> the ones that are too-much greater than 1.

Only matters if you're adding 1.

> So, it is mute that ceil(x) = -floor(-x)) still, if x+1 is not different
> than x.

Except that whether x+1>x is irrelevant if that's not the operation you're
performing.

> It is because above a certain scale factor, the floats don't correspond
> 1-to-1 to mathematical integers any longer.

*Operations* may or may not, depending on both the operation and its specific
inputs.

> (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 seem to think there's something non-trivial about this observation, but,
sorry, I don't see it.  Floating-point is what it is, and doesn't need to
apologize for not being what it never intended to be <wink>.

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

There's no confusion about floating-point that can't be cured by study.  The
repeated confusions I've seen over the decades amount to no more than that:
people making bad assumptions about, and bringing fantasy expectations to, a
system they've never bothered to learn. "Being around" floating-point for
1000 years won't make up for the lack of a deliberate effort to learn.

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

The REXX language deliberately set out to make arithmetic work "the way
people expect".  This turned out to include things like preserving the number
of trailing digits in inputs, so that (e.g.) 2.02 - .02 == 2.00, not 2; or,
even simpler, input 1.000 and get back 1.000, rather than 1. or 1.0 or
1.000000 etc.  REXX ended up with floating point arithmetic, but in base 10,
with arbitrary and user-settable precision, and huge dynamic range.  I expect
that "what people expect" *now* is shaped by experience with hand
calculators.  People are not suprised that, e.g., 1.0/3*3 returns 0.99999999
on an 8-digit hand calculator, but give them a wholly analogous example in
binary fp and they raise a stink to high heaven about "bugs" <wink>.

> 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 don't know what that means, unless you want floating-point operations to
raise exceptions whenever they have an input x such that x+1==x -- in which
case it's unrealistic.  If you want integers and only integers, don't use fp.

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

floor() does the best job it can given what it knows, which is its input.  If
I compute 2.0**500 in 754 arithmetic, I in fact get the exact answer, and
floor() of that has no business presuming "oh no, that's 'too big' to be an
exact answer -- so I'll help Tim by complaining instead".  If you're afraid
of inexact results, don't use fp at all, or use it with the inexact trap
enabled.

> (To say they do so approximately is a concession, in my view,

But a telegraphic obfuscation in mine.  The whole truth isn't so complicated
that it needs to be hidden behind partial truths.

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

Remains unclear to me:  can you define precisely what it is you think floor()
should do?  Feel free to assume 754 arithmetic.  BTW, note that Python isn't
making up its own meaning for floor(); math.floor() inherits the function of
the same name from the platform C library, and the C std mandates its
behavior.  When explaining why it returns "large" floats unchanged, I was
explaining why the C committee chose to do that.  Indeed, I don't know of any
language that defines floor() in any other way.

fighting-the-universe-is-a-low-success-hobby<wink>-ly y'rs  - tim