Path: utzoo!utgpu!water!watmath!clyde!rutgers!princeton!udel!rochester!cornell!uw-beaver!mit-eddie!ll-xn!ames!ucbcad!ucbvax!hplabs!hpda!athertn!ericb
From: ericb@athertn.Atherton.COM (Eric Black)
Newsgroups: comp.lang.c
Subject: Re: Power proposal for ANSI C -- we already have what we need
Summary: Promotion above and beyond the call of necessity
Message-ID: <158@teak.athertn.Atherton.COM>
Date: 12 Jan 88 03:45:26 GMT
References: <38384@sun.uucp> <3812@hoptoad.uucp>
Reply-To: ericb@teak.UUCP (Eric Black)
Organization: Atherton Technology, Sunnyvale, CA
Lines: 49

In article <3812@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>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);
>[...]
>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.
>[...]
>Does *anybody* have a problem with this???

Seems to work as far as it goes...
Your solution still requires the arguments to first be promoted to double,
and the return result converted from double to whatever.  I have done
graphics and number crunching where that conversion both ways is
not desired (float precision is adequate) and it takes an unacceptable
performance hit.

In fact, on some systems (e.g. PR1ME/PRIMOS) a common practice is to
use a kludgey compiler "private keyword" to tell the compiler it's
making an inter-language call (in PRIMOS C it's the modifier "fortran",
of all things!) to avoid this promotion to double, and write the called
routine in FORTRAN *just so it doesn't expect its incoming arguments to
be double*, even though they are declared as float (because C requires
them to be promoted to double on the way in, you see...).

Now, in the first instance above, it is clear that the arguments MUST
be converted to double.  In the second (the builtin), I suppose the
compiler could somehow be told (a #pragma?) not to do that, but
that's really wierd and unexpected behavior.

I suppose that means I really don't have a problem with your proposed
solution, John, because this is a built-in (!) problem with C as it is,
and your solution really doesn't address my problem any less than C
does now.

Is there a provision I haven't seen that solves my problem?  If so, then
"Never mind!".  If not, I'd much prefer that it be added than any
built-in power operator.
-- 
Eric Black	"Garbage in, Gospel out"
   UUCP:	{sun!sunncal,hpda}!athertn!ericb
   Domainist:	ericb@Atherton.COM