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

Re: (OOPS) Motion P1788/0019.01: Explicit/Implicit idatatypes -- VOTING PERIOD ALSO BEGINS

Nate Haye wrote:

Baker Kearfott wrote:

Nate, P-1788,
I guess we agree to disagree. My interpretation of "support" is that it is explicitly mentioned, e.g. that the actual accuracy of the result of an operation whose operands were of mid-rad form would be defined. In contrast, in Motion 19 (and correct me if I am wrong), general rules, such as "must contain the exact result" would be defined for ALL implicit data types, and a mid-rad type could claim to conform to 1788 if it satisfied these general rules, although no rules for a mid-rad type would be explicitly defined in the standard (and hence there would be no explicit support 
for the type in the standard, only implicit support).
Well, it is a nice thought and interpretation, but its not what I see Motion 23 is advocating, unfortunately.
In fact I would not have given the motion a "second" if I had been under this interpretation that it is what Arnold had been intending. Clearly if you go back and read those e-mail messages, I don't see that this was the intention of Motion 23. 

Nate Hayes








This would avoid some, if not
all, of the issues put forth by those opposed to inclusion of a mid-rad type.
That is why I think people of this persuasion should vote NO to Motion 23 and vote YES to Motion 19. The current revision of Motion 19 does not require that any implict i-datatype is supported by default: however, vendors and implementors may support implicit i-datatypes such as mid-rad if they wish (according to Motion 19). But none of this even requires mentioning the words "mid-rad". So Motion 19 is already entirely in-line with your rationale given above.
However, I also point out that Motion 23 is actually a motion on two unrelated topics: mid-rad and Kaucher arithmetic. So by suggesting that people should vote YES to Motion 23 on grounds of the mid-rad rationale as you are advocating above, am I also correct you are implicitly endorsing that Kaucher intervals should not be in the standard? 

Sincerley,

Nate Hayes
In any case, if one or both motions passes, our Technical Editor will need to follow SOME interpretation of what "support" means, to craft the actual wording. Hopefully it will be close enough to what most of us assumed it meant in the accepted position that we'll get the needed 2/3 majority on the actual wording. 

John: Do you have an opinion on this?

Baker

On 10/10/2010 13:30, Nate Hayes wrote:

Baker Kearfott wrote:

Nate et al,

On 10/10/2010 13:05, Nate Hayes wrote:



.
.
.
It seems to me that even under this interpretation it will be a self-contradiction for P1788 to vote YES to both motions 19 and 23. So I guess I don't share your perspecive.
For example, if both motions pass, this seems to imply only non-midrad i-datatypes will be allowed in IEEE 1788. At least, that would be my interpretation.
What if general rules for implicit data types were spelled out, but mid-rad were not 
explicitly mentioned in the standards document?
Well, as I said: my interpretation (and apparently your as well... see below) of Motion 23 is that it would not allow what you describe above, since Motion 23 says there shall be no "support" of a mid-rad type. Period. This seems to match 
your own interpretation of Motion 23, as you said:


Here, let us agree that "support" in this motion means that
operations on the object, possibly including accuracy and
reproducibility requirements, are explicitly defined in the
standard.
In Motion 19, the word "support" means that operations on the object are defined in the standard (see Clause 3.5, Item 6 of Motion 19). Motion 23 would not allow a mid-rad i-datatype, since that would require "support" in the Motion 19 sense.
This means mid-rad would be permanently relegated to an "available"-only type in a future IEEE 1788 standard.
So it is a bit of wishful thinking, I believe, that both Motions 19 and 23 could pass and that this would not represent a self-contradictory outcome. At least, that is my interpretation of the two motions. 

Nate




--

---------------------------------------------------------------
R. Baker Kearfott,    rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------