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

[Guillaume Melquiond]

Le jeudi 21 septembre 2006 à 03:04 +0200, Gabriel Dos Reis a écrit :
> 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.

William Walster's sentence "Surely, a proposed language standard should
not be written in such a way that it can *only* be implemented in a
class library." was quite clear to me at that time. Especially as having
__interval__ T inside the interval class would not be helpful in
performing "symbolic expression manipulation and derivative/slope
derivation, and width/performance optimizations". But if you are saying
that I misunderstood and that there is no disagreement between William
and I on using a class interface, then that is great.

> 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.

This idea was inspired from Howard Hinnant's N1589. Now I see that DR387
currently suggests to have this kind of sentence instead: "If z is an
lvalue expression of type cv std::interval<T> then the expression
reinterpret_cast<cv T(&)[2]>(z) is well-formed". As the point of writing
the "data" member was precisely to express this reinterpretability, this
kind of sentence too is fine with me.

> | > 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.

> 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.

Yes, I may have been underestimating this issue as there is no DR for
this mistake for std::complex (is there?). Moreover, I am not really
confortable with C++ localization mechanism. Do you have any idea of
what is needed for a localized version of intervals? In particular,
should we add members to the numeric category or should we specify a new
category for intervals or is there another way? What would have been
done for std::complex if something had been done?

> | 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.

> 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.

Could you detail a bit more what was suggested at this meeting? That the
definition of std::less<T> be changed so that it becomes a canonical
ordering irrespective of the definition of operator<(T,T)? That a new
class be specified to express a total ordering? Whatever consensus was
reached at that time, we can adjust the proposal to it. The more details
you can provide, the stronger the rationale will be. Thanks.

> | > 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.

Just to be sure I understand correctly what you are saying. What you
call "external semantics specification" is the ability to reinterpret an
array of n std::interval<T> objects into an array of 2*n Ts, similarly
to what is written in the defect report for std::complex, right? Or is
there more to it, or less?

Best regards,

Guillaume