Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!think!mit-eddie!genrad!decvax!decwrl!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.lang.c
Subject: Re: fabs(x) vs. (x) < 0 ? -(x) : (x)
Message-ID: <12908@sun.uucp>
Date: Sun, 8-Feb-87 18:52:21 EST
Article-I.D.: sun.12908
Posted: Sun Feb  8 18:52:21 1987
Date-Received: Tue, 10-Feb-87 04:04:16 EST
References: <4943@mimsy.UUCP> <2550005@hpisod2.HP> <756@unc.unc.UUCP> <2181@batcomputer.tn.cornell.edu> <1315@ho95e.ATT.COM>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Distribution: na
Organization: Sun Microsystems, Mountain View
Lines: 28

>	#define	fabs(x) ( (x) & 0x7FFF )
>
>is probably a *lot* faster than your assembly language function,

On my machine, at least, it's incredibly fast, taking no time at all.
This is because using "fabs" on a floating-point value causes the
compiler to reject the code, so you don't waste cycles actually
running the program.

Sorry, but the only way you'd get something like this to work would be to
cast a pointer to the appropriate piece of the floating-point number
to a pointer to some integral type, and dereference that pointer to get
at the appropriate bits and to stuff the result back there.
According to the October 1, 1986 ANSI C draft:

	3.3.10 Bitwise AND Operator

	...

	Constraints

	   Each of the operands shall have integral type.

>Yeah, a lot of it's not exciting.  The standard complaint is that everything
>is really done in double precision, when you can often get by with single.

Fixed in ANSI C, which does not oblige you to perform floating-point
computations in double precision.