bswheeler39

On 15 Jul 2003 19:33:07 -0700, dpnich@optushome.com.au (Dylan Nicholson)

First, this appears to be c++, not c, although the concepts are
essentially the same in this case. VC6 supports C90, and not C99, so
there are several compiler errors in the above.

Second, set your compiler to conforming mode:
/Za Disable Language Extensions (check box selected) ANSI C
compatibility. Language constructs not compatible with ANSI C are
flagged as errors. Note that this also turns on the /Op (Improve Float
Consistency) flag, which is what is required here.

With /Za set, neither "huh 1" nor "huh 2" is output, and there are no
anomalies, and the behavior is conforming.

However, without /Za set, VC will default to a mode where floating-point
values remain in registers, and are not type-converted in all cases
dictated by the standard. I got both "huh 1" and "huh 2" output, which
is what I would expect, given VC's default behavior.

Relative to your first post,

it would appear that f is rounded up when converted from double to
float, more than FLT_EPSILON. Note that 5.15002 has type double.

Informally, what I see in the debugger is
5.1500201225281 = f (as double)
5.1500201192093 = d + FLT_EPSILON
5.1500200000000 = d
so the result we get is consistent with what we see here.

As another poster has suggested, you may want to look into the problems
associated with floating-point representations.

Regards,
Bruce Wheeler

dpnich

Ah yes, sorry...I meant to convert to C before posting it...
<snip>

So you can't get it to just output huh 1 but not huh 2? You may need
to do it in debug mode (in fact in release mode the floating
comparisons are optimized out, as they are fixed at compile time).
I still don't understand how it could matter which way the casting is
done (explictly inline, or implicity via storing to a float variable).
And I just don't know the x87 FPU instruction set well enough to
understand the difference in the compiled output.


Still, even in this example, it's because I'm using a mixture of
doubles and floats that the problem occurs.

Well yes I'm well aware of those problems, but I don't see how they're
relevant here. I know I was using FLT_EPSILON incorrectly, but
likewise I can't see how that should matter. In general if you assign
the *same* decimal value to two floats, they should never compare as
anything but equal, even if they aren't exactly the value I assigned
to them.

Dylan