Can linux be trusted?
Jens Kilian
> The "problem" may be in the way gcc decides to
> order its operations. Why should using variables
> rather than constants affect this? Why not?
Perhaps the constants get folded away, but the variables don't.
If the compiler uses a different floating-point rounding mode than the runtime,
that would explain the discrepancy. (A good optimizer should be able to
constant-fold the expression involving variables, too.)
I'm not sure if the C standard mandates a compiler to use the same floating
point rounding mode as its runtime environment.
Bye,
Jens.
--
mailto:j...@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Chronos Tachyon
On Thu, 01 Mar 2001 10:54:58 GMT, Tony Porczyk wrote:
> Chronos Tachyon <chronos...@please.no.spam.in.my.mail.com> writes:
>
> >I tried running your code, but I didn't get the problem you described.
> >The only change I made was to "#include <stdio.h>" to quiet the warning
> >about printf being undeclared.
> >user$ gcc -O2 -ansi -Wall -o temp temp.c
> >[...]
>
> Original poster said, "without optimizations".
>
> t.
Duh. You're right, of course. I tried again without -O2 (habits are hard
to break), and got "10 = 9", the opposite of what the guy was complaining
about...
--
Chronos Tachyon
Guardian of Eristic Paraphernalia
Gatekeeper of the Region of Thud
[Reply instructions: My real domain is "echo <address> | cut -d. -f6,7"]
Chas2K
>
> "John Smith" <jms...@generic.com> writes:
>
> > "
> > If you've got a minute, and one of those 'bleeding edge' OSes, try compiling
> > with no optimizations and running this for fun:
> >
> > int main(void)
> > {
> > int a = 60, b = 6, c = 10;
> >
> > printf("%d = %d\n", (int) (((60/6)*0.3) + (10*0.7)), (int) ((( a/b)*0.3) +
> > ( c*0.7)));
> >
> > exit(1);
> > }
> >
> > (BTW the lameness filter defies logic, that was the best I could do with the
> > C snippet)
> >
> > A friend was tortured for a few hours doing an assignment until I took a
> > look at the code and realized the problem boiled down to something that can
> > be reduced to this snippet.
> >
> > I compiled this with default compiler settings on every platform I could
> > find. This means Digital Unix 4.0, OpenVMS 7.2, Solaris 8, IRIX 6.4, HP-UX
> > 10.20, FreeBSD 4-STABLE, OpenBSD 2.8 and various Linux distros, from ancient
> > to cutting edge - both with gcc and any commercial compilers that happened
> > to be available at each box.
> >
> > On all Linux distros, and only on Linux distros, ranging from an ancient
> > Slackware setup to the latest Red Hat, I get 9=10. On everything else, I get
> > 10=10. Go figure, and remember that the whole OS is compiled with that.
> >
> > I think I'll just stick to FreeBSD as far as my intel boxes are concerned.
> > "
> > http://slashdot.org/comments.pl?sid=01/02/28/1712232&cid=93
>
> your problem is you don't how floating point works.
>
> --
> J o h a n K u l l s t a m
> [kull...@ne.mediaone.net]
> sysengr
This whole thread brought back something that has been buried from the
dawn of micros... I went for the TRS-80 Model I because the only other
prebuilt home box then was an Apple and it only had an integer BASIC. I
discovered the FP problems with TRS-80 BASIC early on doing some array
calcs and found out that 1.4142136 squared returned 1.9999998 instead of
2.0000001 as did almost all of the early 4 function calculators. As I
recall our group of BASIC and Z80 ASM hacks finally devised an 'add up
and round down then truncate' routine to allow for the float errors.
Chas2K.01
--
----- * --- http://www.unixstar.com -----------
- Tomorrow's leaders are in Scouting today -
- Support a free and democratic Taiwan -
-----------------------------------------------
Tim Prince
"Christian Bau" <christ...@isltd.insignia.com> wrote in message
news:christian.bau-0...@christian-mac.isltd.insignia.com...
> In article <877l27j...@neumann.gnix>, Sven Esbjerg
> <esb...@egmont-kol.dk> wrote:
>
> > k...@ashi.footprints.net (Kaz Kylheku) writes:
> >
> > > And what compiler do you suppose that FreeBSD uses? You are
incredibly
> > > naive if you think that this has anything to do with the OS. You have
> > > dropped the names of a bunch of operating systems, but failed to
> > > mention anything that is even slightly relevant: such as what version
> > > of the compiler you were using with what command line options. The
> > > processor also matters. You are aware of Intel's record regarding
> > > floating point arithmetic right? Don't expect the same program to
> > > produce the same results when run on two different members of the x86
> > > family.
> >
With different settings of precision or rounding mode? Why do these posters
say they don't trust linux, when they refuse to tell us how FreeBSD sets up
the CPU? Does it copy VC++ ? Why don't these people try the linux case
with other settings, e.g. 53-bit precision mode?
> > You are so right. What if I tell you that I have two machines with
> > identical processors (Intel PIII). One running Linux and one running
> > FreeBSD. Both us gcc-2.95.2. Linux uses libc.so.6 and FreeBSD uses
> > libc.so.4. They produce different results. The code shouldn't have to
> > rely on libc. The 10 = 9 happens on all linux machines I have testet
> > which includes 4 year old installs and new ones. I have not seen it
> > happen on any other Intel based machine.
> >
> > I know that there is a problem when type casting back and forth from
> > int to float. But... with the same compiler and on the same
> > architecture I would expect to see the same error.
>
> Instead of complaining, you should be glad to have learned that same
> compiler + same architecture doesn't guarantee same results. Look at it
> like this:
>
> 1. The C Standard doesn't guarantee results for floating point
> operations that are the same everywhere.
>
> 2. A well-written program will produce approximately the same results
> everywhere.
>
> 3. If your program gives different results like in your case where the
> only difference is the operating system, then you _know_ that your program
> is not well-written. A very valuable information. If one computer says
> nine, and the other says ten, at least you know that both results cannot
> be trusted.
Yes, one of the purposes for changing precision mode would be to check for
unexpected numerical flakiness in your program.
And, why is this message so heavily cross-posted that it can't be replied
to? What does this have to do with a mac, for example?