Re: New approach to annex D of the 754-R proposal.

[Peter Henderson <petercbh@xxxxxxxxxxx>]

Jean-Michel Muller wrote:
> Dear colleagues,
>
> Please find below a rogue comment suggesting a new approach to annex
> D of the 754-R proposal.
Looks good.  Below please find a few comments and corrections plus one
addition.

In addition to the behaviour you describe below, I would like to
propose the following:

If f(x1, .. xN) diverges, but does not tend to +infinity or -infinity,
as (x1, ... xN) tends to (X1,...,XN), then f(X1,...,XN) should return
an infinity.  Here by diverge, I mean for all M, |f(x1,...,xN)| > M
for all (x1,...,xN) sufficiently close to (X1,...,XN).  The choice of
sign should follow the same principles used to choose the sign when
the limit is 0.

The type of behaviour this rule is designed to cover is that of
1/(x-1) as x tends to 1, or 1/(x*sin(1/x)) as x tends to 0.

This rule is not just an attempt to assign a value for every possible
case, it has real benefits.  Using this rule means that 1/f(x) will be
continuous at the point of divergence and that the benefits of
infinity arithmetic will still be available.  Of course, certain
properties will be lost, however, the fact that infinity is returned
means this situation is an exceptional case and can be checked for if
this is important.  Checking for this is not much more difficult than
checking for NaN, which the only sensible alternative.  In fact, for a
function that diverges in both directions as it approaches some point,
using the properties that are lost requires extreme care, even in the
absence of this rule, since the sign function is discontinuous at the
point of divergence.

As an example where this rule applies consider tanPi(x) at x = +/-1/2.
Users have a strong expectation that atanPi(-infinity)=-1/2 and
atanPi(+infinity)=+1/2.  They also have a strong expectation that
tanPi(atanPi(x)) = x for x in [-infinity,+infinity] and
atanPi(tanPi(x))=x for x in [-1/2, +1/2].  Hence, tanPi[-1/2] should
equal -infinity and tan[+1/2] should equal +infinity and the standard
should require this.  This also implies cosPi(-1/2) = -0 and
cosPi(+1/2)=+0.  Similar expectations and requirements imply that
cotPi(1) =-infinity and hence sinPi(1)=+0.  The symmetry of these
functions means cotPi(-1)=+infinity and sinPi(-1)=-0.  Whatever sign
is chosen for the remaining points where these functions diverge
should preserve the odd/even properties of the functions and their
relation to sinPi and cosPi.
.
.
.
> Operations shall signal division by zero as per 8.3, overflow as
> per 8.4 and underflow as per 8.5. They shall signal invalid as
> per 8.2 when the input is invalid, as defined below.
Looking at draft 1.3.0 (Feb. 23, 2007) , these should all be Section 9.x.
> For an n-ary mathematical function f and floating-point numbers
> X1,...,Xn, if f(X1,...,Xn) is defined as some real value y, then the
.
.
.
> When some of the Xi's are +0 or -0, this limit shall be considered
> using only positive
> (resp. negative) values of the corresponding xi's. In this case, if
> the limit does not exist but limits exist for other signs of 0 and are
> equal, the non-existing limit should also be considered as existing
> and equal.
What does "the limit does not exist for other signs of 0" encompass.
Do you intend it to cover functions behaving something like:
  f(x) = x for x > 0;  = sin(1/x) for x < 0?
i.e. the function is defined for x<0, but no limit exists as x tends
to zero from below.  From a purest point of view, f(+0) = +0 and f(-0)
= NaN.  However I suspect most people would find this behaviour too
harsh, and so following your principle, f(-0)=+0.

Alternatively, does this refer to the case where f(x) is not defined
for x<0 or x<=0?  In which case do you intend that for the case
f(0)=0, f(-0) and f(+0) should have the same sign?

