[std-interval] New draft available (aka "Revision 1.5")

[Guillaume Melquiond]

Le vendredi 13 octobre 2006 à 11:50 -0700, Ron Avitzur a écrit :
> Hello,
> 
> Pages 5,8:
> Where it mentions integral and decimal floating point types, 
> set<interval> and valarray<interval>, consider also mentioning 
> complex intervals. Though it is outside the scope of this proposal, 
> complex<interval<double>> might be arguably useful. It happens to 
> compile without error the last time I checked, though the standard 
> does not require std::complex to work with user-defined types. Is 
> this a future direction? Is the implementation too difficult? Are 
> there  existing implementations of complex intervals? Is the problem 
> too poorly understood for standardization? If 
> complex<interval<double>> happens to compile and generate apparently 
> useful code in an implementation, is there any reason to warn a naive 
> user against it?

This can be seen as a future direction, as nothing in the current draft
prevents somebody to write its own proposal on complex intervals; and
once people are used to interval of real numbers, it might be natural to
extend them to interval on complex numbers. The implementation is not
necessarily difficult and some libraries already exist. There is no
specific reason to warn, except the fact that it is not portable due to
the way complex operations are defined in C++.

> Page 6:
> Could you elaborate on why wrap-around intervals are specifically 
> disallowed? Could that be left as an implementation choice and QOI 
> issue? Though it would necessarily complicate implementations a great 
> deal, would allowing it require any changes to the standard aside 
> from the definitions of inf and sup in 26.6.11?

They are not "specifically" disallowed. Some of their properties may be
incompatible with the model described in the draft, but nothing more.

Note that the rationale only explains the choices the authors made when
writing the proposal; what an implementation is allowed or forbidden to
do is strictly described by the proposal part. And our proposal doesn't
go to great lengths to prevent an implementation to have wrap-around
interval, generalized intervals, cset intervals, or whatever. So, to a
certain extent, they can be implemented in a standard-compliant library;
it just means that they won't be portable.

> Pages 13,28:
> Should atanh and atan2 also be overloaded to indicate if the function 
> is undefined or discontinuous across its argument?

For atanh, this is just an oversight. For atan2, I don't know if people
would consider this function useful.

> Page 19:
> Should "any value" be "every value" in describing bool_set 
> comparisons which return true and false? (The wording of the set 
> description used for the Certainly comparisons are clearer and 
> unambiguous.)

This is mainly a matter of I not being a native English speaker. I will
change it to "every" as it seems less ambiguous indeed.

> Page 25:
> Is a domain restriction needed on the definition of atanh?

Right. As other functions have such restrictions, this function should
too.

> Page 35:
> Links in references [2], [12], and [14] are 404.

Thanks for your comments.

Best regards,

Guillaume