floor() function, mathematics, and computer arithmetics

[Dennis E. Hamilton]

Thanks for this discussion.  This has been very useful in clarifying a
number of things for me around computer arithmetics, and even more about the
different ways people approach numeric problems with computers.

I want the best of both worlds:  Speed and compactness (i.e., 32-bit ints
and floating-point doubles) and precision, accuracy, and fidelity (bignums,
rationals, decimal "truth," etc.).  And a way for people to be able to tell
which they are using and how to manage the trade-offs.

Most of all, I am concerned that, like it or not, we are presenting
illusions to people.  I would like a way to have people be on guard about
that without getting too much in their way.  It may be that we simply need
to be more rigorous in our speaking or in how we indicate that there are
exceptions to common understanding of the simple descriptions that we use.
I find there to be something to be responsible for here, and I am going to
keep looking for ways to equip people to be aware of the pitfalls and to be
able to detect and deal with the surprises that are lurking in the bits.

	-	-	-	-	-

I think the discussion of floor() is a great example, and maybe it is a
matter of being clear that python math is about a floating-point
implementation.

But, "Essential Python" says floor(x) Returns the floor of x.

So, this is either completely circular and non-useful or it appeals to some
a priori definition of floor.  One responder took that position and postured
about *mathematical* knowledge.  Yet, as I think you and I can agree, the
math.floor(x) is a special function defined in terms of floating-point
arithmetics, not the mathematical floor function from reals to integers.
Someone else invited induction from examples (a very risky thing to do,
since it suggests that there is a simple mathematical principle involved,
and the exception of floating-point floor is not likely to be discovered
that way).

Now, Harbison and Steele, who have much experience in this area, overstate
the definition of floor() and suggest that the result (in the C library) is
a mathematical integer.  Easy mistake to make.  I've done the same.  I'm
going to have to be much more watchful of how I speak of computer
arithmetic.

Finally, the Standard C Library definition of floor is very subtle.  It is
designed for a skilled audience and someone using it to learn about the
Standard C Library can easily miss the subtlety.

The first edition of Programming Python simply refers readers to C sources
for the math module.

Teach Yourself Python says that the Python floor() is *not* the C Language
floor(), apparently based on an experience with a non-conforming
implementation of the C Library!

It isn't math.floor() so much. (Why did they call it math? Is math to
mathematics as int is to integer?)  I just knew what floor() was and was
startled by the responses the original simple question aroused (before it
became flat-out belligerence).  This particular awoke my concern for how we
teach this stuff.  I am concerned that the artifact, like it or not, is the
teacher, and I am wondering what it is teaching well.

	-	-	-	-	-	-	-	-

Thank you for taking the time for this.

-- Dennis

-----Original Message-----
From: python-list-admin at python.org
[mailto:python-list-admin at python.org]On Behalf Of Tim Peters
Sent: Friday, May 18, 2001 04:02
To: Python-list
Subject: RE: floor() function and mathematical integers



> ...
> If I had my druthers, I would have there be a domain-error exception for
> floor(x) when x is outside the range for which consecutive integers are
> exactly representable.  That is, I wouldn't deliver results outside the

754 double arithmetic has 53 bits of precision.  This make 2.**53 the
smallest positive x for which x+1 == x, so you want floor(2.**53) to
complain, and because "x isn't an integer then" (in this imposed sense).

What about floor(2.**53-1)?  Since we've established that 2.**53 "isn't an
integer", then 2.**53-1 can't be either, since 2.**53-1+1 == the non-integer
2.**53.

Then what about floor(2.**53-2)?  Same thing:  if 2.**53-1 isn't an integer,
then neither is one less than it.  Etc.  [ ... ]

If math.floor() were defined to map floats to ints, I'd have a lot more
symapthy with your view.  But it's defined to map floats to floats, and what
it does makes the best sense *for* floats.

<orcnote>
I agree.  Delivering a bignum from floor would be more consistent and I
agree that would be a different function than math.floor().
</orcnote>

[ ... ]

> ...
> By the way, I am not proposing any changes to Python.  I am not concerned
> about that.

It would help clarify if you were:  so long as it's just philosophical
musing, you won't need to face the difficult issues of selling specific
concrete behavior to real people.  And in the absence of that hard work, I'm
afraid that talk about "serving users" rings hollow.

<orcnote>
I didn't say I wasn't willing to do something about it.  I just don't feel
it is necessary to lobby for "fixing" a language that isn't broken when it
doesn't do something the way I would want it done.

I am very interested in understanding the situation in how it relates to
CP4E, fostering software-engineering success, and having computer-science be
more useful.

I have an opportunity to experiment with this challenge with some
toy-language work I do, and I am willing to develop it further there.
</orcnote>

[ ... ]

> ...
> I think the rub for me is that floor() is a number-theoretic function,
> in contrast with sqrt() or cos() where approximations are understood
> differently (and cos(2.0**500) is still problematic).

Ah.  Perhaps you're just confusing math.floor() with the function of the
same
name from number theory.  I'm not pulling your leg there!  math.floor() maps
floats to floats deliberately, and it's actually a useful function *as
defined* in floating-point work.  It's not trying to be a number-theoretic
function (whatever that means exactly <wink>).

<orcnote>
Well, yes.  More than that, I am concerned that the name and definition are
appropriated and this suggests more harmony than there is.  I don't know if
something so simple as calling it float.floor() would have helped or not.
</orcnote>

> ...
> I think when I want to offer implementations of mathematical objects,
> I will stick to the pure stuff (bignums and rationals), and when
> offering popular implementations (i.e., IEEE floats and 32-bit ints),
> I will keep them  distinct.  I can see the desirability of both.  I don't
> think one approach alone will serve the needs of all users.  And users
> deserve to know more clearly when they are relying on arithmetic schemes
> in which a large number of compromises have been made and there are
> boundary cases to be careful about.  I don't think that we do a very
> good of of letting people know when things are not as simple as we
> encourage them to believe through our omissions.

This is a very optimistic view, Dennis.  Most users won't read a word of the
information you're keen to provide them until *after* they suffer bad
problems, and the more options and explanations you offer the more confused
users will become.  Unlike you, they're not *interested* in the abstractions
or the details.  This is just a fact of life -- why should they be?  That's
where the REXX approach shines, in catering to people who've never really
thought about it and never intend to.  But if you're more interested in
catering to knowledgable and involved users, they don't need nearly the
amount of help you're preparing to give them (just like you didn't need any
help to understand Python's math.floor()).

<orcnote>
Something I need to pay careful attention to.  Agreed.

I would like to find a path that allows people the opportunity to move from
disinterested to knowledgeable at *their* pleasure, and have avenues to
discovery that don't get in their way when that is not what is needed.

If we only learn from mistakes, then I want to look for the predictable
mistakes and arrange that there is access to useful lessons there.
</orcnote>

you-can't-help-those-who-won't-help-themselves-ly y'rs  - tim
<orcnote> Agreed.  That lesson is beyond the scope of programming-language
design. </orcnote>




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