For pow, I prefer that we allow the full domain of RxR. For me, pow is the most general form of sqr, pown, sqrt, powr, root, rSqrt, and compound. Hence, I think that we should not prevent someone who wants to calculate (-32)^(0.2)=-2 from doing just that in a simple fashion as pow(-32,0.2).
see rationale
Your method is valid if the programmers know the values at programming time so that they can choose the function rootn instead of pow.
Furthermore, if for example the values (which become known only at run time) are -32 and 2.2 we get, according to mathematics, pow(-32,2.2) = (-32)^{2.2} = (-32)^{2} \times (-32)^{0.2} = (1024) \times (-2) = -2048.
Since the programmers have no a priori knowledge of the values they cannot break the function calls to two and do
sqr(-32) \times rootn(-32,5)
In the rationale you say that you are trying to follow 754. I know that 754 defined the pow the same way you do and I objected during the voting period on that issue for decimal FP for the same reasons given above. Other members of the 754 committee, prefered to keep things similar to the previous implementations of pow on binary FP.
The difference between binary and decimal is not trivial so let me explain for those in 1788 who might not be familiar.
Any fraction may be regarded as an integer divided by the base of the number system raised to the power of the number of digits after the point. For example in decimal 0.324=324/1000.
In binary, this leads to a denominator with powers of two and we are always computing an even root. Hence, there is no real solution for negative values of x in pow(x,y) if y is a fraction in binary FP.
On the other hand, in decimal FP the denominator is powers of ten. If the numerator has enough powers of two to eliminate those in the denominator such as 0.2=2/10=1/5 or 0.12=12/100=3/25 we still have a fraction but with only odd powers in the denominator and hence we will have odd roots. Those odd roots have real solutions for negative x in pow(x,y) with y in decimal FP.
I argued during the voting period of 754 for the inclusion of special cases for decimal in pow. As I said, other people opted for simplicity. Note that, in 754, pow and the other functions in the same clause are "suggested" to behave as described. P1788 may define them in a slightly different manner and still be compliant with 754.
I prefer that 1788 defines pow to be the most generic case of raising a number to a power and to allow all the possible mathematical cases.
Hope this explains my view better.
--
Hossam A. H. Fahmy
Assistant Professor
Electronics and Communications Department
Cairo University
Egypt