[std-interval] Re: Std-interval Digest, Vol 8, Issue 15
Ray Moore
rmoore17 at columbus.rr.com
Thu Sep 21 15:26:30 PDT 2006
Colleagues,
When I mentioned that "an ermpty interval is contained in any given
interval", I was thinking about set containment as an order relation, of
course. It is not the same thing as an order relation among points on the
real line, of course.
Ray
----- Original Message -----
From: <std-interval-request at compgeom.poly.edu>
To: <std-interval at compgeom.poly.edu>
Sent: Thursday, September 21, 2006 5:39 AM
Subject: Std-interval Digest, Vol 8, Issue 15
> 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. Re: Suggestions for the 2006-09 draft (Dr John Pryce)
> 2. Re: Suggestions for the 2006-09 draft (R. Baker Kearfott)
> 3. Re: Std-interval Digest, Vol 8, Issue 14 (Ray Moore)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Sep 2006 09:55:11 +0100
> From: Dr John Pryce <j.d.pryce at ntlworld.com>
> Subject: Re: [std-interval] Suggestions for the 2006-09 draft
> To: Bill.Walster at sun.com,<std-interval at compgeom.poly.edu>
> Message-ID: <6.2.5.6.0.20060921093907.02cf48d0 at ntlworld.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> Bill
>
> At 22:18 20/09/06, you wrote:
>>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.
>
> I liked your comments. I feel Guillaume and colleagues tend to see
> things too much from the implementation viewpoint and you have
> emphasized principles. In particular I am massively in favour of
> "opaqueness" of the data representation. But, being a C++ beginner, I
> can't comment on issues that depend on details of the language spec.
>
> Opaqueness raises the question of how to tie the precision of
> interval<T> to that of T, which I posed in a posting one or two days
> ago. As their text stands, I believe that opaqueness would allow the
> implementations of interval<float>, interval<double> and
> interval<long double> to be all identical.
>
> What do you think?
>
> Regards
>
> John
>
> Dr John and Mrs Kate Pryce
> 142 Kingshill Rd
> Swindon, Wiltshire SN1 4LW
> UK
> Tel (+44)1793-331062
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Sep 2006 04:47:19 -0500
> From: "R. Baker Kearfott" <rbk at louisiana.edu>
> 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>, Bill.Walster at sun.com
> Message-ID: <2.2.32.20060921094719.00a294c4 at pop.louisiana.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> Bill, John,
>
> I have the same sentiments as both of you.
>
> Baker
>
> At 09:55 AM 9/21/2006 +0100, Dr John Pryce wrote:
>>Bill
>>
>>At 22:18 20/09/06, you wrote:
>>>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.
>>
>>I liked your comments. I feel Guillaume and colleagues tend to see
>>things too much from the implementation viewpoint and you have
>>emphasized principles. In particular I am massively in favour of
>>"opaqueness" of the data representation. But, being a C++ beginner, I
>>can't comment on issues that depend on details of the language spec.
>>
>>Opaqueness raises the question of how to tie the precision of
>>interval<T> to that of T, which I posed in a posting one or two days
>>ago. As their text stands, I believe that opaqueness would allow the
>>implementations of interval<float>, interval<double> and
>>interval<long double> to be all identical.
>>
>>What do you think?
>>
>>Regards
>>
>>John
>>
>>Dr John and Mrs Kate Pryce
>>142 Kingshill Rd
>>Swindon, Wiltshire SN1 4LW
>>UK
>>Tel (+44)1793-331062
>>
>>_______________________________________________
>>Std-interval mailing list
>>Std-interval at compgeom.poly.edu
>>http://compgeom.poly.edu/mailman/listinfo/std-interval
>>
>>
>>
>
> ---------------------------------------------------------------
> R. Baker Kearfott, rbk at louisiana.edu (337) 482-5346 (fax)
> (337) 482-5270 (work) (337) 993-1827 (home)
> URL: http://interval.louisiana.edu/kearfott.html
> Department of Mathematics, University of Louisiana at Lafayette
> (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
> Box 4-1010, Lafayette, LA 70504-1010, USA
> ---------------------------------------------------------------
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Sep 2006 06:31:01 -0400
> From: "Ray Moore" <rmoore17 at columbus.rr.com>
> Subject: [std-interval] Re: Std-interval Digest, Vol 8, Issue 14
> To: <std-interval at compgeom.poly.edu>
> Message-ID: <000301c6dd69$092cbfb0$0202a8c0 at Moore>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
> 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
>> *******************************************
>>
>
>
>
> ------------------------------
>
> _______________________________________________
> 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 15
> *******************************************
>
More information about the Std-interval
mailing list