| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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). This would avoid some, if not all, of the issues put forth by those opposed to inclusion of a mid-rad type. 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 ---------------------------------------------------------------