Re: Motion 31 Suggestions
Dear Ian
I had forgotten where I had stored your comments of 29 Dec. Apologies for the delay. Responses below.
John
On 29 Dec 2011, at 23:07, Ian McIntosh wrote:
> 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.
I don't agree with this. Maybe I need to say more about how constants are defined: there is a language-defined syntax that says what kind of string is a (point) literal constant and what its value is. There may also be language-, library- or user-defined constants.
The syntax and semantics of expressions in §5.5 makes clear that variables are completely different from constants. It has the advantage that "interval extension of a point constant" has an immediate definition, being a particular case of "interval extension of a point function".
This notion of constants was good enough for Ada, as I recall, so it should be good enough for 1788. Defining a language is different from defining a language-neutral standard, but the necessary adjustments should not be beyond us.
However, I see that §5.6 "Required operations" needs a paragraph on constants. Its statement
> an implementation shall provide interval versions
> appropriate to its supported interval types
must apply to literal and named constants. Are there syntactic/semantic obstacles to doing this in a way consistent with "treating constants ... as constant values (interval datums)" (your words)?
E.g., what's the interval version of the literal "1.234" appropriate to the (inf-sup) binary64 type? This is where the work by Arnold and others on ways of ensuring containment comes in. It's not enough to write something like
num2interval<binary64>(1.234)
because that won't enclose the true value 1.234, only its binary64 approximation. So we need
text2interval<binary64>("1.234") & similarly text2interval<binary64>("Pi"), etc.
Arnold has had interesting ideas on this since the Vienna proposal; I need to search for them in the emails.
Your advice will be valuable here. 1788 should not make requirements that are properly the concern of languages, but it must make its definitions implementable in a language.
BTW, I guess a literal is a symbolic object, but in many languages (e.g. Maple) symbols and text strings are different kinds of thing, and denoted differently. So we should aim to use wording that doesn't force literals to be text strings.
> "Details in S5.4."
> This shouldn't be part of the paragraph about constants, since section 5.4 says nothing about them.
Changed 5.4 to 5.4.4.
> 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, ...
A good point. My usage is
"Set S comprises those x in set X such that P(x)" means S = {x in X | P(x)}.
whereas
"Set S consists of x in set X such that P(x)" means S \subseteq {x in X | P(x)}.
and "comprises" is usually replaceable by "consists of exactly". I've added a note about that to 1.5 "Word usage".
> 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?
I've marked it as such.
> "The arrows in the table..."
> Perhaps "The arrows in Table 1..."?
Done
> 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?
It says the *natural* extension is [c,c], i.e. the hull. Am I missing your point?
> 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"?
No, it means "floating-point". "Real functions" are "point functions", which this subclause _is_ about.
> And would it be more precise to say such functions are not defined by this standard?
Yes, done.
> 5.6 Required operations
> "as well as those normally written in binary operator notation x y"
> ... should include "or written in unary operator notation x".
Done
>
> 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.
I struggled with this for some time. An earlier version had c as a boolean, but reconciling that with the concept of interval hull is horribly unnatural IMO. As is "taking any nonzero value as true".
> Table 2 Required forward elementary functions.
> "Rev" shouldn't be capitalized.
> Why not call it recip, short for reciprocal?
Done. Meant to be recip. Probably the result of a careless "replace all"?
> Table 5 Recommended elementary functions
> In the final standard we should try to avoid having any section split by any table.
I agree. Getting good page layout with so many tables is hard, so I'll leave it till near the final cut.