754R vs pow

[David Hough 754R work <754r@xxxxxxxxxxx>]

All the arguments back and forth reaffirmed my belief that 754R should not
attempt to standardize "pow."     The following functions might be
profitably standardized now:

pown(x,n) x**n for integer n
compound(x,n) (1+x)**n for integer n
rootn(x,n) x**(1/n) for positive integer n

===

and maybe:

explog(x,y) exp(y * log(x)) 
        with intermediate divbyzero, underflow, overflow suppressed
        but with these invalid cases suggested by the formula:
        x < 0,  (0,0), (inf,0), (1,inf) 

===

with the following left as exercises for future generations:

zpow(u,v) for complex u and v
and
rpow(x,y) which matches Re(zpow(complex(x),complex(y)))
        whenever Im(zpow(complex(x),complex(y))) is identically zero

Depending on how zpow is defined, rpow might or might not differ from explog.
Languages having complex types might want to bind their "pow" differently
from languages that don't, for all I know.

===

Unlike x*y or hypot(x,y) or even atan2(x,y),  pow(x,y) is not in any sense
symmetric in x and y; usually one is the continuous 
independent variable and the other is a parameter, fixed but perhaps unknown.
754R has more immediate issues to deal with than sorting that out.

Having n be a non-continuous integer parameter of pown, compound, and rootn
perhaps makes it easier to accept that the function values are 1 when n is 0
for any x whatever, and avoids the issues of infinite n.