[std-interval] Re: Std-interval Digest, Vol 8, Issue 14

[Ray Moore]

I should probably stay out of this discussion, because it involves technical 
details about compilers of which I am ignorant. However, there is one thing 
that troubles me just a bit. Perhaps it is trivial.
It is the sentence
    "One would be hard put to argue that any order
    relation between an interval and an empty interval can be said to be 
'true'."
On the contrary, the empty set can be regarded as a subset of any set, 
because it is true that any element of the empty set is also an element of a 
given set, because there are no elements of the empty set. Thus it can be 
said to be true that an ermpty interval is contained in any given interval.

Ray Moore


----- Original Message ----- 
From: <std-interval-request at compgeom.poly.edu>
To: <std-interval at compgeom.poly.edu>
Sent: Thursday, September 21, 2006 2:08 AM
Subject: Std-interval Digest, Vol 8, Issue 14


> Send Std-interval mailing list submissions to
> std-interval at compgeom.poly.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://compgeom.poly.edu/mailman/listinfo/std-interval
> or, via email, send a message with subject or body 'help' to
> std-interval-request at compgeom.poly.edu
>
> You can reach the person managing the list at
> std-interval-owner at compgeom.poly.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Std-interval digest..."
>
>
> Today's Topics:
>
>   1. Suggestions for the 2006-09 draft (G. William Walster)
>   2. Re: Suggestions for the 2006-09 draft (Guillaume Melquiond)
>   3. Re: Suggestions for the 2006-09 draft (Gabriel Dos Reis)
>   4. Re: Suggestions for the 2006-09 draft (Guillaume Melquiond)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 20 Sep 2006 14:18:30 -0700
> From: "G. William Walster" <Bill.Walster at sun.com>
> Subject: [std-interval] Suggestions for the 2006-09 draft
> To: std-interval at compgeom.poly.edu
> Message-ID: <4511B026.3000702 at sun.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> The 2006-09 (revision 1) draft is much better than earlier versions.  See: 
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2067.pdf>  The 
> authors have done a lot of work and should be commended for it.  Sections 
> II through IV are the only ones on which I am competent to comment.  They 
> are clear and well written.
>
> Mike Schulte was kind enough to make some valuable suggestions, 
> nevertheless, I am happy to take full responsibility for any lapses in 
> what follows.
>
> There are still some areas where further improvements can, and in my 
> opinion, should be made.  They follow from four fundamental principles 
> that I believe any interval language standard must not violate:
>
> 1) Containment.  That is, the set of all possible values resulting from 
> the evaluation of any expression over given interval arguments *must* be 
> contained in computed interval results.  This implies, of course, that the 
> set of possible values, the "containment set", or cset, must be defined. 
> As John Pryce and George Corliss point out, there are different ways to 
> define mathematically consistent csets.  Generally, smaller csets are more 
> complicated to define and implement.  Which is chosen can (and should) be 
> a quality of implementation (QOI) choice, as first defined in: 
> <http://docs.sun.com/app/docs/doc/819-3695>.
>
> 2) Opaqueness.  The only possible reason I can think of is for specifying 
> how interval values are internally represented in a given compiler or 
> class library is to provide binary file compatibility.  Source code 
> compatibility from release to release and implementation to implementation 
> can be guaranteed with opaque data types.  The huge advantage of 
> opaqueness is that different platforms can choose to do what makes sense 
> for them *and* different implementers can choose to use different internal 
> representation schemes, depending, for example on the chosen cset system. 
> For example, on systems that do not support infinities or NaNs, one could 
> internally define [+1, -1] to be the representation for empty and [+2, -2] 
> to be the whole real line.  Opaque data types would also not preclude a 
> given implementation from supporting exterior intervals and/or various 
> tags.
>
> 3) Intrinsic Compiler Support.  A proposed language standard should not 
> preclude interval data types from being made intrinsic in a compiler. 
> Many run-time performance and interval width optimizations can best be 
> performed at the abstract syntax tree level within a compiler.  Surely, a 
> proposed language standard should not be written in such a way that it can 
> *only* be implemented in a class library.  Two examples of the kind of 
> optimizations that can best be performed inside a compiler are: symbolic 
> expression manipulation and derivative/slope derivation, and 
> width/performance optimizations such as the implementation of "crude range 
> tests".  See: Walster and Hansen, Using pillow functions to efficiently 
> compute crude range tests, "Numerical Algorithms" V37: 401-415, 2004.
>
> 4) Support Narrow Width.  A proposed interval language standard should not 
> preclude doing *anything* to gain speed and reduce computed interval 
> width.  The *only* constraint should be cset satisfaction.  As 
> developments continue to be made defining narrower width cset systems, and 
> as better algorithms become available for automating the ability to use 
> dependence information, the language standard should not prohibit them 
> from being implemented.  There should be no narrow width requirement, just 
> as there are not speed requirements.  Returning "whole" should be a 
> standard-conforming option.
>
> 5) Ease Of Use.  To the extent possible, syntax and features should be 
> included in an interval language standard that make it easy for algorithm 
> developer *and* end users.  An example of the latter is support for 
> single-number interval input and output.  See:
> G. W. Walster (1988) "Philosophy and practicalities of interval 
> arithmetic" in "Reliability in computing: the role of interval methods in 
> scientific computing", R. E. Moore (ed), Pages: 309 - 323 
> ISBN:0-12-505630-3
> and
> M. J. Schulte et al "Single-Number Interval I/O," Developments in Reliable 
> Computing (T. Csendes ed.) pp.
> 141-148, Kluwer Academic Publishers, 1999.  An electronic version is 
> available at: <http://citeseer.ist.psu.edu/schulte97singlenumber.html>
>
> Keeping the above five principles in mind, here are some specific 
> illustrative example in the current draft that appear to be violations of 
> them:
>
> 1) Last 4 lines on page 4:  Not all operations on an empty interval 
> produce an empty result.  The hull operator is the one exception. This is 
> a good reason why un-initialized intervals should be set to the whole 
> interval.  They will propagate (except through the intersection operator 
> with a finite interval) and be noticed quickly when debugging.  They 
> cannot result in a containment failure.
>
> 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.
>
> 3) Page 5 - lower(): With opaquely defined interval data types, there is 
> no need for this function.  Indeed, it should not be included.  There is 
> no need for it.
>
> 4) Page 6 - Empty Interval: Relative to the discussion of implementations 
> on platforms that do not support NaNs, opaqueness solves the difficulty.
>
> 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.
>
> 6) Page 7 - order relations on empty intervals and - Why do "certainly" 
> comparisons return "true" for empty intervals?: There are good reasons why 
> *all* relations tests on empty intervals should return false.  First, it 
> is the conservative thing to do.  One would be hard put to argue that any 
> order
> relation between an interval and an empty interval can be said to be 
> "true".  Second, if code for a sequence of relational tests is written so 
> it is logically exhaustive, then the final else branch can *only* be taken 
> if there is an unanticipated empty interval in one or more relational 
> tests.  This mechanism provides a convenient way to catch unanticipated 
> empty intervals. In the following Fortran example .CLT. and .PGE. are the 
> certainly less-than and possibly greater-than-or-equal relational 
> operators, respectively.
>
> IF(A .CLT. B) THEN
>
>     ! Code for A .CLT. B
>
> ELSE IF(A .PGE. B) THEN
>
>     ! Code for A .PGE. B
>
> ELSE
>
>     ! Either A, or B, or both A and B is empty.
>
> END IF
>
> A compiler might even check for violation of this principle and provide a 
> warning diagnostic if exhaustive sequences of relational tests are not 
> used.
>
> 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.
>
> 8) Page 8 - Memory layout.  This issue vanishes if interval data types are 
> opaque.
>
> 9) Page 8 - Optimization expectations: An interval language 
> standardization goal can be to make library implementations *close* to 
> compilers.  However, nothing should be in the standard that precludes an 
> intrinsic compiler implementation.
>
> The following typo was noticed by Mike Schulte:
>
> Page 3 - The specification states "Those optimizations, however, are 
> necessary for implementing the proposal." I believe this should be "Those 
> optimizations, however, are *not* necessary for implementing the 
> proposal."
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Sep 2006 02:03:44 +0200
> From: Guillaume Melquiond <guillaume.melquiond at ens-lyon.fr>
> Subject: Re: [std-interval] Suggestions for the 2006-09 draft
> To: Bill.Walster at sun.com,<std-interval at compgeom.poly.edu>
> Message-ID: <1158797024.6204.108.camel at saline>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Le mercredi 20 septembre 2006 à 14:18 -0700, G. William Walster a
> écrit :
>
>> Keeping the above five principles in mind, here are some specific
>> illustrative example in the current draft that appear to be violations
>> of them:
>>
>> 1) Last 4 lines on page 4:  Not all operations on an empty interval
>> produce an empty result.  The hull operator is the one exception. This
>> is a good reason why un-initialized intervals should be set to the
>> whole interval.  They will propagate (except through the intersection
>> operator with a finite interval) and be noticed quickly when
>> debugging.  They cannot result in a containment failure.
>
> Sorry, I don't understand what the "good reason" is. This cannot be the
> fact that "they will propagate". Indeed, whole intervals do not
> propagate through intersect nor cos nor sin nor square nor sqrt nor exp
> nor pow (with an even exponent) nor atan nor cosh nor any other function
> with a codomain shorter than the whole real line. Empty intervals do. I
> don't understand either why it would be quicker to notice whole
> intervals than empty intervals when debugging, especially as there is an
> is_empty predicate but no is_whole predicate.
>
>> 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 may be too pessimistic, but I think the
> proposal would automatically become void after such a change. There are
> a few standardization experts on this list, I hope they can give us an
> enlightened opinion on what would presumably happen if we were to scrap
> the class definition and replace it with a sentence like "There are
> three types named interval_float, interval_double, and
> interval_long_double."
>
>> 4) Page 6 - Empty Interval: Relative to the discussion of
>> implementations on platforms that do not support NaNs, opaqueness
>> solves the difficulty.
>
> I don't see any difficulty that needs solving. This is a non-normative
> paragraph meant to help vendors implement an interval library. We are
> explaining there that using NaNs for bounds leads to an efficient
> implementation of empty intervals. I don't see the point in removing
> this paragraph (?).
>
>> 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. It would require modifying the current Standard to add new members
> to the numpunct facet at the very least. This may be more satisfying,
> but it means a longer and more intrusive proposal.
>
> This makes me wonder if interval(char const *) should specify that the
> string is always parsed with the C locale.
>
>> 6) Page 7 - order relations on empty intervals and - Why do
>> "certainly" comparisons return "true" for empty intervals?: There are
>> good reasons why *all* relations tests on empty intervals should
>> return false.
>
> There are also good reasons to have "certainly" comparisons return true
> on empty intervals. If you use the following definition for a certainly
> less-than, then true is the natural answer when an empty interval is
> involved. Given A and B two intervals, A < B is defined as
>
>    forall a in A, forall b in B, a < b
>
> Moreover, this gives the following conservative identity:
>
>    certainly(a < b) == !possibly(a >= b)
>
> So, as they both have their pros and cons, we need a strong rationale to
> decide between returning true and returning false when certainly
> comparing an interval with the empty set.
>
>> 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.
>
>> 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. Specifying
> std::interval as having the same defect as std::complex would require a
> strong rationale in my opinion. I don't think it is sufficient to say
> that it allows an implementation to provide non-standardized features.
> If the opaqueness allowed a better implementation of the standardized
> features, then this would be a strong enough rationale for removing the
> memory layout.
>
>> The following typo was noticed by Mike Schulte:
>>
>> Page 3 - The specification states "Those optimizations, however, are
>> necessary for implementing the proposal." I believe this should be
>> "Those optimizations, however, are *not* necessary for implementing
>> the proposal."
>
> Thanks. Surprisingly, it seems somebody has already fixed this mistake,
> as my local version reads "Those optimizations, however, are not
> compulsory for implementing the proposal."
>
> Thanks for all your comments.
>
> Best regards,
>
> Guillaume
>
>
> ------------------------------
>
> Message: 3
> Date: 21 Sep 2006 03:04:51 +0200
> From: Gabriel Dos Reis <gdr at integrable-solutions.net>
> Subject: Re: [std-interval] Suggestions for the 2006-09 draft
> To: For discussions concerning the C++ standardization of intervals
> <std-interval at compgeom.poly.edu>
> Cc: Bill.Walster at sun.com
> Message-ID: <m3wt7yrpvw.fsf at zeus.integrable-solutions.net>
> Content-Type: text/plain; charset=us-ascii
>
> 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
>
> ------------------------------
>
> Message: 4
> Date: Thu, 21 Sep 2006 08:59:18 +0200
> From: Guillaume Melquiond <guillaume.melquiond at ens-lyon.fr>
> Subject: Re: [std-interval] Suggestions for the 2006-09 draft
> To: For discussions concerning the C++ standardization of intervals
> <std-interval at compgeom.poly.edu>
> Message-ID: <1158821958.5976.49.camel at saline>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
>
> ------------------------------
>
> _______________________________________________
> Std-interval mailing list
> Std-interval at compgeom.poly.edu
> http://compgeom.poly.edu/mailman/listinfo/std-interval
>
>
> End of Std-interval Digest, Vol 8, Issue 14
> *******************************************
>