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