[std-interval] Comments on the Interval Standard Proposal
Sylvain.Pion at sophia.inria.fr
Sun Oct 1 00:32:43 PDT 2006
Guillaume Melquiond a écrit :
>> 26.6.4 interval member functions
>> 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:
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
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
>> 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.
More information about the Std-interval