I'm forwarding a message I got about the f == 0.0 warnings.
--
Andy Dougherty [EMAIL PROTECTED]
---------- Forwarded message ----------
Date: Wed, 14 Nov 2007 10:38:10 -0500
From: Jeffrey Kegler <[EMAIL PROTECTED]>
To: Andy Dougherty <[EMAIL PROTECTED]>
Subject: Could you forward this into the perl6 internals list
Resent-Date: Wed, 14 Nov 2007 10:38:35 -0500
Resent-From: <[EMAIL PROTECTED]>
I've been following the floating point issue for some time, but am
not on the perl6 internals list, and didn't want to join to make a
single comment. Could I ask you to forward this into the list?
Bottom line: the floating point equality warning is the expression of
a philosophy of math issue, and you may not be following the
philosophy. That's cool. But it's not viable IMHO to not adhere to
the philosophy, but try to keep the warning.
The philosophy of math issue is that if you are taking floats as
approximations of reals, equality does not usually mean anything
useful. It almost never means what the programmer is trying to
express via equality. Floating point zero (0.00) means zero plus or
minus an error, just as with any other floating point number. Zero
is not special in any sense. Are all your "special case" floating
zeroes safe from being mistaken for certain very small but non-zero
numbers in all implementations?
However, we are hackers, not philosophers of mathematics (actually
I'm both, but I'm talking now as a hacker). Floats on computers are
what we hackers use them for, and if we find it useful to special
case the bit pattern corresponding to zero, we can do it. We should,
however, turn off the warning.
I hesitated to come in, because I'm not aware of the context. You
may, for example, be trying to mix code that carefully adheres to the
floating-point-equals-Platonic-idea-of-real-numbers philosophy, with
code written on a it-works-so-what's-the-beef philosophy, in which
case I can see why the problem keeps coming up.
Primary suggestion: You might consider simply turning off the
warning in preference to heroic efforts to shut it up for cases which
are actually no safer than any others.
Other suggestions: If code rewrites are feasible, an additional
boolean is not (certainly in the context of C code) all that
expensive these days, and is a philosophically "right" answer. A
more hackerly solution is to identify a range which won't be the
result of normal computation and test for that. (If the value can
never be less than zero let (f < 0.00) be the special case.
Sorry to interrupt your work, but I've followed your list and seen
this come up several times and I hoped this might help,
thanks for your work,
jeffrey kegler
> > On Mon, Nov 12, 2007 at 12:33:41PM -0800, Andy Dougherty wrote:
> >
> > > It may well be there's an issue with gcc's optimizer, since the
> problem
> > > goes away without optimization, but I think it's also fair to
> say that
> > > the definition of FLOAT_IS_ZERO in include/parrot/misc.h is
> > > perhaps not optimal here. I'd prefer the simpler definition:
> > >
> > > #define FLOAT_IS_ZER0(f) ((f) == 0.0)
> > >
> > > but I didn't get anywhere last time I proposed that. I don't know
> > > what else to do.
> >
> > I suggested
> >
> > f >= 0.0 && f <= 0.0
> >
> > which I believe is identical, even in the face of NaNs, but
> should also shut
> > up the whining, er, warning, about comparison.
>
> You're probably right. However, given that gcc currently throws over a
> thousand warnings it's hard to get worried about about another one
> or two.
>
> > Because I would be so bold as to say that the constant zero would be
> > exempted from any useful warning about floating point equality
> check.
>
> Yes, it's amazing how gcc seems to have hundreds of flags that are
> almost,
> but not quite, entirely unlike the ones you actually want.
>
> --
> Andy Dougherty [EMAIL PROTECTED]
>
