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
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