Or does it encompass both cases?
.
.
.
> If the value to be returned by the operation is 0, the following rules
> shall apply for the sign of this 0. Let sgn be the mathematical
> function defined as follows:
>
>         /
>         |  1         if x > 0
> sgn(x) = | -1         if x < 0
>         | 0          if x = 0
>         \
>
> Consider the limit of sgn(f(x1,...,xn)) as (x1,...,xn) goes to
> (X1,...,Xn). When some of the Xi's are +0 or -0, the limit of
> sgn(f(x1,...,xn)) shall be considered using only positive (resp.
> negative) values of the corresponding xi's.
>
> Let S be the limit set (the set of the cluster points) of
> sgn(f(x1,...,xn)) when (x1,...,xn) goes to (X1,...,Xn).
.
.
.
> * If S = { 1, -1 } or S = { 1, -1, 0 }: the operation associated with f
>   should return -0 if the prevailing rounding mode is
> roundTowardNegative,
>   and +0 otherwise.
> * If S = { 0 }: the operation associated with f should return +0.
In both these cases I feel the "should" should be to preserve sign
symmetries (not just the even/odd, but perhaps symmetries such as
f(1/x) = -f(1/x)), other sign relations and relations with other
functions.  The rule you propose should come after this.  However I
have doubts whether the standard should require anything in this case.
The reason is that any enforced choice is likely to make f(x)=0 a
special case requiring special handling.  What I am getting at here is
that implementations of the function might themselves automatically
produce a sign of zero and if this differs from the prescribed sign, a
test would have to be used to determine if the particular argument has
occurred and then the sign of zero adjusted.  What is likely to happen
under such circumstances is that many implementations will preserve
sign symmetries and relations as a matter of course.
> * If S is empty: the operation associated with f should return 0
>   with a sign obtained using the rules for the sign of zero without
>   taking into account the sign of the Xi's that are equal to zero.
I am not clear as to what situation this is describing.  It seems to
be describing the case where the function is not defined in some
region close to the limit point.  But in this case, the limit is
already defined using points in the domain of the function.
.
.
.
> D.4 Informative list of mathematical functions
>
>   In the following Z = {...,-3,-2,-1,0,1,2,3,...}
>   The definition domains are given in affinely extended real numbers.
.
.
.
> - tanPi x     ]-infty,infty[ \ { 1/2 + k, k in Z}
This should be defined for ]-infinity, +infinity[,  with the values
at 1/2+k  defined as described above.  Similarly for cotPi.
.
.
.
> - atan2(x,y)
>   [-infty,infty] * [-infty,infty] \ {(0,0), (0,infty),
> (+/-infty,+/-infty)}
>
>    returns the angle in radians in [0, 2*Pi[ such that a line segment
>    forming this angle with the x axis passes through (x,y)
As David Hough commented, the range should be [-Pi,+Pi], with the sign
of zero used to choose between -Pi and +Pi.  Also, your definition
differs from the usual definition of atan(x,y)=atan(x/y), for x>0 and
y> 0, which is the angle w.r.t the x axis of the line passing through
(y,x).  Finally, useful values can be assigned to the cases
(+/-0,+/-0), etc, so the domain should be
[-infty,+infty]*[-infty,+infty].
.
.
.
>               /  principal n-th root of x  if n >= 1 and if the root
> exists
> - root(x,n) = |  1/root(x,-n)              if n <= -1
>               \  undefined                 otherwise
>
>   [0,infty] * (Z \ {0})  U  [-intfy,0[ * (Z \ 2Z)
Why is n=0 excluded.  x^0=1 for all x in [-infty, +infty] is the
behaviout everyone expects and follows all the principles you lay out
above.
> [Comment: the second argument n of root is an integer. The operation
> associated with this function might consider its second argument as
> a language-defined integer.
> ]
It is just a personal preference, but it seems less complicated to
restrict this function to [0,infty]*Z.
>                            /
>                            | algebraicPower(x,y) if y is an integer
> - conventionalPow(x,y) =   |
>                            | analyticPower(x,y) if y is not an integer
>                            \
>
>   ]-infty,0[*Z   U   [0,infty] * [-infty,infty] \ {(1,+/-infty)}
>
>
> [Comment: this function is there because many existing programs rely
> on the existence of such an operation.  New programs are expected to
> use the better analyticPower and algebraicPower. conventionalPow is
> NOT compatible with the C99 pow on 1^infty, NaN^0, 1^NaN.  It is not
> expected that many programs rely on these C99 properties.  The
> function may also be considered as purely Language defined and
> therefore might be withdrawn from the list.
> ]
My preference is not to define it.  It has no real mathematical
motivation, and where it is defined, the behaviour is highly language
dependent.

Regards,
Peter Henderson