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

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2007-06-21 00:53:00 +1000, Peter Henderson wrote:
> 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).

I personally really don't like this. I assume that you would want -Inf
in roundTowardNegative and +Inf in roundTowardPositive so that interval
arithmetic can still be consistent. In particular, this would mean that
an exact result can have a value that depends on the rounding mode!!!

> The choice of sign should follow the same principles used to choose
> the sign when the limit is 0.

0 is a different case since -0 = +0.

> > 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.

Draft 1.3.0 is obsolete. The section numbers are taken from draft 1.4.0.

> > 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.

Well, the main goal was to have, e.g., log(-0) = -Inf. But I now think
that the rule above could lead to inconsistencies with multivariate
functions. Considering the cluster points could be a better idea. Now,
remember that the rule is only a "should"...

> 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?

Yes, this is a consequence of the case:

 * 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.

> 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.

This was discussed, and I understand your point of view, and this is
the reason I wanted that a "shall" be replaced into a "should" for
the case "S = { 1, -1 } or S = { 1, -1, 0 }". Note that it is *not*
possible to preserve all sign symmetries (e.g. with the periodicity).

[...]
> > * 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.

The limit is defined, but if it is zero, its sign has not been defined
yet. Remember that +0 and -0 are the same number in the extended real
numbers.

> > - 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],

Yes.

> 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).

Hmm... yes, in fact the function should be atan2(y,x), to follow the
same naming of the C standard.

> Finally, useful values can be assigned to the cases (+/-0,+/-0),
> etc, so the domain should be [-infty,+infty]*[-infty,+infty].

I don't think so. Could you elaborate?

> >               /  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.

Because it doesn't make any sense.

> x^0=1 for all x in [-infty, +infty] is the behaviout everyone
> expects and follows all the principles you lay out above.

So? How would you inverse this?

> >                            /
> >                            | 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.

FYI, this was also my personal feeling.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)