P1788: M0021.02 PASSES
P1788,
Motion 21.02 passes, Yes: 31; No: 18, with 37 voters required for a quorum.
Most of the discussion specific to this motion that occurred during the voting is appended below.
Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave
Milwaukee WI 53201-1881 USA
414-288-6599; GasDay: 288-4400; Fax 288-5579
George.Corliss@xxxxxxxxxxxxx
www.eng.mu.edu/corlissg
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Date: November 22, 2010 1:33:31 PM CST
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: [IEEE P-1788] Voting begins: Motion P1788/M0021.2:IntervalOverlapping
> Reply-To: <rbk@xxxxxxxxxxxx>
>
> P-1788:
>
> The discussion period for Motion 21.2 has ended,
> so voting on it will now begin. Voting will continue until the
> after Monday, December 13. The voting will proceed according to
> the rules for position papers (with a simple majority and a
> quorum required for passage).
>
> Juergen: Thank you for already updating the status on the web site.
>
> All: The motion is available as a link on the web page
> http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html
> (in the private area of the web site). Please contact me if you
> need a password for the private area.
>
> Note: There was previous confusion about the counting of absentee votes
> and determination of a quorum. We have been determining a quorum
> based on the number of active members that have registered with IEEE.
> Also, we have not been removing members from the list of active members
> based on non-participation in position paper votes (and only based
> on non-participation in votes involving standards wording). However,
> 8.2, "Working group membership status," paragraph 2 states:
>
> "Each member is expected to remain informed of working group business,
> either through attending meetings or through electronic means, and to
> participate in votes. The Secretary (or Vote Tabulator, as appropriate)
> records who votes. Those who fail to vote on two consecutive issues will
> be dropped from the roster. These persons can have their voting privileges
> reinstated by again officially placing themselves on the roster."
>
> Thus, there is no distinction between position votes and standards wording
> votes in this regard. To follow our policies and procedures document,
> we will therefore drop people on the roster after two consecutive non-votes
> ON ANY ISSUE. This includes the present vote.
>
>
> Sincerely,
>
> Baker
Begin forwarded message:
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> Date: December 3, 2010 8:15:15 AM CST
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Cc: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Reminder: Motion P1788/M0021.2:IntervalOverlapping
>
> Corliss, George wrote:
>> Reminder: Voting on Motion 21.2 is open until Monday, December 13. Baker's announcement is appended below.
>> Current tally: Yes: 2; No: 0; Required for quorum: 37 As Baker explains in more detail, "To follow our policies and procedures document, we will therefore drop people on the roster after two consecutive non-votes ON ANY ISSUE. This includes the present vote."
>
> So, vote No!
> ... to support a simple, useful, and easily intelligible standard.
>
>
> Arnold Neumaier
Begin forwarded message:
> From: Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Date: December 3, 2010 10:07:35 AM CST
> To: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>, P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Reminder: Motion P1788/M0021.2:IntervalOverlapping
>
> So vote YES!
> ... to have an option for new ideas.
> Juergen
Begin forwarded message:
> From: Svetoslav Markov <smarkov@xxxxxxxxxx>
> Date: December 4, 2010 9:17:00 AM CST
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: (Fwd) Re: Reminder: Motion P1788/M0021.2:IntervalOverlapping
>
> I vote yes on motion 21.2
>
> (because I think that the order relations "overlaps" and
> "overlapped by" are important and should be in the standard)
>
> Svetoslav
Begin forwarded message:
> From: Alexandru Amaricai <amaricai@xxxxxxxxx>
> Date: December 4, 2010 1:20:36 PM CST
> To: <stds-1788@xxxxxxxx>
> Subject: Motion 21
>
> I vote NO on motion 21, in order to keep on simple standard.
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Date: December 4, 2010 9:15:08 PM CST
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: I vote NO on motion 21...
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
> Folks,
>
> I vote NO on motion 21.
>
> My reason has nothing to do with the set of
> comparisons proposed. Any reasonable set is
> fine with me.
>
> The reason I vote NO is that the motion is
> written in a manner that suggests (or even
> implies) the existence of state attached to
> the act of making a comparison.
>
> We wrote comparisons in a similar manner in
> 754-1985 & it led to implementers actually
> CREATING such state as 4 global variable
> bits usually in a PSW attached to the thread
> of execution in question.
>
> At the time & in the era of 4 MegaHz 8-bit
> microprocessors that implemented their
> floating-point in software more often than
> not, this was not considered bad.
>
> But in the years that have followed it has
> become clear that requiring state is a bad
> thing in the era of multi threaded multi
> GigaHz 32 or 64 bit microprocessors with
> multiple on chip floating-point units. It
> creates an interlock choke point similar to
> a branch that slows everything down & makes
> added headaches for the hardware designer.
>
> And, for us, it will delay the acceptance
> of 1788 into general hardware use.
>
> But all is not lost.
>
> It would be sufficient to rewrite motion 21
> to describe the list of comparisons only.
>
> Any organization of those comparisons into a
> system that requires 13 states to describe it
> (such as tables 1 & 2 & the language that goes
> with them) should be left out or, at the very
> least, relegated to an informative annex.
>
> If this were done I would change my vote to
> YES.
>
> Yours,
>
> Dan
Begin forwarded message:
> From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>
> Date: December 5, 2010 6:06:40 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: I vote NO on motion 21...
>
>
> Dear P1788 members,
>
> I share the same view described by Dan below regarding the problems due to the presence of global states in current and future hardware systems.
>
> Hence, I vote NO as well.
Begin forwarded message:
> From: Andreas Rauh <andreas.rauh@xxxxxxxxxxxxxx>
> Date: December 5, 2010 6:43:12 AM CST
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0021.2:IntervalOverlapping: NO
>
> Dear colleagues,
>
> my vote is NO, with the same reason given already by Dan Zuras. However, I really like the idea of order relations such as "overlaps" and "overlapped by".
>
> Best regards,
> Andreas
Begin forwarded message:
> From: <vaccaro@xxxxxxxxxxxx>
> Date: December 5, 2010 3:36:30 PM CST
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0021.2:IntervalOverlapping: NO
>
> For this motion my vote is NO.
> I fully agree with the argumentations discussed by Dan Zuras.
>
> A.Vaccaro
Begin forwarded message:
> From: Dominique Lohez <dominique.lohez@xxxxxxx>
> Date: December 6, 2010 3:33:33 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Subject: Motion p1788/21.02 Interval overlapping vote YES
>
> My vote is YES because
> 1) I think that it is really useful to be able to identify among a panel of comparison what comparison(s) is(are) really true
> 2) the panel of available comparisons is very convenient 5 even if it could be improved)
>
> Best regards
>
>
> Dominique
Begin forwarded message:
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Date: December 6, 2010 7:40:54 AM CST
> To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: P1788 Motion M0021.02 YES
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>
> I vote yes for Motion 21.2 interval overlapping:
>
> I think it is specified clear enough not to be global state, e.g., the result of the interval overlapping operator is a first-class abstract data type IOV (this is something the IEEE 754 documents didn't do).
>
> I also see the motion is practical, particularly for applications of temporal and spatial sorting (including red-black trees). With proper hardware support these algorithms should be much faster due to interval overlapping. Since we use these algorithms in our products and applications, we would make good use of any interval processor that suppported interval overlapping operations.
>
> Sincerely,
>
> Nate Hayes
> Sunfish Studio, LLC
Begin forwarded message:
> From: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Date: December 6, 2010 10:11:33 AM CST
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: I vote NO on motion 21...
>
> Am 05.12.2010 04:15, schrieb Dan Zuras Intervals:
>> Folks,
>>
>> I vote NO on motion 21.
>>
>> My reason has nothing to do with the set of
>> comparisons proposed. Any reasonable set is
>> fine with me.
>>
>> The reason I vote NO is that the motion is
>> written in a manner that suggests (or even
>> implies) the existence of state attached to
>> the act of making a comparison.
>>
>> We wrote comparisons in a similar manner in
>> 754-1985& it led to implementers actually
>> CREATING such state as 4 global variable
>> bits usually in a PSW attached to the thread
>> of execution in question.
>>
>> At the time& in the era of 4 MegaHz 8-bit
>> microprocessors that implemented their
>> floating-point in software more often than
>> not, this was not considered bad.
>>
>> But in the years that have followed it has
>> become clear that requiring state is a bad
>> thing in the era of multi threaded multi
>> GigaHz 32 or 64 bit microprocessors with
>> multiple on chip floating-point units. It
>> creates an interlock choke point similar to
>> a branch that slows everything down& makes
>> added headaches for the hardware designer.
>>
>> And, for us, it will delay the acceptance
>> of 1788 into general hardware use.
>>
>> But all is not lost.
>>
>> It would be sufficient to rewrite motion 21
>> to describe the list of comparisons only.
>>
>> Any organization of those comparisons into a
>> system that requires 13 states to describe it
>> (such as tables 1& 2& the language that goes
>> with them) should be left out or, at the very
>> least, relegated to an informative annex.
>>
>> If this were done I would change my vote to
>> YES.
>>
>> Yours,
>>
>> Dan
>
>
> Dear Dan, P1788,
>
> as you can see in the motion text there is no requirement for global state.
>
> >>>>
> Motion 21
> "P1788 should provide access to the states of the interval overlapping
> relation. In particular it should provide a function on two intervals a and b whose range is the set of 13 states defined by tables 1 and 2.
> Additionally the functionality of the abstract data type IOV described by table 8 in section 5 of the position paper should be available.
> For full flexibility the atomic operations should be available as comparisons, see Table 9."
>
> This motion is to be understood as a supplement to motion 13.04.
> The advantages are outlined in the position paper that serves as
> rationale for the motion.
> <<<<
>
>
> As Nate indicated in his vote an abstract data type is used.
>
>
> Jürgen & Marco
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
> Date: December 7, 2010 1:43:49 AM CST
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: A "no" vote on Motion 21.2 from Josep Vehi
>
> P-1788:
>
> I am relaying this, which was sent privately to me.
>
> Baker
> ===========
>
> I vote No to Motion 21.2, to keep the standard as clear and simple as possible.
>
> Best regards,
> Josep
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: December 7, 2010 4:16:54 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: P1788 Motion M0021.02 YES
>
> P1788
>
> If Motion 21.02 had said the features described are *required* I should certainly have voted NO. The position paper is unclear about this because the standardese words "shall", "should", "required" etc. hardly occur, and don't make the intent obvious.
>
> But Juergen & Marco's accompanying motion statement, below, make it clear these features are *recommended*:
>> Motion 21.2
>>
>> P1788 *should* provide access to the states of the interval overlapping relation.
>>
>> In particular it *should* provide a function on two intervals a and b whose range is the set of 13 states defined by tables 1 and 2.
>>
>> Additionally the functionality of the abstract data type IOV described by table 8 in section 5 of the position paper *should* be available.
>>
>> For full flexibility the atomic operations *should* be available as comparisons, see Table 9."
>>
>> This motion is to be understood as a supplement to motion 13.04.
>> The advantages are outlined in the position paper that serves as
>> rationale for the motion.
>>
>> Note that we do not want to change the traditional way of interval comparisons as outlined in motion 13.04 but we want P1788 to provide an additional way AS AN OPTION, that may offer some new kind of applications.
> (added emphases mine)
>
> I think this is right. This implies they will appear in an Annex. Those who, like Nate, can see a use for them and maybe an opportunity to put them into hardware, will implement them. If the result looks appealing, people will say "me too", other implementations will appear and maybe the feature will become required in a future revision. If not, not.
>
> Therefore I vote YES. People who voted no, did you vote against even the _option_ of this feature?
>
> John Pryce
> Begin forwarded message:
>
>> From: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>> Date: December 7, 2010 10:05:53 AM CST
>> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>, John Pryce <j.d.pryce@xxxxxxxxxxxx>
>> Subject: P1788 Motion M0021.02 YES
>>
>> YES. I agree with John, too.
>>
>> I remark that these are motions of positions, NOT of wording. I assume that the Technical Editors will adjust wording when preparing actual standards text.
>>
>> Dr. George F. Corliss
>>
>> On Dec 7, 2010, at 9:39 AM, Kreinovich, Vladik wrote:
>>
>>> I vote YES, since as recommended it makes sense
>
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Date: December 7, 2010 1:59:37 PM CST
> To: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: P1788 Motion M0021.02 YES
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
>> Subject: Re: P1788 Motion M0021.02 YES
>> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
>> Date: Tue, 7 Dec 2010 10:16:54 +0000
>> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>>
>> P1788
>>
>> If Motion 21.02 had said the features described are
>> *required* I should certainly have voted NO. The
>> position paper is unclear about this because the
>> standardese words "shall", "should", "required" etc.
>> hardly occur, and don't make the intent obvious.
>>
>> But Juergen & Marco's accompanying motion statement,
>> below, make it clear these features are *recommended*:
>
> John,
>
> This too is cause to reject the motion.
> If the intent is to put something as fundamental
> as comparison relations under "should", they
> have no portable utility at all.
>
> Remember, the implementer's interpretation of
> the word "shall" is "I NEED to do it" & the
> word "should" is "I DON'T need to do it".
>
> As such, if the comparisons themselves are not
> under 'shall' they cannot be counted on to be
> used in portable code. Indeed, they cannot even
> be written into pseudo code in peer reviewed
> papers as some reviewer will reject that paper
> on the grounds that the code cannot be reliably
> written.
>
> Therefore, the list of comparisons, whatever
> they are, should all appear under 'shall'.
>
>>> Motion 21.2
>>>
>>> . . .
>>>
>>
>> I think this is right. This implies they will appear
>> in an Annex. Those who, like Nate, can see a use for
>> them and maybe an opportunity to put them into hardware,
>> will implement them. If the result looks appealing,
>> people will say "me too", other implementations will
>> appear and maybe the feature will become required in
>> a future revision. If not, not.
>>
>> Therefore I vote YES. People who voted no, did you vote
>> against even the _option_ of this feature?
>>
>> John Pryce
>
> As you point out, the motion speaks of the 'state'
> associated with comparisons in the same language as
> it does of the comparisons themselves. To quote
> from the introduction:
>
> In [6] we have shown that the general overlapping
> relation can be efficiently implemented in hardware.
> 4 bits are sufficient to encode the different states.
> Together with an object oriented interface allowing
> the direct access to the states (cases) this will
> presumably lead to a better performance of
> application programs.
>
> The notion of some hardware operation that returned
> a 'state' rather than true or false was thought to
> be interesting in 1985. The idea was that, having
> acquired the 'state' you now have all the information
> needed to make any comparison you require.
>
> But this is not how algorithms are written. One knows
> in advance what relation is needed & all one needs to
> know is whether that relation is true or false. The
> burden of the creation of state on the chance that you
> MIGHT want save the need to do another comparison turned
> out to be a very poor tradeoff indeed.
>
> So, not only would vote against a motion that considered
> state under 'shall', I would vote against a motion that
> suggested it under 'should'.
>
> So, yes, I would vote against even the option of such a
> thing.
>
> However, if my interpretation is incorrect & you believe
> the intent is to define a list comparisons under 'shall'
> & NOT to define state at all (even under 'should') then
> you may have my YES vote.
>
> Even if we all agree that you, as editor, will write the
> document in that way, you may have my YES vote.
>
> But, until we come to that understanding, I think I will
> still vote NO.
>
> Yours,
>
> Dan
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: December 8, 2010 2:13:31 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: P1788 Motion M0021.02 YES
>
> Dan
>
> On 7 Dec 2010, at 19:59, Dan Zuras Intervals wrote:
>> This too is cause to reject the motion.
>> If the intent is to put something as fundamental
>> as comparison relations under "should", they
>> have no portable utility at all.
>>
>> Remember, the implementer's interpretation of
>> the word "shall" is "I NEED to do it" & the
>> word "should" is "I DON'T need to do it".
>
>
> Indeed. But the Kulisch comparisons of motion 13 are all "shall".
>
> John
Begin forwarded message:
> From: Ned Nedialkov <nedialk@xxxxxxxxxxx>
> Date: December 8, 2010 2:20:16 PM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: P1788 Motion M0021.02: NO
>
> I vote NO.
>
> I would vote for a minimal set of operations, as Arnold suggested earlier. What is proposed is way to complicated in my opinion.
> I think we need a small, simple "kernel" of interval operations, so an "ordinary" person can grasp them easily.
>
> Best regards,
> Ned
Begin forwarded message:
> From: Svetoslav Markov <smarkov@xxxxxxxxxx>
> Date: December 9, 2010 5:08:08 AM CST
> To: Ned Nedialkov <nedialk@xxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: P1788 Motion M0021.02: NO
>
> Dear Ned,
>
> in principle I do not like any non-mathematical
> arguments, but now you challenge me to say
> the following :
>
> 1) any "ordinary" person can grasp the relations easily
> from the provided picture;
>
> 2) these relations will be certainly liked by the "temporal interval
> algebra community" and it will be good if this community
> uses the standard as well.
>
> Svetoslav
Begin forwarded message:
> From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
> Date: December 9, 2010 8:39:32 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: P1788 Motion M0021.02: NO
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I vote NO on Motion 21.02 to support the KISS principle.
>
> FG.
> - --
> Frédéric Goualard LINA - UMR CNRS 6241
> Begin forwarded message:
>
>> From: Michael Schulte <schulte@xxxxxxxxxxxxx>
>> Date: December 9, 2010 6:40:50 PM CST
>> To: <owner-stds-1788@xxxxxxxxxxxxxxxxx>
>> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
>> Subject: P1788 Motion M0021.22 No
>> Reply-To: <schulte@xxxxxxxxxxxxx>
>>
>> I vote NO on Motion 21.2, since would add unnecessary complexity to the standard.
>>
>
> Begin forwarded message:
>
>> From: Chenyi Hu <CHu@xxxxxxx>
>> Date: December 11, 2010 11:27:36 AM CST
>> To: <stds-1788@xxxxxxxx>
>> Subject: P1788/M0021.2 NO
>>
>> I vote NO on this motion.
>>
>> I have not been able to see the broadness of its potential application that justifies its position in the standard.
>>
>> Sincerely,
>>
>>
>> Chenyi Hu
>
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: December 11, 2010 11:40:56 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0021.2: YES
>
> I vote a reluctant YES on Motion P1788/M0021.2 -- reluctant because
> I appreciate Dan Zuras' warning about misinerpretation, and others'
> desire for KISS.
>
> The position paper does offer an interesting background however, more
> concrete (in my opinion) than the bare BRA framework of Dominique Lohez'
> proposal (motion 20) -- and the motion itself clearly states that the
> mandatory comparisons are those of motion 13, and that the "overlapping"
> function (it's NOT a relation, it's a function with a range of 13, 16 or
> 17 enmerated states -- more on that below) would just be a recommended
> addendum.
>
> My position on such optional features is that they ARE worth standardizing,
> in the sense that it is only the availability that is optional (and even
> that should apply to a consistent package and not individual features):
> IF the facility is present, it MUST have the standard-defined properties.
> This is more useful than not saying anything, because in that case one
> cannot depend on anything.
>
> Now, have we 13, 16 or 17 possible outcomes of "overlapping(A,B)"?
>
> I mention 17 because the result is not an interval, so decorations don't
> apply -- yet there must be a result for the case where at least one of the
> arguments is invalid. (Not every enviroment supports throwing exceptions.)
> Simply treating invalid intervals as Empty may not be the right answer.
>
> I think he critical voting will come when we see the impact of this motion
> on the text of the draft standard.
>
> Michel.
Begin forwarded message:
> From: Mark Stadtherr <markst@xxxxxx>
> Date: December 11, 2010 9:43:22 PM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0021.2: YES
> Reply-To: <markst@xxxxxx>
>
> I will vote yes, with some reluctance as expressed by
> Michel Hack. I think there is some value in standardizing
> optional features.
>
> Mark
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Date: December 12, 2010 5:34:52 AM CST
> To: <stds-1788@xxxxxxxx>
> Subject: P1788 Motion M0021.02 YES
>
> I vote yes for Motion 21.2.
>
> I haven't had the time to look at the rationale extensively, but
> the implementation seems rather simple and it is optional, and
> such relations may be useful in some applications. So, I don't
> see any reason to reject the motion.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Date: December 12, 2010 5:47:03 AM CST
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: I vote NO on motion 21...
>
> On 2010-12-04 19:15:08 -0800, Dan Zuras Intervals wrote:
>> Folks,
>>
>> I vote NO on motion 21.
>>
>> My reason has nothing to do with the set of
>> comparisons proposed. Any reasonable set is
>> fine with me.
>>
>> The reason I vote NO is that the motion is
>> written in a manner that suggests (or even
>> implies) the existence of state attached to
>> the act of making a comparison.
>
> This is wrong: it doesn't suggest or imply anything like that (the
> word "state" is used purely in an abstract specification; there are
> no data formats with some state in them). Perhaps the wording isn't
> perfect, but we are not voting on the wording.
>
>> We wrote comparisons in a similar manner in
>> 754-1985 & it led to implementers actually
>> CREATING such state as 4 global variable
>> bits usually in a PSW attached to the thread
>> of execution in question.
>>
>> At the time & in the era of 4 MegaHz 8-bit
>> microprocessors that implemented their
>> floating-point in software more often than
>> not, this was not considered bad.
>
> So, what's wrong at that time?
>
>> But in the years that have followed it has
>> become clear that requiring state is a bad
>> thing in the era of multi threaded multi
>> GigaHz 32 or 64 bit microprocessors with
>> multiple on chip floating-point units. It
>> creates an interlock choke point similar to
>> a branch that slows everything down & makes
>> added headaches for the hardware designer.
>
> They are not forced to use the same kind of implementation today.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>
> Date: December 12, 2010 5:55:52 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0021.2: NO
>
> I vote NO on motion P1788/M0021.2.
>
> The system seemed elegant to me at first. But when I tried to apply it
> to some of my use cases, I soon become overwhelmed trying to figure
> which subsets of the partition were corresponding to the relations I
> wanted to express. In the end, it seemed faster and less error-prone to
> go back to just comparing bounds. My feeling is that most users will
> experience the same situation, causing the feature to just bloat the
> standard if it goes unused, hence my vote.
>
> Best regards,
>
> Guillaume
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: December 12, 2010 5:51:42 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Vincent's comment on Dan's reason to vote NO
>
> (With regard to Motion 21 and the notion of "state")
>
> Vincent Lefèvre wrote:
>> They are not forced to use the same kind of implementation today.
>
> Dan's point was that they were not forced back then either -- but thought
> they were based on a possible misunderstanding of the wording of the 1985
> standard (IEEE 754).
>
> Michel
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: December 12, 2010 10:12:42 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0021.2: NO
>
> On 12 Dec 2010, at 11:55, Guillaume Melquiond wrote:
>> I vote NO on motion P1788/M0021.2.
>>
>> The system seemed elegant to me at first. But when I tried to apply it
>> to some of my use cases, I soon become overwhelmed trying to figure
>> which subsets of the partition were corresponding to the relations I
>> wanted to express. In the end, it seemed faster and less error-prone to
>> go back to just comparing bounds. My feeling is that most users will
>> experience the same situation, causing the feature to just bloat the
>> standard if it goes unused, hence my vote.
>
> Thanks Guillaume, that's the sort of experimenting we need.
> John Pryce
Begin forwarded message:
> From: Christian Keil <c.keil@xxxxxxxxxxxxx>
> Date: December 12, 2010 2:01:37 PM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: P1788/M0021.2: NO
>
> My vote on this motion is NO.
>
> Guillaume's reasoning pretty well describes my impression when
> reading the motion.
>
> Regards,
>
> Christian
Begin forwarded message:
> From: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Date: December 12, 2010 5:52:07 PM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0021.2:IntervalOverlapping NO
>
> I vote NO on M0021.2.
>
> I do not believe that the set of operations listed in this paper are
> generally useful, and it enlarges the specification without clear
> benefit. There is nothing in the paper that could not be obtained by
> allowing access to the infimum and supremum of each interval and
> allowing the user to make their own comparisons.
>
> In addition, I think some of the comparisons are actively dangerous,
> such as "meets" or "starts" or "finishes" or "finishedBy" or "startedBy"
> or "metBy", or "equalP". These essentially require testing equality of
> two imprecise floating-point numbers, and doing something based on that
> test. This is almost always bad practice, and usually indicates
> misunderstanding of uncertainties in floating-point math. In an
> ordinary numeric program, if you're doing something like
>
> if a==1.1
> doSomething()
>
> Then your program should probably be considered untrustable and will
> likely not do what you intend. This proposal essentially
> institutionalizes that untrustable, worst-practice behavior.
>
> When comparing intervals, where endpoints are rounded outward, these
> operations will probably never do what you want, as "very close"
> endpoints will not actually be coincident.
>
> --
> Alan Eliasen
> eliasen@xxxxxxxxxxxxxx
> http://futureboy.us/
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Date: December 13, 2010 8:28:16 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0021.2:IntervalOverlapping NO
>
> On 2010-12-12 16:52:07 -0700, Alan Eliasen wrote:
>> I vote NO on M0021.2.
>>
>> I do not believe that the set of operations listed in this paper are
>> generally useful, and it enlarges the specification without clear
>> benefit. There is nothing in the paper that could not be obtained by
>> allowing access to the infimum and supremum of each interval and
>> allowing the user to make their own comparisons.
>
> This is also true for Motion 13.04, which has passed (I note that
> you also voted NO on it, though, but this wasn't such a firm NO).
>
> BTW, a point that Motion 13.04 is missing is set-based definitions,
> I mean the equivalent of Table 1 of Motion 21.2.
>
>> In addition, I think some of the comparisons are actively dangerous,
>> such as "meets" or "starts" or "finishes" or "finishedBy" or "startedBy"
>> or "metBy", or "equalP". These essentially require testing equality of
>> two imprecise floating-point numbers, and doing something based on that
>> test.
>
> This is also true for Motion 13.04 (which has a = b, but also
> two different "a precedes or touches b" and "a precedes b").
>
> Anyway if you want to avoid such problems, you should define
> an arithmetic without discontinuous functions, thus without
> comparisons.
>
>> This is almost always bad practice, and usually indicates
>> misunderstanding of uncertainties in floating-point math.
>
> Note that IEEE 754 offers some guarantee.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>