| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Obviously lots of thought and work has gone into this. I have some comments, suggestions and questions, and one thing we disagree on.
3.2.1 arithmetic operation:
"Constants such as 3 and TT are regarded as arithmetic operations whose number of arguments is zero."
I disagree with treating constants as arithmetic operations instead of as constant values (interval datums). It adds too many complications in too many places (5.4.1, 5.4.2, 5.4.3, ...).
If we treat constants as arithmetic operations, shouldn't we treat variables as arithmetic operations too? And if constants are arithmetic operations defined in the implementation library, should all constants be included in either section 5.6 or 5.7? And maybe all variables? Of course then we'd have to decide which constants (and maybe which variables?) are required and which are recommended. 8<) It's better to treat constants as what they are - constants. That of course means rewriting section 5.4.4 Constants, keeping some of the wording relating to how the value of a constant is determined.
"Details in S5.4."
This shouldn't be part of the paragraph about constants, since section 5.4 says nothing about them.
3.2.3 domain:
"the domain comprises those points in the set..."
Comprises is am awkward word for a standard to use, since it has two definitions that are almost opposites and that are both in current use. In the first, the parts comprise the whole. In the second, the whole comprises its parts. The first was I think the first definition, and there is no good synonym for it. The second can be replaced by "consists of". Maybe this doesn't matter here, since the sentence makes the meaning clear, but I prefer to avoid ambiguous words. See also sections 3.2.5, 4.1 Level 2, 5.2, ...
4.1 Specification Levels Overview - Level 2
"In addition to an ordinary (bare) interval, this level de nes a decorated interval..."
Should that be deleted in this motion?
"The arrows in the table..."
Perhaps "The arrows in Table 1..."?
5.4.4 Constants:
"an interval extension of a real constant is any zero-argument interval function that returns an interval containing c."
Should this return the hull, instead of any interval containing the constant?
5.5.2 Generic functions
"An arithmetic operation or _expression_ may also denote a floating point function; this is not relevant to this standard."
At level 1, should "floating-point" be "Real"? And would it be more precise to say such functions are not defined by this standard?
5.6 Required operations
"as well as those normally written in binary operator notation x y"
Since some of the operations are unary not binary this should include "or written in unary operator notation x". If constants are operations then they need to be allowed too.
5.6.2 Case expressions and case function
There are probably good reasons for defining the case condition as true if it's <0, but most programming languages consider any nonzero value as true so this may cause some confusion. An alternative would be to define c as a boolean, with c<0 giving the current semantics.
The hull (g U h) aspect may also cause confusion. Confusion leads to bugs.
Table 2 Required forward elementary functions.
"Rev" shouldn't be capitalized.
Why not call it recip, short for reciprocal?
Table 5 Recommended elementary functions
In the final standard we should try to avoid having any section split by any table. It wasn't immediately obvious to me that "This is a point-function" referred to dotProduct on the previous page.
Thanks for all your work!
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development