[std-interval] Revised document available

[Guillaume Melquiond]

Le lundi 18 septembre 2006 à 22:48 +0100, Dr John Pryce a écrit :
> Dear std-intervalers,

> B.
> I do not feel the text makes it clear whether the 
> platform's arithmetic MUST support oo - which 
> more or less amounts to using IEEE arithmetic.

Unless I'm mistaken, infinities are mandated by LIA-1 (Language
Independent Arithmetic 1) and this is an ISO international standard,
contrarily to what IEEE-754 is (and IEC-559 is international but not
ISO). So just because we are speaking about infinities does not mean we
are speaking about IEEE infinities.

> On p4 we read
>    The value of whole() requires that T has an infinity
>    (in std::numeric_limits<T>).
> and the definition of "whole()" has
>    Requires: std::numeric_limits<T>::has_infinity.

I recently came to this same conclusion: the definition of whole is
badly worded, it doesn't have to introduce the notion of explicit
infinities in the base type. Note that the "requires" was really meant
in the standardese sense: a precondition on calling the function.

> Actually one can easily (at the cost of some 
> performance penalty) encode "whole" and other 
> infinite intervals on an arithmetic without oo, 
> using reverse-ordered bounds, as recent postings to this group have hinted.

Yes. And this precisely means you can write a conforming and non-trivial
implementation on a platform that does not support infinities in the
base type.

> C.
> More on ambiguous support for oo. The definition 
> of an interval<T> object 26.6#3 uses the phrase 
> "is specified by two values of type T ...". Implications of this wording are:

No, I think you are putting too much meaning in the wording of 26.6#3.
This paragraph refers to the values returned by the lower and upper
methods and is fine in itself. This makes me notice, however, that the
definition of these methods is a bit poor: they should have an
implementation-defined behavior when the bounds are not finite as inf
and sup have.

> (a) If T does not support oo then infinite intervals are forbidden: one is
>    not permitted to encode them by some other method.
> 
> (b) A midpoint-radius (m-r) representation is forbidden: not explicitly, but
>    de facto. I don't think m-r is a good system on the real line (recall Rump's
>    INTLAB uses it in the complex plane) but I use it as a test. I don't think
>    a standard should rule out m-r, and believe one that does so is too
>    implementation-oriented.
> 
> The reason m-r is excluded is that it defines an interval by two type T numbers
>    m, r such that the exact mathematical interval is [m-r, m+r]. In general
>    these endpoints are not exact type T numbers, 
> but the text says they must be.

Looking at the proposal, the only part that forbids the midpoint-radius
representation is the interval(T,T) constructor. Is this what you are
referring too? Should we weaken its postcondition?

> (c) Implementations that support non-closed intervals are explicitly forbidden.
>    This is indirectly related to handling oo, and 
> I will return to it in a later
>    message.
> 
>    Actually George pointed out this is not 
> entirely true. By playing around with
>    the class hierarchy one can add other kinds of interval to those this
>    standard restricts one to. But it would be nice to permit them explicitly.

What do you mean "explicitly"? Do you want to add an interval(T, T,
bool, bool) constructor that sets the opened/closed status of the
bounds? Or do you just want 26.6#3 to be reworded? Which wording do you
suggest?

[...]

> BTW some people feel that the IEEE designers 
> "didn't really intend" Inf to be infinity, but 
> just to mean some finite number too large to 
> represent. But then, why is it that IEEE defines 
> Inf times 0 to be NaN rather than 0?

Because 0 was intended to mean some finite number too small to represent
(hence its sign) :-).

Best regards,

Guillaume