Re: Rounded operations discussion...
P 1788,
On May 15, 2011, at 1:32 PM, Nate Hayes wrote:
> BTW, I changed the thread title for the sanity of our voting tabulator. :)
Thanks. Since I tabulate the votes by hand, I was not at all confused :0
For everyone's information, the vote currently stands at Yes: 5; No: 7; Needed for quorum: 37
Voting ends 2011-06-03.
If you cast multiple votes, only the last one counts.
If you have a sense of humor about the jobs our students get (or your company offers), and can laugh at gender stereotypes, watch the Code Monkey video/song: http://www.youtube.com/watch?v=v4Wy7gRGgeA
George
>
>
>
> Dan Zuras wrote:
>>> 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.
>
> I agree.
>
>
>>
>> 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 don't think you need to convince anyone of this, because no one is arguing this point (that I am aware of).
>
>
>>
>>>
>>>
>>> >
>>> > 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.
>>
>
> The current motion does not demand (shall). So I take it you believe it is too much even to ask (should).
>
> IEEE 754-2008 asks for last-bit accurate transcendental functions. No hardware does this, and even software implementations can be slow. But was it wrong to set the bar so high?
>
> Nate
Dr. George F. Corliss
Electrical and Computer Engineering
Marquette University
P.O. Box 1881
1515 W. Wisconsin Ave
Milwaukee WI 53201-1881 USA
414-288-6599; GasDay: 288-4400; Fax 288-5579
George.Corliss@xxxxxxxxxxxxx
www.eng.mu.edu/corlissg