Xref: utzoo comp.unix.ultrix:5156 comp.sys.sgi:6590 comp.sys.mips:1141
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!caen!umich!sharkey!amara!jcm
From: jcm@amara.UUCP (John Martin)
Newsgroups: comp.unix.ultrix,comp.sys.sgi,comp.sys.mips
Subject: Actually it's printf.. (was Re: Another C compiler bug)
Summary: problem is with "printf" in library
Keywords: binary search, printf
Message-ID: <5017@amara.UUCP>
Date: 1 Nov 90 20:10:12 GMT
References: <11565@sybase.sybase.com> <1990Nov1.153433.4006@cimage.com>
Sender: news@adi.COM
Reply-To: jcm@squid.UUCP (John Martin)
Followup-To: comp.unix.ultrix
Organization: Applied Dynamics, Ann Arbor
Lines: 69

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