Re: int2interval, frac2interval, rat2interval

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2012-04-20 16:15:20 +0100, N.M. Maclaren wrote:
> On Apr 20 2012, Vincent Lefevre wrote:
> >>> > >Note: in practice, the type can provide infinities, but they should
> >>> >be seen as other values, because infinities cannot be produced in a
> >>> >correct integer expression.
> >>> > Er, why not?  It is as easy to specify and produce integral
> >>infinities
> >>> as rational / real / floating-point ones.  Not all languages use ISO
> >>> C's aberrant numeric type model.
> >>
> >>I agree, but I meant that infinities are not part of math integers
> >>(with an exact arithmetic). For instance, 1/0 as an expression on
> >>integers is undefined. For floating-point arithmetic, there is the
> >>concept of limit, but not in integer arithmetic.
> 
> Er, no.  Firstly, in mathematics, 1/0 is undefined in the integers,
> reals, rationals and complex numbers.  It can be added to any of them,
> but only at the cost of breaking some of their important properties.

It can be added, but AFAIK, there are well-known no conventions
about it (contrary to Rbar).

> Furthermore, the concept of a limit exists for integers, too, and so
> does the completion of the ring Z with two infinities.

Yes, but this concept is useless to make things like 1/0 defined.

> As far as computational integers and floating-point goes, either or
> both can have signed zeroes, and the problems are almost identical.

Signed zeroes are a bad idea for integers (even for floating-point,
it wasn't a very good idea). And almost all implementations do not
support signed zeroes for integers (actually I don't know any
integer implementation with signed zeroes, and really seen as
signed at Level 2). P1788 must ignore them.

> >>I think that infinities may be useful in integer types, but only in
> >>order to signal overflows. However overflows would mean that the value
> >>is inexact, while the context here is that i is an exact integer.
> >
> >Anyway, even if one would want to accept infinities seen as exact
> >values, int2interval(+oo) and int2interval(-oo) would be similar
> >to nums2interval(+oo,+oo) and int2interval(-oo,-oo), thus NaI,
> >as suggested above. So, I don't see any problem with the spec on
> >possible infinities.
> 
> Fine.  But EXACTLY the same applies to any of the other variants,
> such as real / floating-point.

There are no such variants: num2interval() on floating-point or
any number type as specified by Motion 33 is not part of P1788.

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