| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 notexplicitly 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