🚀 go-pugleaf

mambuhl@ripco.com (Martin Ambuhl) wrote:

>amish@data.uchicago.edu (Amish Dave)
>in <DLtLuF.KEC@midway.uchicago.edu> asks:

>>On a P133 running Linux1.2.13 with gcc-2.7.0, I get strange behavior with
>>the code below.  Sparc2-SunOS-gcc2.6.3 and Alpha-DecUNIX2.3c-gcc2.7.0
>>behave correctly with the same code.

[...]

>When you evaluate 0.7 * 70 or 0.7 * (20+50), you are depending on the
>level and type of optimization the compiler uses.  A "smart"
>implementation may decide that it knows the result to be 49,

He compiled without optimization, so no "smartness" should be involved.

>but a
>strong argument can be made that the correct result should be 48.  0.7
>decimal is not expressible as n / pow(2.,k) where n and k are integers.
>So it will be a repeating fraction.  In octal, this is
>0.5 4631 4631 4631 ... Suppose a mantissa of 30 bits (10 octal digits).
>If the implementation uses 0.5 4631 4631 4, then 0.7 *70 is 48; while
>with 0.5 4631 4631 5, 0.7 *70 is 49.

>[To make it easier, note that
>    0.54 * 106 (octal) = 60.10 (octal) = 48.125 (decimal)
>    0.55 * 106 (octal) = 61.16 (octal) = 49.21875  (decimal)]


>>#include <stdio.h>
>>main()
>>{
>>        int a = 20, b = 50, c;

>>        c = (int)(0.7 * (a + b));
>>        printf("c = %d\n", c);

>>        c = (int)(0.7 * 70);
>>        printf("c = %d\n", c);
>>}

>>When compiled without any options (gcc -o foo foo.c), on the Pentium, it
>>prints out
>>c = 48
>>c = 49

>>The correct output should be:
>     ^^^^^^^
>     wrong.  Correct outputs include 48 and 49.
>>c = 49
>>c = 49

I think that the output should be the same for both lines, either 48 or
49, but not mixing it up. (see below)

>>On Sparc-SunOS-2.6.3 or Alpha-DUnix3.2c-2.7.0 machines, it works correctly.
>>I can get it to function correctly on the Pentium with -msoft-float, but...
>                          ^^^^^^^^^
>                          wrong.
>>What's going on?

>You haven't learned your early lessons in floating point arithmetic and
>how to protect yourself from unexpected but correct results.

It's more than just putting it on a shelf of floating point roundoffs.
The problem is not the internal representation of the (dec.) float 0.7,
it should be the same in both lines. The difference is in the
representation of the second operand. One would exspect in both cases an
interger represntation of 70, which is casted to a float or double.

I had some similar experience even with function calls and posted to
this newsgroup (float != float ...) which described Problems with floats
and function returns under DJGPP (gcc for DOS, i386).

>                                            
>--
>* Martin Ambuhl       net: mambuhl@ripco.com
>* Chicago, IL (USA)    

===
Axel Thimm <axl@zedat.fu-berlin.de>
Freie Universitaet Berlin
===