Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-unix!teknowledge-vaxc!uw-beaver!uw-june!entropy!dataio!bright
From: bright@dataio.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and Floating Point
Message-ID: <1283@dataio.Data-IO.COM>
Date: Thu, 2-Apr-87 14:00:12 EST
Article-I.D.: dataio.1283
Posted: Thu Apr  2 14:00:12 1987
Date-Received: Sat, 4-Apr-87 16:05:48 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA>
Reply-To: bright@dataio.UUCP (Walter Bright)
Organization: Data I/O - FutureNet Corp., Redmond, WA
Lines: 76
Keywords: C Fortran Floating Point

In article <5716@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <15958@sun.uucp> dgh@sun.uucp (David Hough) writes:
>It is BECAUSE I care about good floating-point algorithms that I even
>bothered to suggest that floating-point == was not a good idea.
>
>I am still waiting for a really good reason for using floating-point
>== in any robust algorithm.  I have posted the only one that anyone
>has yet come up with (== 0.0 special case switch) and have also posted
>an example of the problems its general use can cause.  I have many years
>of experience in programming significant numerical applications in both
>Fortran and C, and I am convinced that floating == is virtually NEVER
>a good thing to write in one's code.

I use == for doubles and floats frequently:
	o in my test suites for my C compiler (Datalight C). This
	  is because I know EXACTLY what bit pattern
	  I want and want to make sure that all the library routines work
	  exactly.

	o to detect +infinity and -infinity, as the 8087 handles it
	  differently than the software floating point does.

	o in routines that attempt to determine the characteristics
	  of the floating point code (like Cody and Waite's machine
	  arithmetic program).

	o to detect special values supported by the 8087 in hardware
	  (such as pi).

I suspect that == is also useful:
	o in specially tweaked numerical programs. As Cody and Waite point
	  out, for many purposes you cannot write numerical routines that
	  are both portable and accurate to the limits of the machine.
	  Take a look at the code to implement sin() for an example.

And now for something completely different:

	How about allowing numbers to be specified in binary radix,
	as in 0b00110101 ? No existing code would be broken, and it
	would be very useful to those of us writing graphics code,
	code to fiddle with bits in i/o ports, etc. It seems odd that
	decimal, octal, hex, floating and ascii formats are supported,
	but not binary in a language supposedly designed for bit twiddling!
	As a corollary, support %b in printf and scanf.

	Also, support specifying floating numbers in hex radix. This
	would avoid horrible kludges like:

		unsigned value[4] = {0x1234,0x5678,0xabcd,0x4532};
		double d;

		if (d < *(double *)value)
			...

	The syntax would be:

		double def = 0x1324.5E678e+0x12;
		double abc = -0x.1B4F;

	def prescribes a mantissa of 0x12345E678 and an exponent of
	(4*16+0x12).

	Note that a + or - would be required before the exponent, to
	distinguish the e from the digit e. Also note that octal is
	a little difficult to parse, as lots of people use leading 0s
	already.

	Such syntax would be very useful to those of us writing numerical
	subroutines. Numerical analysis books frequently give the
	constants to use specified in hex or octal, so as to control
	the resulting values exactly. Note also that the constants
	for def and abc are more portably defined than value is, as
	value depends on byte order, exponent bias, where the sign bit
	is, etc. They are also less error prone to type in, as they
	can be compared directly with the book values instead of going
	through a manual translation process.