Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: I vote NO on Motion P1788/M0024.02:RoundedOperations



Since Dan is among the most knowledgeable in this group about the standards language, I concur with him and vote NO. Just like Dan, I like the idea of encouraging the manufacturers to implement these operations, but I am worried about the language. If the terms are changed, I will gladly vote Yes, because clearly operations with direct rounding are extremely important. 

-----Original Message-----
From: stds-1788@xxxxxxxx [mailto:stds-1788@xxxxxxxx] On Behalf Of Dan Zuras Intervals
Sent: Sunday, May 15, 2011 9:42 AM
To: Ulrich Kulisch
Cc: stds-1788@xxxxxxxxxxxxxxxxx; Dan Zuras Intervals
Subject: Re: I vote NO on Motion P1788/M0024.02:RoundedOperations

> Date: Sun, 15 May 2011 17:06:05 +0200
> From: Ulrich Kulisch <Ulrich.Kulisch@xxxxxxxxxxx>
> To: Ian McIntosh <ianm@xxxxxxxxxx>
> CC: stds-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: I vote NO on Motion P1788/M0024.02:RoundedOperations
> 
> 
> Ian:
> 
> As I said already in my answer on Dan's mail the motion does not require 
> hardware instructions with explicit rounding modes!
> 
> The motion requires arithmetic operations with the directed roundings as 
> distinct operations. The rounding shall be an integral part of the 
> operation.
> 
> These operations are the basic building blocks for interval arithmetic. 
> For a quarter of a century these operations have not been available and 
> this was felt as great deficiency for interval arithmetic. Of course, 
> many tricks have been developed to code around this. But with an 
> interval arithmetic standard these times definitively shall be left behind.
> 
> Best wishes
> Ulrich
> 

	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).

	The key word is "shall".  In the nomenclature of a standard
	the word "shall" is used to describe something that is
	mandatory.

	If, as you say, you intend that these instructions are NOT
	required, the word that indicates that is "should".

	The fly in the ointment is that the word "should" is
	interpreted by implementers as "need NOT be done".

	In that case we, as a standards body, cannot count on the
	mentioned feature to be there & we must write the rest of
	our standard to presume that it is not.

	Those are your choices for a motion: Require it with "shall"
	& eliminate Intel, IBM, & nearly all other current machines
	from conforming to our standard.  Or recommend it with
	"should" and assume it is not there.

	The third alternative is not to mention it at all & count
	on enlightened self interest to encourage the implementers
	out there to innovate in their own ways to beat the
	competition as they see best.

	I choose this last which is why I voted no.

	I apologise if my argument centers around wordsmithing
	but in this case I think it goes to intent as well.

	Yours,

				Dan