# [std-interval] Comments on the Interval Standard Proposal

Guillaume Melquiond guillaume.melquiond at ens-lyon.fr
Sun Oct 1 10:33:21 PDT 2006

```Le dimanche 01 octobre 2006 à 01:26 +0200, Gabriel Dos Reis a écrit :
> Sylvain Pion <Sylvain.Pion at sophia.inria.fr> writes:
>
> | Gabriel Dos Reis a écrit :
> | > | For implementations which do not support infinity, how do you check if
> | > | an interval is bounded ?  Currently we can't.
> | > support infinity, does not it follow all intervals are bounded?
> |
> | I was thinking that implementations could store extra data members
> | specifying if a bound is infinite.  You can't return it through
> | .lower(), because the floating-point type does not have a value
> | for infinity, but is_positively_bounded() can return the
> | information.
>
> Aha.  So, is it accurate to summarize the issue as to how to support
> unbounded intervals even where the implementation has bounded
> arithmetic for scalar arithmetic types?

Your summary may be a bit short. Let's detail the issue along three
axis: concept / vendor / user, as only the "user" part needs fixing in
my opinion.

1. From an interval arithmetic point of view, whether the environment
supports infinities or not is irrelevant: there is no need for a
mathematical infinity in order to define what unbounded intervals are
and how to compute with them.

2. From a library point of view, missing IEEE-754 infinities make the
code a bit more complicated and a lot slower, as you need to detect
overflows by hand. Representation doesn't even require extra data
members, as half of the data space is left unused by proper intervals,
so you can store unbounded intervals by using reversed bounds.

3. From a user point of view, missing infinities give unexpected results
for the value access functions when dealing with unbounded intervals.
This is where the proposal is weak and the is_*_bounded functions would
solve the problem.

Best regards,

Guillaume

```