[std-interval] Suggestions for the 2006-09 draft

[Gabriel Dos Reis]

Guillaume Melquiond <guillaume.melquiond at ens-lyon.fr> writes:

[...]

| > 2) Page 5 second paragraph: The goal of not requiring language changes
| > is fine.  However, consistent with principles 3) and 4), above, do not
| > preclude an intrinsic compiler implementation.
| 
| It seems you want us to remove the interval class, so that intrinsic
| types can be used instead.

I read the suggestion differently.

Takes the std::complex data type for example.  Its standard
specification does not preclude intrinsic compiler support.  Indeed, I
implemented the GNU libstdc++ std::complex based on the compiler
intrinsinc support for __complex__ T.

This is possible because the actual internal definition is left
implementation-defined.  I certainly do hope that the final
specification of the class template interval should not require the
private members as shown on page 13, but instead leave it
implemented-defined.   The whole class should be semantically complete
without referring to internal<>::data.

[...]

| > 5) Page 7 - [a;b] notation:  Why not let this be a localization
| > option, as is the use of , or . for a decimal point?  This is
| > consistent with principle 5), above.  For example, in countries that
| > use a comma for a decimal place, they should be free to adopt the
| > semicolon delimiter.  Doing so will not conflict with the use of the
| > comma for an interval delimiter by other countries.  Thus, [2.3, 4.5]
| > can be unambiguously localized to [2,3; 4,5], or [2,3: 4,5].  This
| > need not be specified in the proposed standard.
| 
| Quite the contrary in fact. If we let the notation be a localization
| option, the proposal would have to specify a lot more than it currently
| does.

So?  If you want to get the specification in the standard, be prepared
to specify more than the proposal currently does :-)
[ this is just a reality report from the, not a "treatening"
remark. Quite very few proposals get in without elaborations not
anticipated by the authors. ]

This issue should not be taken lightly.  One mistake we made in C++98
was to hardcode the external form of std::complex<T>.  I don't think
that kind of mistake should be repeated.  There should be a way
(manipulator?) to key the parsing on locales.  Don't underestimate
that aspect.

[...]

| > 7) Page 7 - Should std::set<interval> work?:  By this, I presume is
| > meant that sets or lists of intervals could be defined and used.  The
| > issue raised, if I understand it, is that because intervals are not
| > naturally unambiguously ordered, this cannot be done.  On the
| > contrary, when lists (sets) of interval and/or interval vectors (or
| > boxes) are used, as they often are ordered using some scalar function
| > of them, such as width, relative error upper bound, or the upper bound
| > on an objective function in an optimization algorithm.  So, as long as
| > set ordering can be performed a result of computing a scalar function
| > of the elements of the set, there should be no reason why this
| > possibility should not be supported.
| 
| I think you have missed the actual issue this paragraph refers to. In
| the C++ standard library, std::set<T> means std::set< T, std::less<T> >
| and std::less<T> is defined as a functional class for operator<(T,T). As
| a consequence, in order for std::set<interval> to work out of the box,
| we either have to specify a specialization for std::less<interval> or to
| specify an operator<(interval,interval) with a strict weak ordering.
| None of these two specifications are desirable.

Why?

You can say std::less<T*> in general even if you cannot operator< tow
pointers in general.

The issue of std::set<T>, where T is a floating point value is one
that keeps poping up.  In particular, that of
std::set<std::complex<T>> is very annyoing.  To solve this issue, it has 
been suggested several times (the first time I hear of it was from
Andy Koenig at the Santa Cruz meeting, October 2002) to introduce a
"canonical ordering" defined in terms of the value representation so
that even if it does not make sense to use operator< on complex<T>, it
should make sense to say std::set<complex<T>> as people expect.  I
don't think it would be appropriate or convincing for the interval
proposal to ignore the issue or handwave.

| > 8) Page 8 - Memory layout.  This issue vanishes if interval data types
| > are opaque.
| 
| As detailed in the paragraph, there is an active defect report related
| to std::complex being opaque and without any memory layout.

As the author of that issue, I suspect I have to weight in.

"Opacity" and "predictable layout" are not exactly conflicting here --
neither in the std::complex case, as amended by my proposal.  As I
said earlier, I implemented std::complex<T> with GCC's __complex__,
yet I guarantee that the resulting type has the same layout as that of
array of two elements.  What you need is invariants and external
semantics specification.  You can (and should) leave the rest as
"opaque". 

-- Gaby