Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.lang.c
Subject: Re: Power proposal for ANSI C -- we already have what we need
Message-ID: <3812@hoptoad.uucp>
Date: 10 Jan 88 10:42:11 GMT
References: <38384@sun.uucp>
Organization: Nebula Consultants in San Francisco
Lines: 60

I guess most people who are talking about problems with pow()
can't think like a (draft proposed) ANSI C compiler.

Suppose you have a dumb math library.  In <math.h> you put a declaration like:

	double pow(double, double);

and write the library routine, and you are done.  Now users can call
this routine with integers, floats, doubles, whatever, and it works,
because the function includes a prototype.  E.g.

	zap = pow(x, 2);

works, as does

	zap = pow(x, 2.0);
	oot = pow(x, 0.5);  etc...

Now suppose that you have a smart compiler and math library.  In
<math.h> you do:

	#define	pow	_compiler_pow

where _compiler_pow is recognized as a keyword by the compiler.  This
is a two-argument function built into the compiler -- it *knows* the
types of the operands, etc, just like any other built in primitive function,
like addition or multiplication or sizeof.  So if the user codes:

	zap = pow(x, 2);

it can easily see to multiply x by itself.  If you code

	zap = pow(x, 2.0);

it can *also* see to multiply x by itself (if your float representation
can't hold exact values of small integers, you are already in trouble).
If you code:

	oot = pow(x, .5);

then it can generate a square root instruction (ditto representation of .5).

And if you code

	whoknows = pow(x, y)

then it generates a subroutine call to the dumb library routine.

Does *anybody* have a problem with this???  I think it would be crazy
to change the standard for something like this.  Adding new multi-character
arithmetic operators to the language at the final stage of review?
Be serious.  We laughed at ( ), we roared at noalias, who would believe 
us if we overloaded ** to mean a crippled float/int-only exponentiation?
we already have one crippled math op (% doesn't work on floats, for no reason),
why add another?
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
  I forsee a day when there are two kinds of C compilers: standard ones and 
  useful ones ... just like Pascal and Fortran.  Are we making progress yet?
	-- ASC:GUTHERY%slb-test.csnet