My reasoning, was: Re: I vote NO on motion 36.03...
> 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