Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Power operator?
Summary: Use a function, but not "pow()"
Message-ID: <2195@haddock.ISC.COM>
Date: 8 Jan 88 23:44:53 GMT
References: <47000029@uxe.cso.uiuc.edu> <10063@mimsy.UUCP> <646@l.cc.purdue.edu> <10088@mimsy.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 27

In article <10088@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>What pow function?  Who said we were calling the pow function? :-)
[Implying that "pow" might be implemented as a builtin]

I have several problems with using pow() for integer powers.  Unue, I dislike
having to use floating point in otherwise "pure" integer code.  ("difftime()",
yuck.)  Due, I suspect that most vendors will not optimize the statement
"j = (int)pow((double)ifunc(), 2.0)" into what I want.  Trie, it's possible
that the cast to double throws away the lower bits of my left argument, which
would yield an incorrect result.  Kvare, it's just too verbose (and I won't
remove the casts; some compilers would emit warnings without them).

The proposals I've seen so far include:
x ** y     Already means "multiply by what y points to".
x ^ y      Already means "exclusive or".
x ^^ y     Some people want this reserved for logical (not bitwise) xor.
x ! y      Doesn't extend to an assignment form, since "!=" is taken.
x *^ y     Not bad; I could live with it.  However, ANSI is unlikely to
           introduce new operator syntax anyway.
pow(x,y)   See above paragraph.

I counterpropose "int ipow(int, int);", "long lpow(long, int);", and
"double fpow(double, int);".  These are easy to implement as either functions
or builtins, and vendors will probably be more willing to inline-expand these
functions than the full pow() function.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint