Re: I vote NO on Motion P1788/M0024.02:RoundedOperations
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>,
> "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: I vote NO on Motion P1788/M0024.02:RoundedOperations
> Date: Sun, 15 May 2011 12:29:48 -0500
>
> Dan Zuras wrote:
> >> Dan Zuras wrote:
> >> > Ulrich,
> >> >
> >> > I quote from your motion:
> >> >
> >> > Instead, a future interval arithmetic standard should
> >> > require that EVERY FUTURE PROCESSOR shall provide the
> >> > 16 operations listed above as distinct instructions.
> >> >
> >> > (emphasis yours in bold).
> >>
> >> Dan,
> >>
> >> You are quoting version 1 of the motion from 4/15/2011.
> >>
> >> We are voting on the friendly amedment made by Prof. Kulisch on 4/29/2011
> >> which changed that passage to:
> >>
> >> "The operations with the directed roundings should be implemented
> >> directly
> >> in hardware for efficiency reasons."
> >>
> >> There were also a few other changes based on comments made earlier by
> >> Prof.
> >> Fahmy and others.
> >>
> >> I hope people are basing their votes on the right motion!
> >>
> >> Nate
> >
> > Hmm. Interesting. We have 3 files here.
> >
> > The file Prof Kulisch posted on 4/15 is called RoundOper.pdf
> >
> > I am quoting from the file that is on the motions website as
> > documentation for motion 24 which is motion24roundOper.pdf.
> >
> > It is the file I consulted when I made up my mind & it contains
> > the passage you see above.
>
> Ah, dang. I don't have the current password to the motions website, but I
> take your word for it...
>
> as Vladik suggests, maybe it is appropriate to clarify and restart the vote;
> or perhaps it is enough just to clarify and then proceed with voting (people
> can choose to change thier votes or not at thier own discretion).
Perhaps.
I'll leave that up to the officers.
It did not change my vote but it did change Vlad's.
And we both said so.
So can others if they wish to clarify matters.
>
>
> >
> > But you are correct, the file Ulrich posted on 4/29 under the
> > name RoundOper1.pdf contains the modified passage:
> >
> > The operations with the directed roundings SHOULD be
> > implemented directly in hardware for efficiency reasons.
> >
> > However, the paragraph that now preceeds that passage states:
> >
> > Every IEEE 1788 compliant system SHALL provide the 8
> > operations with the directed roundings by distinct
> > operation codes. Each of the 8 operations SHALL be
> > callable as a single instruction. The rounding SHALL
> > be an integral part of the arithmetic operation.
> > Employing an operation with a directed rounding must
> > be as simple as employing the corresponding operation
> > with rounding to nearest.
> >
> > (emphasis his in bold).
> >
> > Do you REALLY think that's an improvement?
>
> If you believe conforming systems must provide the 8 distinct rounded
> operations, though not necessarily in hardware, then it seems the language
> is an improvement... though if we wish to split hairs it may still be
> necessary to give specific definitions for the terms "operation codes" and
> "instruction". Usually these terms are associated with hardware
> implementations.
>
> Nate
There are many things here.
First, all 754 implementations that I am aware of
today DO provide for directed rounding instructions
in hardware.
It is just that the 8087 legacy has most of them
providing it with the inefficient 1980s method of
rounding modes. Some more modern machines do as
Ulrich suggests but most don't.
Thus things like distinct operation codes, single
instructions & an integral part of the arithmetic
operation are not splitting hairs. They are a
fundamental difference in approach. A difference
that most machine architectures are unequipped to
handle.
Finally, even if there WERE machines out there
that did the directed rounding instructions (or
some part of them) in software I would STILL think
this is a bad idea for us as a standards body to
demand of our implementers.
It is not our place to make hardware decisions for
our implementers. They are far better trained to
do that than we are. It is rather our place to
decide how intervals shall appear (the shall is
intentional here) to the user of intervals. This
is where we (present company excepted) are far
better trained then they are.
>
>
> >
> > I think the intent is clear & it does not change my mind.
> > All my arguments apply to this motion as well as the other.
> >
> > I guess I vote NO whichever is the correct motion.
> >
> >
> > Dan
> >
Don't get me wrong: I think what Prof Kulisch has
in mind is a good idea. The last machine I worked
on before I retired had opcodes for this. It is
just not something that we have the right to demand
(shall) or even ask (should) of our implementers.
So I vote no.
Dan