jcm@amara.UUCP (John Martin) (11/02/90)
In article <1990Nov1.153433.4006@cimage.com> brian@dgsi.UUCP (Brian Kelley) writes: >In article <11565@sybase.sybase.com> mcfong@mercury.sybase.com () writes: >>[...] >>Looks like yet another compiler bug which MIPS has fixed but DEC and >>SGI have not yet picked up. >>[...] >I think the main problem is ULTRIX 4.0 is using version 2.00 of the MIPS >C compiler. No, actually I suspect that the real culprit is "printf" not rounding properly (though I confess I haven't checked the binary form for the 7e-7 floating-point value to completely absolve the compiler). To test my hypothesis, here's a little binary search program that determines the value below which all floating-point values will be printf'ed as "0.000000": --------------------------------------------------- #define TRACE(x) /*#define TRACE(x) printf("mid = [e]%e: [f]%f\n", x, x)*/ #define STREQ(a,b) (strcmp(a,b) == 0) char zstr[] = "0.000000"; /* watch for all zeroes */ int main() { float lo=0.0, hi=1.0, mid; char buf[10]; for (;;) { mid = 0.5 * (hi+lo); TRACE(mid); if (mid == hi || mid == lo) break; sprintf(buf, "%f", mid); if (STREQ(buf, zstr)) lo = mid; else hi = mid; } printf("hi = %e\n", hi); printf("lo = %e\n", lo); return (0); } --------------------------------------------------- On my DECstation 3100 running Ultrix 4.0, this produces the output: mips ---- hi = 9.500000e-07 lo = 9.500000e-07 I also tried it on different, admittedly non-mips, systems: 68k sun sparc vax/vms ------- ----- ------- hi = 5.000001e-07 hi = 5.000001e-07 hi = 5.000001e-07 lo = 5.000000e-07 lo = 5.000000e-07 lo = 5.000000e-07 As you can see, the "printf" in Ultrix 4.0 simply seems to be choosing the wrong place to round up. I really doubt that the mips compiler could be goofing when initializing 'lo' to 0.0, 'hi' to 1.0, or the 0.5 constant in the 'mid' calculation, or that the fundamental floating point calculations are seriously perturbed. It looks like an output formatting problem to me. -- John Martin, Applied Dynamics International, Ann Arbor, MI, (313)973-1300 jcm@adi.com || jcm%amara.uucp@mailgw.cc.umich.edu || ...uunet!sharkey!amara!jcm "How many times over the past six months did you, or people working for you, write some program fragment for table searching?" -- Bertrand Meyer
thomson@cs.utah.edu (Rich Thomson) (11/02/90)
In article <5017@amara.UUCP> jcm@squid.UUCP (John Martin) writes: |No, actually I suspect that the real culprit is "printf" not rounding |properly [...] To test my hypothesis, here's a program that determines |the value below which all floating-point values will be printf'ed as |"0.000000": [program deleted] |On my DECstation 3100 running Ultrix 4.0, this produces the output: |I also tried it on different, admittedly non-mips, systems: |DECstation 3100 68k sun sparc vax/vms |(Ultrix 4.0) |hi = 9.500000e-07 hi = 5.000001e-07 hi = 5.000001e-07 hi = 5.000001e-07 |lo = 9.500000e-07 lo = 5.000000e-07 lo = 5.000000e-07 lo = 5.000000e-07 On an ESV (MIPS R3000, ES/os 1.3, MIPS cc 2.1) I obtained the same numbers as the 68k, sparc and vax/vms. I suspect it is the libraries in Ultrix as well. -- Rich Rich Thomson thomson@cs.utah.edu {bellcore,hplabs,uunet}!utah-cs!thomson ``If everybody is thinking the same thing, is anybody thinking?'' --Bob Johnson
meissner@osf.org (Michael Meissner) (11/03/90)
In article <5017@amara.UUCP> jcm@amara.UUCP (John Martin) writes: | No, actually I suspect that the real culprit is "printf" not rounding | properly (though I confess I haven't checked the binary form for the | 7e-7 floating-point value to completely absolve the compiler). I did do the checking, and the compiler is certainly passing the right bits. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
heller@cs.umass.edu (From the screen of Deneva...) (11/12/90)
In article <5017@amara.UUCP>, jcm@amara.UUCP (John Martin) writes... >In article <1990Nov1.153433.4006@cimage.com> brian@dgsi.UUCP (Brian Kelley) writes: >>In article <11565@sybase.sybase.com> mcfong@mercury.sybase.com () writes: >>>[...] >>>Looks like yet another compiler bug which MIPS has fixed but DEC and >>>SGI have not yet picked up. >>>[...] >>I think the main problem is ULTRIX 4.0 is using version 2.00 of the MIPS >>C compiler. > >No, actually I suspect that the real culprit is "printf" not rounding >properly (though I confess I haven't checked the binary form for the >7e-7 floating-point value to completely absolve the compiler). Or you count try forcing printf to use more precision, using something like %10.8f and seeing if 7e-7 still prints as 0.0000000. Robert Heller ARPANet: Heller@CS.UMass.EDU BITNET: Heller@UMass.BITNET BIX: locks.hill.bbs GEnie: RHeller FidoNet: 1:321/153 (Locks Hill BBS, Wendell, MA) CompuServe 71450,3432 Local PV VAXen: COINS::HELLER UCC Cyber/DG: Heller@CS
osm@ox.com (Owen Scott Medd) (11/13/90)
In many articles people complain about rounding errors with the Ultrix C
compiler...
> [ ad nauseum... ]
The problem is rounding up when there is a zero in the last displayed
digit. That is:
printf("%6.2f\n", .006) prints 0.00,
while printf("%6.2f\n", .016) prints 0.02
The internal representation is correct, just printf/*cvt are screwed up.
This is a *documented* bug in the Ultrix 4.0 (cc2.0) C compiler (right
there in the release notes) and an undocumented bug in the cc1.31
compiler. The Atlanta CSC *assures* me that it's fixed in the 4.1 cc,
though they have not followed through on their request (of a week ago!)
of getting me a rush copy of 4.1.
Sigh.