Re: motion elementary functions
> Date: Tue, 13 Oct 2009 14:14:12 +0200
> Subject: Re: motion elementary functions
> From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
>
> Juergen and P1788,
>
>
> >> 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).
> >>
> > I don't like this. The user should call rootn(-32,5)
> > 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.
>
> . . .
>
> 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
>
Folks,
I generally agree with Hossam on this matter.
We had great difficulty deciding on the correct definition
of x^y for 754. In the end, including all of pown, powr,
& pow was the compromise I LEAST desired. And I, like
Hossam as I remember, argued for pow, the most general
of the three.
Still, in our new context we have the chance to correct
this situation & once again go to a single well defined
x^y. It depends on how we act in undefined regions of a
function.
You see the problem is that when x < 0 the function x^y
is defined at only countably many discrete points. In
a floating-point domain with radix 2 or 10 there are
none for r = 2 & only finitely many for r = 10.
But while our system of discourse has a radix for its
endpoints, the sets themselves are contiguous subsets
of the reals & therefore HAVE no radix.
So we are back to a function that has countably many
answers that are dense in the Reals.
If I am not mistaken, those points can be written as
those x & y such that: x = a^d/b^d < 0, GCD(a,b) = 1,
y = c/d, & GCD(c,d) = 1. Then x^y = (a/b)^c.
Again, if I'm not mistaken, this function is even
continuous in both arguments when confined to these
points.
(With a possible sign ambiguity due to the fact that
this is really the principal valued Real projection
of a countably many infinitely valued function in the
complex numbers. I can go into details if it becomes
necessary.)
It can even be evaluated efficiently as -exp(y*log(|x|).
Thus, an interval xx^yy can be well defined everywhere
if we are willing to return answers in the case where
at least part of xx < 0. That is, we can return a
consistent & continuous interval as a result if we
are willing to do that in a sub domain in which the
function is UNdefined everywhere EXCEPT for a dense
& countable subset of points.
So it seems to me that the answer to this question
hinges on how we answer the decoration question & its
implications for the evaluation of functions at least
partially outside their domain of definition.
Well, that's my $0.02 on the subject.
Except for please, please, PLEASE, let's only have
ONE function. And make it a good one. :-)
Yours,
Dan