Re: Do I have a second? (Motion to not support mid-rad
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: <rbk@xxxxxxxxxxxx>,
> "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: "Arnold Neumaier" <Arnold.Neumaier@xxxxxxxxxxxx>,
> <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Do I have a second? (Motion to not support mid-rad
> Date: Tue, 14 Sep 2010 09:54:37 -0500
>
> I second.
>
> Nate Hayes
Thank you Nate.
I guess this puts us in the discussion phase so let
me clarify as I see it.
>
>
> P.S. I agree with Baker the motion is a bit ambiguous and
> needs some clarification during the discussion phase.
> I also believe if this motion passes that the title of
> this working group needs to change.
One step at a time.
One step at a time. :-)
(BTW, changing the title of either the standard or
the working group has PAR implications. We can do
it but we have to get the IEEE involved when we do.)
>
>
>
>
> ----- Original Message -----
> From: "Ralph Baker Kearfott" <rbk@xxxxxxxxxxxx>
> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: "Arnold Neumaier" <Arnold.Neumaier@xxxxxxxxxxxx>;
> <stds-1788@xxxxxxxxxxxxxxxxx>
> Sent: Tuesday, September 14, 2010 9:04 AM
> Subject: Do I have a second? (Motion to not support mid-rad
>
>
> > P-1788:
> >
> > Arnold Neumaier and Dan Zuras have jointly put forward the
> > following motion:
> >
> > The standard shall not support a midrad interval format or
> > > nonstandard intervals, beyond providing conversion support,
> > > approximately to the extent specified in the Vienna Proposal.
> > >
> >
> > Do I have a second?
> >
> > Baker
> >
> > P.S. I'm wondering precisely what "support" means here. Perhaps,
> > if the motion is seconded, that could be clarified during the
> > discussion. (I'm assuming it means explicitly specifying the
> > behavior of mid/rad operations.)
> >
> > P.P.S. The voting period for Motion 19 is continuing.
> >
> > --
> >
> > ---------------------------------------------------------------
> > R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
I believe you are both correct. The notion of 'support'
here is ambiguous.
The motion itself is unusual but not without precedent.
The motion states that a conforming implementation
shall NOT do something in order to conform. That is,
an otherwise conforming implementation could lose
that status if it chooses to do something extra.
<begin old war story>
An analogy from the floating-point world comes from
Cray.
Cray existed prior to 754. Like everyone else at the
time, they rolled their own when it came to floating-
point. Needless to say it had some interesting
properties. Let me concentrate on just a few.
Their equivalent to our double was a 64-bit datatype
they called single. (They came from Minnesota but
they thought like Texans. :-) It had a 56-bit
mantissa & a 7 bit exponent (with one bit for sign).
But when they multiplied two such numbers together
they only computed 48 bits of the result on the
grounds that Seymour wanted to get rid of the low
24x24 circuit & just use the remaining 3.
As a result of this & booth encoding one side, their
multiplies were not only inaccurate, they had the
property that A*B != B*A.
Then, adds were inexact when they might be exact
due to a lack of a sticky bit.
Finally, their divider (which used a Newton circuit
to approximate x/y by x*(1/y)) suffered from the
problems it inherited from the multiplier. As a
result you found that 18.0/3.0 != 6.0. (When most
of the Pentium designers were still in kindergarten.)
This is all preamble because some time after 754 hit
the streets Cray went to highly parallel commercial
microprocessor based machines which used 754 based
floating-point. (Basically boatloads of overdriven
Intel & AMD chips.)
But, in order to support dusty decks they provided
an 'old Cray' floating-point datatype that allowed
people to do it the old crappy way if they had
coded for it.
Those Crays WITHOUT support for old floating-point
could be considered conforming. WITH that support,
they became non-conforming for all the obvious
reasons.
<end old war story>
So there is precedent for this. It is even a good
analogy. For if Arnold is correct & doing things
in the mid-rad fashion violates even containment
then providing such a capability invalidates all
else that the standard is there to provide.
Therefore, I would say that 'support' in this context
means providing the means to do ANYTHING with a
mid-rad value other than to convert to & from it.
I suppose this puts the library writer into a grey
area. In that if they want to provide a canned
package that works internally in mid-rad but that
they have gone to a lot of trouble to make sure is
correct & containing they must do so in a manner
that never allows anyone to look into the can.
So arithmetic is out. Conversions are in. And
a canned routine could be acceptable under a sort
of don't ask don't tell policy.
That's the way I figure it.
Of course, Arnold can give his own opinion on the
matter.
Does that clarify things?
This decision is a stark one.
I think that is as it should be.
Dan