This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: glibc conditioning
- To: Jinsong Zhao <zhaojs at cadence dot com>, Ulrich Drepper <drepper at cygnus dot com>
- Subject: Re: glibc conditioning
- From: Mark Brown <bmark at us dot ibm dot com>
- Date: Tue, 28 Aug 2001 09:04:05 -0500
- CC: <libc-alpha at sources dot redhat dot com>, <stevew at srware dot com>
Jinsong Zhao wrote on 8/27/01 5:52 PM:
> double d=0.3;
> int i = (int)(1000*d);
>
> Only on Linux i is 299, while on all other machines (Solaris, AIX,
> HPUX, FreeBSD) i is 300. I guess this is just one of the demonstrated
> behavior that says Linux is different from everyone else on floating
> point operations.
This is, not to put too fine a point on it, poor coding practice. If
you came to IBM with a similar claim against AIX, you would be having
this same conversation with me....
> There is no point in arguing with me what is the strictly right answer
> according to some standard. The point is, as an OS/library user, I
> want to have consistent results.
To get consistent results, one should use the library properly.
I see others have already pointed you to the fine paper
"What every computer scientist should know about floating-point arithmetic"
by David Goldberg.
> Our software are heavily numerical in nature. I understand that
> writing codes that compare doubles or do casting is like playing with
> fire.
That is the truth!
> Unfortunately, we have to live with the history and the
> legacy. For me, for now I have to stop working on porting to Linux and
> regret that I cannot enjoy the speed of Intel computers. The floating
> point problems are showing in the thousands of lines codes written by
> others.
Then you should be cursing those "others", not the GNU C volunteers :-/
> So, please, if you consider people like me as one of your customers
> who want to bring the EDA tools (a $3 billion annual business) onto
> Linux
One must question the usefulness of tools with floating point code
such as the above. Can we trust them?
--
Mark S. Brown bmark@us.ibm.com
Senior Technical Staff Member 512.838.3926 T/L678.3926
IBM Corporation, Austin, Texas Mark Brown/Austin/IBM