P1788: Comments on Motion 36 Flavors
P1788,
Motion 36 Flavors final vote:
Yes: 25
No: 23
A compilation of comments during the voting period is below
George Corliss, P1788 Voting Tabulator
George.Corliss@xxxxxxxxxxxxx
Begin forwarded message:
> From: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Subject: YES Motion P1788/M0036.03:Flavors
> Date: August 22, 2012 6:16:16 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>, "rbk@xxxxxxxxxxxxx" <rbk@xxxxxxxxxxxxx>
>
> P1788,
>
> I vote YES on Motion 36 Flavors
>
> SOMEONE has to get the voting started. It seems to me John has done an admirable job of decoupling the needs/desires of different segments of the interval community. This motion provides a structure under which those who care about each "flavor" of interval can make progress toward a standard that will include their flavor.
Begin forwarded message:
> From: Dominique Lohez <dominique.lohez@xxxxxxx>
> Subject: Motion P1788/M0036.03:Flavors Vote NO
> Date: August 22, 2012 10:28:53 AM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
>
> My vote is NO
>
> I would vote if the following change were done
>
> 1) In terminology the sentence
>
> , and any related kind that the modal subgroup may wish to specify.
>
>
>
>
> 2) the cause 2 before the add is replaced by
>
> All the operations defined on "classical" intervals should be appropriately extended to modal intervals
>
> Other flavors are discussed in a future motion.
> The add is kept .
>
> The clause 5 is removed
>
>
>
> In clause 7 the sentence
>
> An implementation shall support at least one flavor. It shall document which flavors it supports.
> is replaced by
>
> An implementation SHALL support set based intervals
>
>
>
> An implementation SHOULD support modal intervals
>
>
>
> The rationale will be detailed on separate mail.
>
>
> Dominique
Begin forwarded message:
> From: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Subject: RE: Motion P1788/M0036.03:Flavors Vote NO
> Date: August 22, 2012 10:37:56 AM CDT
> To: 'Dominique Lohez' <dominique.lohez@xxxxxxx>, "'Corliss, George'" <george.corliss@xxxxxxxxxxxxx>, 'stds-1788' <stds-1788@xxxxxxxxxxxxxxxxx>
>
> For the benefit of those who are not native English speakers, SHALL means that for only packages that implement set operations satisfy our standard, but what does SHOULD mean and how it is different?
>
> P.S. This reminds me of discussion in the US about Second Amendment where two sides are absolutely sure about the meaning but this meaning is exactly opposite :-(
>
> I know should and shall differ in some bureaucratic documents
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Subject: Re: shall vs should Re: Motion P1788/M0036.03:Flavors Vote NO
> Date: August 22, 2012 11:16:20 AM CDT
> To: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Cc: 'Dominique Lohez' <dominique.lohez@xxxxxxx>, "'Corliss, George'" <george.corliss@xxxxxxxxxxxxx>, 'stds-1788' <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> Actually, I believe "shall" is a also technical term in
> "standardese" language: SHALL is "normative," that is,
> it dictates something the standard must contain. I'm
> not sure "should" means anything in this context, but,
> in common English, "should" means something like
> it is the logical, reasonable, or the correct
> thing to do.
>
> In the actual standards document, we should use "shall" to
> dictate what is actually standard-conforming.
>
> Baker
Begin forwarded message:
> From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxx>
> Subject: RE: Motion P1788/M0036.03:Flavors
> Date: August 22, 2012 11:29:22 AM CDT
> To: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Cc: 'Dominique Lohez' <dominique.lohez@xxxxxxx>, "'Corliss, George'" <george.corliss@xxxxxxxxxxxxx>, 'stds-1788' <stds-1788@xxxxxxxxxxxxxxxxx>
>
>
> Dear 1788,
>
> My vote on this flavors motion is YES.
>
>
> On Wed, 2012-08-22 at 09:37 -0600, Kreinovich, Vladik wrote:
>> For the benefit of those who are not native English speakers, SHALL means that for only packages that implement set operations satisfy our standard, but what does SHOULD mean and how it is different?
>
> In the IEEE standards terminology "shall" indicates necessary
> requirements. Implementations MUST implement any "shall" requirements
> in order to claim compliance to the standard.
>
> However, for IEEE "should" is only a recommendation. An implementation
> that does NOT implement a "should" clause of the standard can still
> claim compliance if it fulfills all the "shall"s.
>
>
> Best regards
> --
> Hossam A. H. Fahmy
Begin forwarded message:
> From: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Subject: RE: Motion P1788/M0036.03:Flavors Vote NO
> Date: August 22, 2012 11:57:33 AM CDT
> To: "'Ferguson, Warren E'" <warren.e.ferguson@xxxxxxxxx>
> Cc: 'stds-1788' <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Thanks a lot!
>
> -----Original Message-----
> From: Ferguson, Warren E [mailto:warren.e.ferguson@xxxxxxxxx]
> Sent: Wednesday, August 22, 2012 10:11 AM
> To: Kreinovich, Vladik
> Subject: RE: Motion P1788/M0036.03:Flavors Vote NO
>
> This is probably carry-over form IEEE FP Std 754-1985, and I copied this from that standard:
>
> shall: The use of the word shall signifies that which is obligatory in any conforming implementation.
>
> should: The use of the word should signifies that which is strongly recommended as being in keeping with the intent of the standard, although architectural or other constraints beyond the scope of this standard may on occasion render the recommendations impractical.
Begin forwarded message:
> From: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0036.03: NO Flavors
> Date: August 23, 2012 7:13:49 AM CDT
> To: "'stds-1788@xxxxxxxxxxxxxxxxx'" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> In the last days Jürgen and I discussed a lot about flavors and both of us came to the decision mentioned in Jürgens mail.
>
> Hence I vote no on Motion 36.
>
> Best regards
>
> Marco
Begin forwarded message:
> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0036.03: YES
> Date: August 23, 2012 8:11:21 AM CDT
> To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>
> I vote yes.
>
> Rationale:
>
> Besides this motion, P1788 seems to me not to be on track for a progressive
> standard, but rather a track that will make Kaucher/modal arithmetic
> non-conforming. To include Kaucher/modal intervals at a later time would
> then require invalidating the future 1788 standard, which is unlikely. So
> the precedent would be set for competing standards, and intervallers in both
> industry and academia will be developing incompatible interval applications.
> Some people have suggested they fear running out of time if considering the
> possibility of this motion, but in my view the aforementioned outcome would
> be a much bigger failure.
>
> Nate Hayes
> Sunfish Studio, LLC
Begin forwarded message:
> From: "Joel C. Salomon" <joelcsalomon@xxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03: YES
> Date: August 23, 2012 9:19:43 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>
> On Thu, Aug 23, 2012 at 9:11 AM, Nate Hayes <nh@xxxxxxxxxxxxxxxxx> wrote:
>> Besides this motion, P1788 seems to me not to be on track for a progressive
>> standard, but rather a track that will make Kaucher/modal arithmetic
>> non-conforming. To include Kaucher/modal intervals at a later time would
>> then require invalidating the future 1788 standard, which is unlikely. So
>> the precedent would be set for competing standards, and intervallers in both
>> industry and academia will be developing incompatible interval applications.
>> Some people have suggested they fear running out of time if considering the
>> possibility of this motion, but in my view the aforementioned outcome would
>> be a much bigger failure.
>
> I'm not a voting member of this group, but I'm coming out of lurk-mode
> to weigh in on this.
>
> It may be that for time constraints, P1788 needs to go to
> standardization with only set-based intervals defined. That would be
> alright if there were room for a revision that included other flavors.
> (Consider the large revision to 754 that was needed to accommodate
> decimal -- but if we need to interface to Martian computers that use
> base-17, a future revision would be relatively simple.)
>
> I think Nate has the right of this issue: Even if only one flavor is
> defined this time around, the concept needs to be in the standard.
>
> --Joel Salomon
Begin forwarded message:
> From: Chenyi Hu <chu@xxxxxxx>
> Subject: Re: PLEASE VOTE: Motion P1788/M0036.03:Flavors - voting period begins
> Date: August 24, 2012 9:37:40 AM CDT
> To: <rbk@xxxxxxxxxxxxx>
> Cc: George Corliss <george.corliss@xxxxxxxxxxxxx>
>
> Hi Baker,
>
> Would it be possible to include the flavors as journal of development as our Interval BLAS in the BLAST standard http://www.netlib.org/blas/blast-forum/? I am not sure if a journal of development is permissible in an IEEE standard.
>
> Seems to me M0036.03 allows anyone of the flavors (though each one has its merit). This defeats the purpose of a standard.
>
> Thanks,
>
> -Chenyi
>
Begin forwarded message:
> From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03:Flavors Yes
> Date: August 24, 2012 5:31:11 PM CDT
> To: John Pryce <j.d.pryce@xxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 36 is YES.
>
> I had given up on 1788 before I just learned of this motion.
>
> Bill Walster
Begin forwarded message:
> From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03:Flavors Yes
> Date: August 24, 2012 10:10:21 PM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
>
>
> Your welcome, George.
>
> At least now there is a possibility of a mathematically well founded option based on mathematically well-defined csets, which is not the case at present. :)
>
> Cheers,
>
> Bill
Begin forwarded message:
> From: Dmitry Nadezhin <dmitry.nadezhin@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03:Flavors - voting period begins YES
> Date: August 25, 2012 11:45:34 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES for the motion 36.3 .
>
> It defines principles of common part of the standard.
> So flavour documents will be similar in style.
>
> Also it splits work on set-based intervals, on modal intervals on cset interval into parallel discussion threads.
> I hope that we will be less distracted from the work on the set-based flavour if this motion passes.
>
> -Dima
Begin forwarded message:
> From: Frédéric Goualard <Frederic.Goualard@xxxxxxxxxxxxxx>
> Subject: Motion P1788/M0036.03: NO
> Date: August 28, 2012 2:50:54 AM CDT
> To: "stds-1788@xxxxxxxxxxxxxxxxx" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I vote NO on motion P1788/M0036.03 for the same reasons as Dr.
> Lefevre, Pr. Gudenberg and others.
>
> FG.
> - --
> Frédéric Goualard LINA - UMR CNRS 6241
Begin forwarded message:
> From: "Neher, Markus (IANM) [IANM bezeichnet die Organisationseinheit Institut für Angewandte und Numerische Mathematik]" <markus.neher@xxxxxxx>
> Subject: Motion 36.03: NO
> Date: August 28, 2012 3:44:17 AM CDT
> To: "stds-1788@xxxxxxxxxxxxxxxxx" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 36.03 is NO for the same reasons as Prof. Gudenberg and others.
>
> This is a tough decision, because John has done a lot of excellent work to include for example Kaucher intervals, which I do not want to discourage. Furthermore, I agree with Nate Hayes:
>
> > To include Kaucher/modal intervals at a later time would
> > then require invalidating the future 1788 standard, which is unlikely.
>
> However, I think that the current standard is already complicated even without flavours. My general concern is that if some 100 experts on interval arithmetic can not agree on a simple and unambiguous definition of its basic arithmetic operations, this standard will never be adopted. If Motion 36.03 passes, I'm already looking forward to someone splitting flavors into major aromas and minor scents.
>
> Best regards,
>
> Markus
Begin forwarded message:
> From: Stefan Siegel <St.Siegel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0036.03: NO
> Date: August 28, 2012 6:54:29 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO with the same rasons as Jürgen, Dr. Lefevre and others...
>
> Best regards,
>
> Stefan
Begin forwarded message:
> From: Michel Hack <mhack@xxxxxxx>
> Subject: Motion P1788/M0036.03:Flavors - YES
> Date: August 28, 2012 7:25:48 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on Motion 36.
>
> The argument that we can always deal with this issue later
> does not work, because it would INVALIDATE a standard that
> does not allow for the possibility of multiple flavours.
>
> This is different from the addition of DFP to IEEE 754.
> None of the properties of BFP defined in 754-2008 were
> invalidated; some were strengthened (should -> shall),
> and some requirements were dropped (trap specifications
> for wrapped exponents), but other improvements (such as
> unifying NaN treatment) had to be phrased as SHOULD to
> avoid invalidating the old standard.
>
> Motion 36 does not require that multiple flavours be supported.
> It only provides a framework for doing so. The fact that modal
> intervals may not (in some work group member's opinions) be ready
> for prime time would then NOT delay the standardization of the
> flavour that has the widest support and most solid foundation (in
> some opinions) in reasonable time.
>
> Some have suggested that the Motion 3 interval flavour be required.
> I don't think that it necessary. If and when, say, a modal flavour
> will have been formulated in a manner that allows it to be included
> in the standard, a vendor who is only interested in that flavour
> would not be able to provide a conforming implementation without
> doing the extra work of providing also a full second flavour.
>
> There was also (primarily offline) a detailed discussion of the
> interactions between different flavours, and the possibility that
> even different types might be treated as different flavours --
> sort of getting into the perfume business brought up by Dima. In
> my opinion the primary utility of flavours is that it allows ONE
> flavour to be available in a standard form for a program to exploit.
> It would be a DIFFERENT program that takes advantage of another
> flavour. The mechanism for supporting multiple flavours in one
> program should be there to allow specialised interface programs to
> be written in a portable and standard-conforming manner. Yes, some
> programmers may be able to exploit multiple flavours (when available
> in an integrated manner in some environment) for interesting effects,
> but the main application of the standard will be for single-flavour
> programs.
>
> Michel.
Begin forwarded message:
> From: Ulrich Kulisch <ulrich.kulisch@xxxxxxx>
> Subject: Motion 36.03: Flavors No
> Date: August 25, 2012 10:30:42 AM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on motion 36.03 is No.
> I would vote Yes if the number of flavours and the time for presenting a flavour would be limited.
>
> Rationale:
> What the scientific computing community primarily expects from P1788 is a standard on set based intervals, i.e., on closed (bounded and unbounded) real intervals of IR and \overline{IR}. I appreciate the goal keeping the standard open for possible extensions. But there is no need keeping it open for all kinds of (exotic) extensions.
>
> Flavours on unbounded intervals, on wrap around intervals, or on cset intervals would seriously devaluate the set based part of the standard on which agreement is already available.
>
> The only sensible extension many P1788 members see is Kaucher/modal arithmetic. If their proponents do not present a simple and acceptable motion until the end of this year IEEE P1788 should be finished without it immediately.
>
> Ulrich Kulisch
egin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Re: Motion 36.03: Flavors No
> Date: August 29, 2012 2:43:58 AM CDT
> To: Ulrich Kulisch <ulrich.kulisch@xxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Ulrich and P1788
>
> On 25 Aug 2012, at 16:30, Ulrich Kulisch wrote:
>> My vote on motion 36.03 is No.
>> I would vote Yes if the number of flavours and the time for presenting a flavour would be limited.
>>
>> Rationale:
>> What the scientific computing community primarily expects from P1788 is a standard on set based intervals, i.e., on closed (bounded and unbounded) real intervals of IR and \overline{IR}. I appreciate the goal keeping the standard open for possible extensions. But there is no need keeping it open for all kinds of (exotic) extensions.
>
> The time for presenting a flavour this time around will be limited. There will be a deadline in 2013 which I expect Baker and Nathalie will set shortly.
>
> I propose the process for accepting a new flavour in the future be essentially the same as for accepting a journal paper:
> - Ongoing 1788 committee to be set up, including an editorial board.
> - Any new flavour document to be sent to editorial board and peer-reviewed
> according to suitable criteria: e.g. mathematical soundness plus usefulness
> in applications.
>
> This is NOT a free-for all.
>
> I hope the Kaucher/modal group get on with their document, meantime I aim to work with Christian Keil on the set-based one.
>
> John Pryce
Begin forwarded message:
> From: Günter Mayer <guenter.mayer@xxxxxxxxxxxxxx>
> Subject: Motion 36.03: NO
> Date: August 29, 2012 6:22:59 AM CDT
> To: "stds-1788@xxxxxxxxxxxxxxxxx" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 36.03 is NO for the same reasons as Prof. Dr. Wolff von Gudenberg and others.
>
> Best wishes,
>
> Guenter Mayer
Begin forwarded message:
> From: <skalna@xxxxxxxxxx>
> Subject: Motion P1788/M0036.03:Flavors
> Date: August 29, 2012 4:10:25 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 36.03 is NO for the same reasons as Prof. Gudenberg and others.
>
> Best regards,
> Iwona Skalna
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: My reasoning, was: Re: I vote NO on motion 36.03...
> Date: August 31, 2012 8:30:42 AM CDT
> To: John Pryce <j.d.pryce@xxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
>> Subject: Re: I vote NO on motion 36.03...
>> From: John Pryce <j.d.pryce@xxxxxxxxxx>
>> Date: Fri, 31 Aug 2012 09:42:04 +0100
>> Cc: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
>> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>>
>> Dan and P1788
>>
>> On 28 Aug 2012, at 14:45, Dan Zuras Intervals wrote:
>>> I vote NO on this motion.
>> ...
>>> We are voting on THIS standard not some future one
>>> that might come to exist if it can be made of those
>>> who can agree more than we. After all, WE are the
>>> experts & would also be on that committee.
>>>
>>> If this motion should fail, please take that as
>>> increased pressure to agree on some sort of Kaucher
>>> or modal proposal. If not, don't worry about it.
>>> Including such intervals at any time invalidates
>>> nothing about this standard.
>>>
>>> While John has created an excellent framework to
>>> discuss things such as "flavors", that discussion
>>> is something we should have now not at some future
>>> time. His work is not wasted no matter how this
>>> motion goes.
>>
>> I thank you for your praise for my framework, but please would you clarify
>> what you think should be done? To me your words read like
>>
>> "We risk running out of time. So reject motion 36 and get back to discussing
>> how we might agree to unify set-based and Kaucher in one system. Never mind
>> that we have gone round in circles trying to agree this for over a year."
>>
>> (BTW I am now using "Kaucher" instead of "modal" after seeing that Alexandre
>> Goldszteijn's work, which seems a solid theoretical basis, uses Kaucher
>> intervals as its basic definition.)
>>
>> Or does your "If not, don't worry about it" mean that you are thinking long
>> term? I.e. we can put a Kaucher (or modal) sub-document in an informative
>> Annex, and do the same to my flavors, with the aim of making them mandatory
>> in future when we have validated the ideas thoroughly in theory and practice?
>>
>> What do other people think?
>>
>> John Pryce
>
>
> John,
>
> I thought about explaining myself to you when I heard your
> voice at the MSC meeting. Alas, it went so fast I had no
> time. Or, perhaps, courage to waste the MSC's time.
>
> You think of this motion as like adding decimal to 754. As
> did I, at least initially. Adding decimal was a good idea &
> one we all thought would improve the standard. I believe it
> ultimately cost us maybe a year or a year & a half but in the
> end it was worth it. 754 is a better document when stated in
> a radix independent way than in binary. (Well, with r = 2 or
> 10 anyway. :-) Many things that just went by the wayside in
> the 1985 document were exposed by that description. For
> example, the distinction between a bit & its representation in
> a number format. As binary guys, it took us some time to wrap
> our heads around this but it was time well spent, IMHO.
>
> Then, as I thought about it some more, another interpretation
> occurred to me. That of the distinction between BID & DPD.
>
> This was first raised in our context by Michel in the
> following note which I quote here in its entirety:
>
>> Date: Thu, 30 Aug 2012 10:45:00 -0400
>> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>> From: Michel Hack <mhack@xxxxxxx>
>> Subject: Re: Motion P1788/M0036.03: NO Flavors (a comment, not a vote)
>>
>> John Pryce wrote:
>>> In fact the comparison seems to me to be very close. Binary and
>>> decimal are the two "flavors" of 754 arithmetic!
>>
>> One difference is that 1788 flavors propose a "constant attibute",
>> whereas the 754-2008 radix is more like a type attribute carried
>> by each datum. (There is a radix(datum) required function; we did
>> not propose a flavor(interval) function -- only a currentFlavor()
>> environmental function.)
>>
>> Languages have indeed implemented the BFP vs DFP distinction via
>> different types, though I suspect a language that makes the DFP/BFP
>> distinction flavor-like is possible; indeed, pre-DFP C could be
>> described this way (the radix of K&S C "float" or "double" could be
>> anything).
>>
>> The 754-2008 decimal encoding flavors (BID/DPD) provide a closer analogy.
>>
>> Even closer is the distinction between BFP and HFP, or Ebcdic vs Ascii,
>> encountered in situations where both alternatives can coexist on one
>> platform, e.g. IBM's Z-series. On IBM's P-series there are two different
>> flavors of "long double", as I believe there are on Intel/HP Itanium. In
>> each case the distinction is based on compiler options or pragmas, and
>> there are macros to enquire about the current flavor.
>>
>> Michel.
>
> You see, Michel was present during the time we considered all
> this for 754. Historically, we were initially going with the
> DPD representation for decimal. It was an intensely clever
> method of encoding decimal information which we had worked out
> over the years to fit into our context. Then along came Intel.
>
> You see, it seemed that Intel had been working on their own
> version of decimal for some time before the rest of us heard
> anything about it. By the time they informed us of it (near
> the end of our work) they had worked out an equally clever
> method of doing decimal on their binary engines in software
> so long as they were free to represent the information in
> their own way. They called this BID. And they proposed it
> to us as THEIR way to represent decimal numbers. Well, it
> caused a big stir.
>
> I mean a REALLY big stir.
>
> As we were walking to dinner after the meeting I told the
> Intel guy I wish he were an idiot. To which he asked why.
> I replied that if he were an idiot I could ignore this new
> proposal & get back to finishing 754. But he was NOT an
> idiot & his proposal, as late as it was, had merit. (I did
> NOT tell him that being from Intel gave him some clout in
> the matter. Nor that IBM had since made their hardware
> based on DPD & would not likely be willing to change at
> this late date.)
>
> Well, the committee split on the matter so much so that all
> our time was taken up with it from that point on. So much
> so that I declared us to be deadlocked on the matter & went
> to suspend subsequent meetings. (It was a ploy on my part
> to get Intel & IBM to agree on a format. A ploy that mostly
> didn't work & almost got me removed from the chair. But the
> IEEE backed me on it & I thank them for that.)
>
> As it happened, the ploy worked to the extent that both IBM
> & Intel agreed to have both formats in the standard. (You
> see, I felt that Intel could live with the DPD format but,
> as I ordered them to just agree on anything, I had to live
> with the result.)
>
> So 754 has two ways of representing decimal numbers. They
> are entirely different & have only a few bits in common but
> they are both there & both represent the same set of numbers.
>
> And yet, I feel the standard is less for it. It took us
> another 6 months or so to cram BID into the text equally
> along side DPD. And, while we haven't yet had anyone
> complain about it yet I'm sure it will cause nothing but
> trouble in the future.
>
> And, John, THIS is mostly why I voted against this motion.
> I fear that we will go off into a pointless discussion that
> has no real bearing on how intervals should behave that may
> cost us the standard itself.
>
> But I acknowledge that I may be wrong. On the one hand, it
> may be more like binary versus decimal &, while taking us
> some time, will make for a better standard. On the other
> hand, the motion seems to be passing in spite of my
> objection so I may end up being moot. (This is what I meant
> when I said, "Don't worry about it." Kaucher intervals
> invalidate nothing about the rest of the standard, IMHO.)
>
> That & the fact that your "flavors" are a clever way to
> attack the problem means I have no REAL objection to them
> should they come to exist. You have written them well
> enough that they should guide us to a solution should we
> need to go that way.
>
> Or, we could, as Bob mentioned at the MSC meeting, put the
> Kaucher stuff in an informative annex with the view to
> making that annex necessary in the future. If we are
> careful, that would work but, frankly, I like flavors
> better.
>
> I hope this clarifies my position well enough. Perhaps I
> should have voted "yes" on it. But I feel I can write up
> more on something that I vote "no" on than those that I
> approve of. It is not a great motivation but, then again,
> I DID say I had only a poor motivation for disapproval.
>
> I still only have that. Sorry about that.
>
> Yours,
>
> Dan
Begin forwarded message:
> From: "J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0036.03: NO Flavors
> Date: August 23, 2012 5:38:18 AM CDT
> To: "'stds-1788@xxxxxxxxxxxxxxxxx'" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear p1788
>
> I vote NO on motion 36 flavors.
>
> I appreciate very much the way how John is trying to keep everybody aboard.
> I like the idea of getting a better enclosure by modal arithmetic
> I see the importance of Kaucher intervals in algebraic extensions
>
> BUT
>
> We are preparing a standard, which should (and will) be progressive.
> As a standard P1788 has to fix or prescribe the rules for One flavor of intervals
> and NOT open up new alternatives.
>
> My second concern is the time.
> Those who favor modal arithmetic, may argue that 2 flavors are better
> I do not think we can manage to include this second flavor in our remaining time.
> BTW nobody has shown up to do the job of a technical editor for modal arithmetic.
>
> The key issue, however, is not HOW we include Kaucher arithmetic but IF.
> That should be clear before ways of inclusion are discussed.
>
> Hence, if there will be a decision to include Kaucher intervals, I will vote for flavors.
> I, indeed, think P1788 in its first version shall be for set-based intervals (motion 3) only.
>
> Juergen
Begin forwarded message:
> From: Alexandre Goldsztejn <alexandre.goldsztejn@xxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03: NO Flavors
> Date: August 23, 2012 5:52:11 AM CDT
> To: "J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Cc: "stds-1788@xxxxxxxxxxxxxxxxx" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote no, with the same arguments as Professor Gudenberg.
>
> Alexandre Goldsztejn
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03: NO Flavors
> Date: August 28, 2012 2:21:07 AM CDT
> To: "stds-1788@xxxxxxxxxxxxxxxxx" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2012-08-23 12:52:11 +0200, Alexandre Goldsztejn wrote:
>> I vote no, with the same arguments as Professor Gudenberg.
>
> I also vote NO on Motion 36.03.
>
> This problem is complex (discussions, partly in private, have shown
> some issues, and there may still be hidden ones), thus flavors should
> be based on an implementation before they could be standardized.
>
> The idea of flavors came too late, and IMHO, there isn't enough time
> to include them in the standard and carefully check everything. And
> more generally I agree with Prof. Gudenberg.
>
> Flavors could be a goal of the first revision of the standard (like
> how decimal arithmetic was introduced in IEEE 754).
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Dominique Lohez <dominique.lohez@xxxxxxx>
> Subject: Re: Motion P1788/M0036.03: NO Flavors
> Date: August 29, 2012 10:37:24 AM CDT
> To: "J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Cc: "'stds-1788@xxxxxxxxxxxxxxxxx'" <stds-1788@xxxxxxxxxxxxxxxxx>
>
> J. Wolff von Gudenberg a écrit :
>> Dear p1788
>>
>> I vote NO on motion 36 flavors.
>>
>> I appreciate very much the way how John is trying to keep everybody aboard.
>> I like the idea of getting a better enclosure by modal arithmetic
>> I see the importance of Kaucher intervals in algebraic extensions
>>
>> BUT
>>
>> We are preparing a standard, which should (and will) be progressive.
>> As a standard P1788 has to fix or prescribe the rules for One flavor of intervals
>> and NOT open up new alternatives.
>>
> I completely agree with the statement that we must not build a standard with alternatives.
>
> My opinion is that modal interval should be be introduced as an optional recommended extension of intervals defined
> by motion 3.
>
> Thus the job is already done.
>
> Thus one only add a paragraph on the behavior of improper modal intervals.
>
>
> Sincerely
>
> Dominique
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03: NO Flavors
> Date: August 30, 2012 9:07:37 AM CDT
> To: Dominique Lohez <dominique.lohez@xxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dominique
>
> On 29 Aug 2012, at 16:37, Dominique Lohez wrote:
>> J. Wolff von Gudenberg a écrit :
>>> I vote NO on motion 36 flavors.
>>>
>>> I appreciate very much the way how John is trying to keep everybody aboard.
>>> I like the idea of getting a better enclosure by modal arithmetic
>>> I see the importance of Kaucher intervals in algebraic extensions
>>>
>>> BUT
>>>
>>> We are preparing a standard, which should (and will) be progressive.
>>> As a standard P1788 has to fix or prescribe the rules for One flavor of intervals
>>> and NOT open up new alternatives.
>>>
>> I completely agree with the statement that we must not build a standard with alternatives.
>
> I completely reject this line of argument. It's like saying IEEE754 should not have the "alternatives" of binary and decimal arithmetic.
>
> In fact the comparison seems to me to be very close. Binary and decimal are the two "flavors" of 754 arithmetic!
>
> If you say "the interval flavor concept is premature, we haven't time to validate it", that's a valid argument (though I disagree).
>
> If you say "90% of interval workers use set-based intervals so standardise on that", that's a valid argument too, though if you asked where 90% of dollars earned by interval algorithms came from, the answer would likely be different, as we know.
>
> But to say a standard should not cater for alternatives simply doesn't hold water.
>
> John Pryce
Begin forwarded message:
> From: Michel Hack <mhack@xxxxxxx>
> Subject: Re: Motion P1788/M0036.03: NO Flavors (a comment, not a vote)
> Date: August 30, 2012 9:45:00 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> John Pryce wrote:
>> In fact the comparison seems to me to be very close. Binary and
>> decimal are the two "flavors" of 754 arithmetic!
>
> One difference is that 1788 flavors propose a "constant attibute",
> whereas the 754-2008 radix is more like a type attribute carried
> by each datum. (There is a radix(datum) required function; we did
> not propose a flavor(interval) function -- only a currentFlavor()
> environmental function.)
>
> Languages have indeed implemented the BFP vs DFP distinction via
> different types, though I suspect a language that makes the DFP/BFP
> distinction flavor-like is possible; indeed, pre-DFP C could be
> described this way (the radix of K&S C "float" or "double" could be
> anything).
>
> The 754-2008 decimal encoding flavors (BID/DPD) provide a closer analogy.
>
> Even closer is the distinction between BFP and HFP, or Ebcdic vs Ascii,
> encountered in situations where both alternatives can coexist on one
> platform, e.g. IBM's Z-series. On IBM's P-series there are two different
> flavors of "long double", as I believe there are on Intel/HP Itanium. In
> each case the distinction is based on compiler options or pragmas, and
> there are macros to enquire about the current flavor.
>
> Michel.
Begin forwarded message:
> From: Dominique Lohez <dominique.lohez@xxxxxxx>
> Subject: Re: Motion P1788/M0036.03: NO Flavors
> Date: August 30, 2012 10:35:25 AM CDT
> To: John Pryce <j.d.pryce@xxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> John Pryce a écrit :
>> Dominique
>>
>> On 29 Aug 2012, at 16:37, Dominique Lohez wrote:
>>
>>> J. Wolff von Gudenberg a écrit :
>>>
>>>> I vote NO on motion 36 flavors.
>>>>
>>>> I appreciate very much the way how John is trying to keep everybody aboard.
>>>> I like the idea of getting a better enclosure by modal arithmetic
>>>> I see the importance of Kaucher intervals in algebraic extensions
>>>>
>>>> BUT
>>>>
>>>> We are preparing a standard, which should (and will) be progressive.
>>>> As a standard P1788 has to fix or prescribe the rules for One flavor of intervals
>>>> and NOT open up new alternatives.
>>>>
>>>>
>>> I completely agree with the statement that we must not build a standard with alternatives.
>>>
>>
>> I completely reject this line of argument. It's like saying IEEE754 should not have the "alternatives" of binary and decimal arithmetic.
>>
> John,
>
> IMHO the right comparison would between natural numbers and relative number.
> This hold because new result can be obtained as shown by Nate.
> Then you do not have to build alternative between natural number and relative numbers
>
> Dominique LOHEZ
>
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03: NO Flavors
> Date: August 31, 2012 9:09:07 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2012-08-30 17:35:25 +0200, Dominique Lohez wrote:
>> IMHO the right comparison would between natural numbers and relative
>> number.
>
> Yes, in C, one has signed and unsigned integer arithmetics. For
> some types, the "flavor" is explicit, but for other types and
> for some intermediate results (e.g. when adding an unsigned int
> and a long), this depends on the implementation.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: I vote NO on motion 36.03...
> Date: August 28, 2012 8:45:39 AM CDT
> To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
> Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
> Folks,
>
> I vote NO on this motion.
>
> My reasons are largely along the lines of Ulrich's
> arguments, although from a different perspective.
>
> We are voting on THIS standard not some future one
> that might come to exist if it can be made of those
> who can agree more than we. After all, WE are the
> experts & would also be on that committee.
>
> If this motion should fail, please take that as
> increased pressure to agree on some sort of Kaucher
> or modal proposal. If not, don't worry about it.
> Including such intervals at any time invalidates
> nothing about this standard.
>
> While John has created an excellent framework to
> discuss things such as "flavors", that discussion
> is something we should have now not at some future
> time. His work is not wasted no matter how this
> motion goes.
>
> Let's take advantage of that.
>
> If we can...
>
>
> Dan
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Re: I vote NO on motion 36.03...
> Date: August 31, 2012 3:42:04 AM CDT
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Cc: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> Dan and P1788
>
> On 28 Aug 2012, at 14:45, Dan Zuras Intervals wrote:
>> I vote NO on this motion.
> ...
>> We are voting on THIS standard not some future one
>> that might come to exist if it can be made of those
>> who can agree more than we. After all, WE are the
>> experts & would also be on that committee.
>>
>> If this motion should fail, please take that as
>> increased pressure to agree on some sort of Kaucher
>> or modal proposal. If not, don't worry about it.
>> Including such intervals at any time invalidates
>> nothing about this standard.
>>
>> While John has created an excellent framework to
>> discuss things such as "flavors", that discussion
>> is something we should have now not at some future
>> time. His work is not wasted no matter how this
>> motion goes.
>
> I thank you for your praise for my framework, but please would you clarify what you think should be done? To me your words read like
>
> "We risk running out of time. So reject motion 36 and get back to discussing how we might agree to unify set-based and Kaucher in one system. Never mind that we have gone round in circles trying to agree this for over a year."
>
> (BTW I am now using "Kaucher" instead of "modal" after seeing that Alexandre Goldszteijn's work, which seems a solid theoretical basis, uses Kaucher intervals as its basic definition.)
>
> Or does your "If not, don't worry about it" mean that you are thinking long term? I.e. we can put a Kaucher (or modal) sub-document in an informative Annex, and do the same to my flavors, with the aim of making them mandatory in future when we have validated the ideas thoroughly in theory and practice?
>
> What do other people think?
>
> John Pryce
Begin forwarded message:
> From: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Subject: RE: I vote NO on motion 36.03...
> Date: August 31, 2012 8:57:18 AM CDT
> To: 'John Pryce' <j.d.pryce@xxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Cc: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
>
> I read their message as saying let us include only usual (set-theoretic) intervals and leave everything else as a vaguely described option. If there is time to develop Kaucher/modal option fast let us do it, otherwise let us not.
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Subject: Re: time limits; this vs a future standard
> Date: August 31, 2012 10:53:47 AM CDT
> To: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Cc: 'John Pryce' <j.d.pryce@xxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>, stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> Another option suggested at the MSC teleconference
> yesterday when I brought it up was to put items
> that cannot be put into standards-quality
> by the agreed upon time into an informative
> (that is, non-normative) but carefully worded
> appendix. The idea is that developers can see the
> intent of including the items in a future revision
> of the standard, but the items don't need to be
> included for conformance to the present standard.
> This mechanism may increase the likelihood that
> we deliver the document before the end of the
> PAR authorization term.
>
> I mention this here as a possibility, without
> stating precisely what should be in any such appendix.
>
> Baker
Begin forwarded message:
> From: Rudnei Cunha <rudnei.cunha@xxxxxxxxx>
> Subject: Re: I vote NO on motion 36.03...
> Date: August 31, 2012 12:57:05 PM CDT
> To: John Pryce <j.d.pryce@xxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear colleagues,
> I fear we may be losing track attempting to cover many different ideas on the same standard. It seems to me, from the discussions, that at this point we may not be able to accomodate these ideas in a single proposal.
>
> I would favour a minimal yet extendable approach, with normative (minimal) and non-normative (extensions) texts. This way, we may go forward, in time, while at the same time achieving a reasonable compromise for the future. Once the standard is accepted and people start using actual implementations, we will be able to build upon version 1.0 of the standard.
>
> Hope it helps!
> Rudnei
>
Begin forwarded message:
> From: Jose antonio Muñoz lopez <naramuno@xxxxxxxxxx>
> Subject: Motion P1788/M0036.03:Flavors Yes
> Date: September 2, 2012 5:48:23 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 36 is YES.
>
> I agree with Corliss, George. Opening the standard other extentions
> make it more rich and workable.
>
> José A. Muñoz
Begin forwarded message:
> From: Walter Kraemer <kraemer@xxxxxxxxxxxxxxxxxxxxx>
> Subject: Motion 36.03: NO
> Date: September 4, 2012 2:46:20 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
> My vote on Motion 36.03 is NO for the same reasons as Prof. Dr. Wolff
> von Gudenberg and others.
>
> Best wishes, Walter
Begin forwarded message:
> From: Pipop T. <pipopt@xxxxxxxxx>
> Subject: Motion 36.03: NO
> Date: September 4, 2012 3:44:44 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on Motion 36.03 with the same reasons as Professor Gudenberg.
Begin forwarded message:
> From: Svetoslav Markov <smarkov@xxxxxxxxxx>
> Subject: Motion 36.03: NO
> Date: September 4, 2012 8:40:56 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 36.03 is NO for some
> reasons noted by Ulrich Kulisch and Dan Zuras.
> I would vote yes if no other extensions
> to classical intervals are allowed apart of
> Kaucher/modal arithmetic.
>
> Best wishes, Svetoslav
Begin forwarded message:
> From: Andreas Rauh <andreas.rauh@xxxxxxxxxxxxxx>
> Subject: Motion P1788/M0036.03:Flavors Yes
> Date: September 6, 2012 4:35:02 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear colleagues,
>
> my vote is YES, under the assumption that the main goal of this working group is still to get a (hopefully widely) accepted standard in due time.
>
> Best regards,
> Andreas
>
>
> --
> Dr.-Ing. Andreas Rauh
Begin forwarded message:
> From: Jean-Pierre Merlet <Jean-Pierre.Merlet@xxxxxxxx>
> Subject: M0036.03 Flavors and standard invalidation: NO
> Date: September 6, 2012 3:33:00 PM CDT
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Reply-To: <Jean-Pierre.Merlet@xxxxxxxx>
>
> I vote NO: although decoration will be useful it's a very complex problem which goes well beyond interval and therefore must be very finely crafted. For sure a lot of good point have been made but we are not yet ready to make that a standard
>
> J-P. Merlet
Begin forwarded message:
> From: Mark Stadtherr <markst@xxxxxx>
> Subject: Motion P1788/M0036.03:Flavors Yes
> Date: September 6, 2012 4:53:23 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <markst@xxxxxx>
>
> My vote on Motion 36.03 is YES. While I share many of the
> concerns expressed by those voting no, I have come to
> accept John Pryce's belief that that passing Motion 36.03
> will not cause significant delay to a set-based standard.
>
> Mark
Begin forwarded message:
> From: "Hanek, Bob" <bob.hanek@xxxxxxxxx>
> Subject: Motion 36.03: NO
> Date: September 7, 2012 8:57:47 AM CDT
> To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
>
> My vote on Motion 36.03 is NO for the same reasons as Prof. Dr. Wolff
> von Gudenberg and others.
>
Begin forwarded message:
> From: Chenyi Hu <chu@xxxxxxx>
> Subject: Motion 36.03: NO
> Date: September 7, 2012 9:13:33 AM CDT
> To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx>
>
> My vote on Motion 36.03 is NO. However, it could be an appropriate appendix item.
>
> >>> "Hanek, Bob" <bob.hanek@xxxxxxxxx> 9/7/2012 8:57 AM >>>
> My vote on Motion 36.03 is NO for the same reasons as Prof. Dr. Wolff
> von Gudenberg and others.
>
Begin forwarded message:
> From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>
> Subject: Motion 36.03: NO
> Date: September 9, 2012 6:31:44 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on Motion 36.03: Flavors.
>
> I have long hesitated whether to vote yes. In the end, I decided that
> flavors were not worth complicating the standard text. Indeed, I doubt
> someone would ever want to write some program that would run whatever
> the current flavor on the target architecture; a given program will
> almost always be written with a specific flavor in mind. In particular,
> Paragraph 7 raises a red flag.
>
> Said otherwise, having a single "addition" and defining its behavior
> depending on flavors feels like a mistake. There isn't a single
> addition, there are as many additions as there are flavors and they
> should all be defined as separate entities (which doesn't prevent to
> factor standard text whenever possible). As a point of comparison,
> IEEE-754r does define as many additions as there are formats (and in
> particular, binary and decimal additions are different beasts) even if
> it uses the generic name "formatOf-addition" (which is to be understood
> as binary32-addition, decimal64-addition, and so on).
>
> Short version: having a common standard supporting various flavors of
> interval arithmetic does not require to artificially merge them all in
> the same mold, hence my vote.
>
> Best regards,
>
> Guillaume
Begin forwarded message:
> From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: I change my vote on Motion P1788/M0036.03 to YES...
> Date: September 9, 2012 5:01:07 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
>
> Folks,
>
> By my count we are one vote away from passing this motion
> & down to hours to do it. Therefore, I will change my vote
> to YES to pass it. My no vote was ill-considered anyway &
> I would not have it fail by my one vote. I believe we need
> something like John's organization if we are to finish in a
> decently short period of time.
>
> Yours,
>
>
> Dan
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Subject: Re: flavors
> Date: September 9, 2012 11:37:07 PM CDT
> To: J.Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Cc: Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx>, Christian Keil <c.keil@xxxxxxxxxxxxx>, George Corliss <George.Corliss@xxxxxxxxxxxxx>, Nathalie Revol <Nathalie.Revol@xxxxxxxxxxx>, Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>, Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> Jürgen
>
> On 20 Aug 2012, at 11:36, J. Wolff von Gudenberg wrote:
>> some thoughts on new flavors in order to prepare the flavor extension motion
>>
>> P1788 is about interval arithmetic in flavor "closed-sets". For better readability as well as better extendability
>> the flavor "closed-bounded-sets" (classical) is also defined
>>
>> Here are some rules to extend p1788 by a new flavor
>>
>> write a proposal containing
>> - an explanation of the intended application
>> - a- specification what is an interval
>> - a description of the differences with the classical or the closed-sets flavor
>> - an FTIA or similar behavior
>>
>> That usually means to define a new level 1
>>
>> The proposal has to be backed by (at least) 3 people from different affiliations
>>
>> submit the proposal to the permanent body called "1788 Review Committee" or similar.
>>
>> That committee will start a peer review by at least 2 referees
>> to check that the contents as well as the wording accord to the standard document
>
> Now it looks as though motion 36 has passed, will you go public on your proposed rules?
>
> John
Begin forwarded message:
> From: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Subject: Motion P1788/M0036.03: Flavors: NO
> Date: September 9, 2012 4:05:34 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion P1788/M0036.03: Flavors is NO.
>
> With any NO vote, I am required to state what would bring me to a "YES."
>
> In most ways, I agree with the spirit of creating a standard that
> allows for a common set of operations, and allows implementations to
> extend that with a "better" set of operations for some purposes and
> boundary cases (e.g. Kaucher intervals, or disjoint unions of intervals,
> or various handlings of infinities, or arbitrary-precision, or symbolic
> calculations.)
>
> I would tend to vote YES for a motion that has been thought through
> more clearly than this one. The rationale paper is muddled, does not
> define terms that it uses, is inconsistent in its terminology (for
> example, it defines "C-opinst" but then in some places uses the term
> "common opinst" which is not clear if it refers to the same term; there
> are many such instances of inconsistent editing,) is not consistent with
> the text of the Motion, has open-ended questions, notes to self that
> indicate that further research is necessary, inconsistent line wrapping
> and notation, and other more fundamental problems.
>
> The text of the Motion does also not even use the same terminology as
> the text of the Rationale. The Motion cannot stand alone (and the text
> of the Motion is what we're ultimately voting on,) the Rationale is not
> self-consistent, and the Motion and Rationale are not consistent with
> each other. These are fundamental editing problems. We need to do
> better. Any time we demand the time of hundreds of busy experts, we
> need to make sure that we've done our job of editing properly. (My
> mantra to myself when composing group e-mails is that "if it's not worth
> my time to edit and format and proofread properly, it's not worth
> people's time to read it." I delete many, many emails without sending
> based on this rule.)
>
> I would strongly suggest that this motion be tabled, edited, and made
> more coherent, in which case it might find more enthusiastic adherents.
> A rationale paper should make its argument persuasively. The current
> rationale paper does not inspire confidence.
>
> As I have noted before, I am concerned that this standardization
> effort is not paying enough consideration to "better" interval
> implementations, including those that may include rational numbers,
> arbitrary-precision numbers, symbolic constants (such as pi or e,) and
> so on. The open-ended questions in the rationale paper do not give me
> confidence that these issues have been properly considered. Is
> arbitrary-precision or symbolic mathematics considered an incompatible
> flavor? Or is it within the aegis of the "common operations?" (These
> are apparently unresolved questions-to-self in the current rationale paper.)
>
> Performance issues also go unaddressed here. The new "COMMON"
> decoration appears to require that every operation in every flavor check
> for this "COMMON" decoration to decide whether they should proceed with
> calculation. This has severe performance implications, especially with
> vectorized calculations. It also isn't at all clear what we do when an
> implementation decides it can't deal with a result that is passed in
> from another incompatible flavor. Throw exceptions? Crash? Return
> wrong results silently? Do all operations now have to return error
> codes in that case? Any motion for separate flavors needs to address if
> we can handle this situation, and how.
>
> I would, in the future, vote in favor of a motion that allows for a
> set of "common" operations, and possibly more "better" implementations,
> but this is not a motion that has been considered enough to incur the
> costs of supporting additional flavors. I would hope that we could get
> a stronger motion and rationale paper that demonstrates the need for
> various flavors. I would like a progressive standard that works for
> more people. However, as history has proven, it may be difficult enough
> to for us to agree on basic operations. The additional cost/benefit
> analysis of supporting multiple flavors has not been adequately
> demonstrated by this motion, and for that reason, I must reluctantly
> vote NO. I may vote YES on a better motion, and I encourage that a
> better motion for such be put forth.
>
> --
> Alan Eliasen
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03: Flavors: NO
> Date: September 9, 2012 1:59:25 PM CDT
> To: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> Alan,
>
> Actually, according to my interpretation of the rules,
> you only need to state what would change your "no" to "yes"
> for voting on the actual standards wording, not on position
> papers. However, it is still a good idea to explain yourself
> even with position papers, and we appreciate it.
>
> Baker
>
> P.S. Hopefully we've got enough solid positions now that
> we can start making headway on the actual document.
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03: Flavors: NO
> Date: September 9, 2012 3:11:05 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2012-09-09 03:05:34 -0600, Alan Eliasen wrote:
>> I would tend to vote YES for a motion that has been thought through
>> more clearly than this one. The rationale paper is muddled, does not
>> define terms that it uses, is inconsistent in its terminology (for
>> example, it defines "C-opinst" but then in some places uses the term
>> "common opinst" which is not clear if it refers to the same term; there
>> are many such instances of inconsistent editing,) is not consistent with
>> the text of the Motion, has open-ended questions, notes to self that
>> indicate that further research is necessary, inconsistent line wrapping
>> and notation, and other more fundamental problems.
>
> Note that purely editorial errors (line wrapping, obvious typos...)
> are not a problem since motions are not standard text, but are
> interpreted by the editors.
>
>> As I have noted before, I am concerned that this standardization
>> effort is not paying enough consideration to "better" interval
>> implementations, including those that may include rational numbers,
>> arbitrary-precision numbers, symbolic constants (such as pi or e,) and
>> so on. The open-ended questions in the rationale paper do not give me
>> confidence that these issues have been properly considered. Is
>> arbitrary-precision or symbolic mathematics considered an incompatible
>> flavor? Or is it within the aegis of the "common operations?" (These
>> are apparently unresolved questions-to-self in the current rationale paper.)
>
> Symbolic constants are real numbers. So, this is unrelated to flavors.
> They can even be supported by inf-sup if F includes such constants
> (since F is *not* necessarily a floating-point format, but can
> include any finite subset of real numbers, this is OK). Supporting
> "all" symbolic constants can be done like multiple-precision.
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Re: Motion P1788/M0036.03: Flavors: NO
> Date: September 9, 2012 11:27:36 PM CDT
> To: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear Alan
>
> I am glad that you have stated so fully the objections you have to motion 36 and its rationale. But ...
>
> There is no Father Christmas writing motions, nor a magic workforce of Elves checking that they are logically correct and consistently worded, etc.
>
> There is only us, the members of the working group. The proposer of each motion must be its Santa Claus. For this motion it was yours truly, Technical Editor, who is at the same time trying to write revised draft text of Level 2 ... and decorations ... and I/O ..., with the help of Christian Keil, the other TE, who does what he can while holding down a full time job. (Post retirement, I only have to hold down a part time job.) And hopefully we have a life, and family, too.
>
> You, the members of P1788, must be those magic elves. There is no one else.
>
> For this motion, the elves who have helped me improve concepts and wording have been primarily George Corliss, Alexandre Goldszteijn, Michel Hack, Christian Keil, Vincent Lefevre (a big thank-you to him). Thanks also to Juergen and Ulrich for giving reasons why they dislike the whole flavors concept, at this stage of the project. Apologies to those I've missed.
>
> The time for the elves to get busy, is early in the discussion period. An elf who waits till the penultimate day of voting -- and then says what is wrong with the work without detailing what is needed to put it right -- forgoes most of the elves' magic power, and thereby the influence and honour due to him or her.
>
> Alan, I'll bet that many of the things you call inconsistencies are misunderstandings on your part. Vincent has pointed out some, correctly I believe. Will you give me a detailed list of each wrong thing and your proposed correction? Refer, in each instance, to specific sentences, concepts, etc. in the current motion and rationale, so we can get our teeth into your objections.
>
> You may convince us an improved flavors motion is needed. Will you submit it and pilot it through submission and discussion to a vote? You are well placed to give us a broader perspective, thanks to your knowledge of, and concern for, exact real computing. Your reward will be due influence and honour. The cost to you will be to spend the time needed to broaden your own perspective.
>
> If not you, now, then who, when?
>
> Regards
>
> John Pryce
Begin forwarded message:
> From: Lee Winter <lee.j.i.winter@xxxxxxxxx>
> Subject: Re: P1788: Motion 36 Flavors
> Date: September 10, 2012 3:03:05 AM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
> I vote NO.
>
> The current version of flavors is not KISS. When it becomes KISS I
> would vote for it.
>
> Lee Winter