[Trent Mick]
> I apologize if I am hitting covered ground. What about a module (called
> limits or something like that) that would expose some appropriate
> #define's
> in limits.h and float.h.
I personally have little use for these.
> For example:
>
> limits.FLT_EPSILON could expose the C DBL_EPSILON
> limits.FLT_MAX could expose the C DBL_MAX
Hmm -- all evidence suggests that your "O" and "A" keys work fine, so where
did the absurdly abbreviated FLT come from <wink>?
> limits.INT_MAX could expose the C LONG_MAX (although that particulay name
> would cause confusion with the actual C INT_MAX)
That one is available as sys.maxint.
> - Does this kind of thing already exist somewhere? Maybe in NumPy.
Dunno. I compute the floating-point limits when needed with Python code,
and observing what the hardware actually does is a heck of a lot more
trustworthy than platform C header files (and especially when
cross-compiling).
> - If we ever (perhaps in Py3K) turn the basic types into classes
> then these could turn into constant attributes of those classes, i.e.:
> f = 3.14159
> f.EPSILON = <as set by C's DBL_EPSILON>
That sounds better.
> - I thought of these values being useful when I thought of comparing
> two floats for equality. Doing a straight comparison of floats is
> dangerous/wrong
This is a myth whose only claim to veracity is the frequency and intensity
with which it's mechanically repeated <0.6 wink>. It's no more dangerous
than adding two floats: you're potentially screwed if you don't know what
you're doing in either case, but you're in no trouble at all if you do.
> but is it not okay to consider two floats reasonably equal iff:
> -EPSILON < float2 - float1 < EPSILON
Knuth (Vol 2) gives a reasonable defn of approximate float equality. Yours
is measuring absolute error, which is almost never reasonable; relative
error is the measure of interest, but then 0.0 is an especially irksome
comparand.
> ...
> I suppose the answer to my question is: "It depends on the situation."
Yes.
> Could this algorithm for float comparison be a better default than the
> status quo?
No.
> I know that Mark H. and others have suggested that Python should maybe
> not provide a float comparsion operator at all to beginners.
There's a good case to be made for not exposing *anything* about fp to
beginners, but comparisons aren't especially surprising. This usually gets
suggested when a newbie is surprised that e.g. 1./49*49 != 1. Telling them
they *are* equal is simply a lie, and they'll pay for that false comfort
twice over a little bit later down the fp road. For example, int(1./49*49)
is 0 on IEEE-754 platforms, which is awfully surprising for an expression
that "equals" 1(!). The next suggestion is then to fudge int() too, and so
on and so on. It's like the arcade Whack-A-Mole game: each mole you knock
into its hole pops up two more where you weren't looking. Before you know
it, not even a bona fide expert can guess what code will actually do
anymore.
the-754-committee-probably-did-the-best-job-of-fixing-binary-fp-
that-can-be-done-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4