HELP: restore my faith in Python

[Tim Peters]

[Ken Seehof]
> Seems to me an improvement would be to have python artificially
> add epsilon to floats before converting to int.  This would still
> suck but IMHO it would suck less.

In my arrogant option, it's a terrible idea.  You're welcome <wink>.

> Yeah, I know it's artificial, but it's not rocket science.  Everyone
> knows that int(0.99999999999999999999993427) == 1 is more
> correct than int(0.99999999999999999999993427) == 0.

Does everyone also know that

    int(0.9999999999999999999993427) == 1

is more useful?  How about

    int(0.999999999999999999993427) == 1
    int(0.99999999999999999993427) == 1
    int(0.9999999999999999993427) == 1
    int(0.999999999999999993427) == 1

and so on?  So long as you draw the line *somewhere*, you haven't solved
anything, you've merely moved the surprises from where they're predictable
across *all* IEEE-754 platforms to something unique to Python.

The problems with floating-point are deep and can't be patched over.  "Quick
hacks" always backfire.  If somebody wants to indulge in a notion of "safe
epsilon", there's nothing to stop them from writing that explicitly.

> I challenge anyone to come up with a real world situation where the
> latter answer is more valuable.

For starters, any situation whatsoever in which exact integers happen to be
manipulated in floating-point format.  It would be surprising as hell for,
e.g.,

    top = 2.**52 - 1.0
    bot = top + 1.0
    int(top/bot)

to come out as 1.  Not just surprising, but plain wrong.  Many programs do
this, btw:  Python's floats have 53 bits of precision on most machines, but
Python's ints only 31.

> I'll let the experts figure out what exactly epsilon should be.

There is no suitable value, an no expert will touch this even on a
double-dog dare <wink>.

[on integer division]
> I suggest the Alice approach: find out what "non-programmers"
> expect the behaviour to be, commit to that, then do the best you
> can to formalize the rules so "real programmers" can figure out
> what to expect too.

The ABC project did that and came up with rationals.  Ditto the TeachScheme!
project.  In ABC rationals didn't work out that well in practice, but I
suspect it's because the language's floating-point facilities were clunky.
Haven't heard similar complaints about MzScheme.

> Unfortunately, I have a feeling that most "real programmers",
> including myself, will probably be somewhat annoyed at the results.
> After all, we think integer division is sometimes useful.

It would be reasonable to introduce, e.g., "//" as an integer division
operator.

> ...

leaving-case-sensitivity-to-the-sensitive<wink>-ly y'rs  - tim