[std-interval] Comments on the Interval Standard Proposal

Sylvain Pion Sylvain.Pion at sophia.inria.fr
Sun Oct 1 00:32:43 PDT 2006


Guillaume Melquiond a écrit :
>> 26.6.4 interval member functions
>>
>>    whole();
>>
>>       I do not see a definition of the static member function whole().
>>       I am particularly interested in what whole().lower() et.al. means.
> 
> There is a definition in the proposal saying that "whole" returns [-inf,
> +inf]. Anyway, there was some discussions on the list and now "whole" is
> only defined as returning an interval containing all the real numbers.
> There is no difference with the older definition for a 754-based
> efficient implementation, but the function can now be defined on an
> arithmetic without infinities.
> 
> Concerning the "lower" and "upper" members, I have fixed their
> definitions along the lines of the "inf" and "sup" functions, so that
> they return the corresponding infinities for unbounded intervals. When
> infinities are not available, the behavior is implementation-defined.

For implementations which do not support infinity, how do you check if
an interval is bounded ?  Currently we can't.
What about adding functions like:
   is_positively_bounded(interval<T>), and
   is_negatively_bounded?
Or something like that.

Even for cases where infinities are supported, they can be more
convenient than testing like:
   x.upper() == numeric_limits<double>::infinity()

>>    interval(const char *s);
>>
>>       I think undefined behavior here is a very bad idea.  The programmer
>>       cannot effectively avoid the bad behavior without parsing the string
>>       manually.  That is too much of a burden.  I suggest that the parse
>>       either return empty (which is indistinguishable from a successfully
>>       parsed empty) or return an error code, or throw an exception.  You
>>       should ask the library experts for their prefered solution.
> 
> On the contrary, I think undefined behavior is a good idea :). The point
> of this constructor is to define interval constants in the program, e.g.
> ``interval<float> Pi("[3.1415926,3.1415927]");''. With an undefined
> behavior, we may hope that compilers will warn when they detect a syntax
> error, as they already do with printf format strings.
> 
> The constructor was not meant to be used to convert user inputs. The STL
> I/O stream machinery should be used instead as it will correctly detect
> any mistyped input and report it to the program. Am I missing something?

The use case you mention is supposed to be handled by initializer_lists
at some point anyway (I guess).  So in the end, we might differentiate
between the case of a constant string, available to the compiler, and
the case of a "run-time" string, which might come from elsewhere (not
necessarily I/O).

For now, I would tend to follow Lawrence's list of potential solutions.
They do not prevent study of compile-time constant strings by the
compiler anyway.

>>    interval(T t);
>>
>>       What does "if the value of t is infinite, it will be interpreted as a finite
>>       number to [sic] big to be representable when constructing the
>>       interval" mean?  How does this statement affect my program?
> 
> This is a good question, and I'm not sure I have a good answer. The
> point of this definition is to provide an interval that still respects
> the inclusion property when an infinity is interpreted an overflow. From
> an implementation point of view, it means that interval(+Inf) constructs
> the interval [+Max,+Inf].

I think [+Max,+Inf] is a wrong choice.
I see only 2 reasonnable choices: error or whole.

Either we error out on this (using an exception or an error code),
as intervals only contain real (finite) numbers and infinity is not
such a number, hence not representable in an interval.

Or we consider that we try to fix up some code that did overflow,
but then, given than +Inf-C is also +Inf (for C any finite number),
then it means that we should also fix up this case after the fact,
thus +Max-C should also be in the interval, hence the only reasonable
interval is whole.

I don't have any strong preference between these two, but maybe
returning whole is safe enough.

-- 
Sylvain


More information about the Std-interval mailing list