| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Michel and P1788
I have tried to respond to Michel's comments below.
Appended also is my response to Vincent's comments, which I sent to him privately yesterday.
I attach PDF of the resulting version, whose page headers and watermark proclaim it as V04.3.
I have not put in any change tracking, but when we have time, I or Christian will add marginal marks to link nontrivial changes to the email (sender + date) that triggered them.
I have included Clause 2 "Introduction" in this PDF, because Vincent said rationale is needed for some choices we have made. This Intro already has some rationale, so it seems an appropriate place to include whatever extra is required. Vincent, how do you feel about contributing?
Back to the grind... more comments to consider...
John
On 26 Jan 2012, at 23:01, Michel Hack wrote:
> Some comments:
>
> 4.1 Specification levels overview. Mention openface-T in the text
> for Level 2, so that T-hull does not come as a surprise in a.
> ...
Good idea. What's in the Table isn't enough. Helpful info added, I hope.
> 5.5.2 Generic functions. "The implementation's library contains
> all computable versions ...".
> ALL computable versions? That seems like a LOT.
Vincent made same point. Done, I hope.
> 5.5.3 Point functions ... "... the undefined function NaN ..."
>
> Cute -- given that constants are 0-ary functions, this is
> in fact a perfectly well-defined constant!
I thought it is cute too, but begin to wonder if it is a bit "over the top" for a general user of the standard.
> 5.6.1 Constants. I suppose 'expressible in the C language" is just a
> placeholder at this point. This is separate from using C syntax in
> an illustrative manner in the standard ("This standard writes..."),
> which is ok.
I thought "expressible as floating constants in the C language" was quite a good idea and could be permanent! It describes a SET S of (extended real) numbers, not a WAY of writing them. And I think languages of the Fortran/C/Java/Matlab families all have the same S. (Symbolic languages can express much more.)
> Can we not simply tie this to the definition of expressions in 5.5.3,
> using point functions from the set of required point point functions?
> In other words, compile-time expressions (no variables, only functions,
> including constants (i.e. literals)).
But the aim of 5.6.1 is to tie this down -- to state a minimal set of values an implementation MUST allow the programmer to denote by literal constants.
Michel: If you don't like or accept my explanation, propose better wording.
> Table 2, Required forwards elementary functions, Note h: round() should imply
> ties-away-from-zero? Really?
Good point. I changed to "round(x) is the nearest integer to x, with ties rounded according to the language default." Will that do?
> Table 3, Required reverse elementary functions. We need two versions of
> the non-commutative ones: divRev1, divRev2, powRev1, powRev2 -- or
> perhaps powRev2 is not needed or practical.
So we do. Also two versions of atan2Rev.
Worse than that, I gave the functions in the table the wrong number of arguments according to the specifying enclosures (5), (6), (7). Corrected.
I now have divRev1, divRev2, powRev1, powRev2, atan2Rev1, atan2Rev2. I leave all these reverse functions as Required for now. Note that the Vienna proposal 3.8-3.11 uses the phrase "if required", but the tables indicate it thinks all those in our list ARE required.
> Table 4, Required numeric functions. midRad() is not a numeric function
> according to 5.6.8 ("the result a number"). Indeed, at Level 2
> there would be a problem: what kind of beast is "a pair of numbers"?
Thanks for forcing clarity here. Will you propose suitable wording, maybe on the lines of the next paragraph. Returning several values is not really a problem but the mechanism is language-dependent. Matlab can do it directly. Fortran, C, etc can do it via the argument list. Or one can put the outputs into a structure. Shouldn't we just ask a language to achieve it in some appropriate way?
> What could be said is that implementations are encouraged to provide
> a way return both mid() and rad() of the same interval in a manner
> that avoids extra work, just as quotient and remainder are often
> delivered together. Many compilers will be able to deduce this
> from context when the two nominally-separate functions are invoked
> next to each other.
Yes. Here, at Level 2 we want m,r returned such that [m-r,m+r] (if no NaN occurred) is guaranteed to enclose the input interval.
> If an implicit midrad type is supported, it should of course have a
> constructor, or type conversion from infsup to midrad, but that falls
> under extra type-specific operations (something that can only happen
> at Level 2).
Yes.
========================================================================================
Vincent
Responding, with apologies for missing it earlier. You have paid great attention to detail, for which many thanks.
John
On 11 Jan 2012, at 15:25, Vincent Lefevre wrote:
> On 2011-12-05 07:10:51 +0000, John Pryce wrote:
>> I circulate herewith a draft text, and submit a motion ...
>
> Not sure about the current status, but here are my comments:
>
> General note: a rationale would help to understand some choices.
The Introduction, which I left out of the circulated text, gives some rationale. I attach a copy with that included; it hasn't been amended for over a year and I'ld be glad of your ideas for a thorough rewrite.
If you would be able to add yourself to the editorial team of me and Christian Keil, and rewrite the Intro yourself with suitable rationale, even better! I would be most grateful of that help.
> §3.1: Is the notation compatible with the ISO 80000-2:2009 standard?
> http://en.wikipedia.org/wiki/ISO_31-11 says: R* = R \ {0}
I wasn't aware. I've used R* myself for years. An alternative is \overline{R} (with mathbb). I think we didn't choose that at the start because Ulrich's liking for \overline{IR} to mean all closed intervals is a little incompatible. It's a macro, so trivial to change globally.
> §3.1, IR (editorial): } } -> }
Done
> §3.1, F: Must -inf and +inf be part of F?
If F is a f.p. format, yes, to ensure that the hull always exists for the inf-sup type. But where in the text are you referring to?
> §3.1, \overline{IF}: what about the empty set? (§5.2 gives an answer,
> but "bounds" is not currently defined, and using infinite bounds for
> the empty set is quite artificial).
I agree, and will change it. But, now we have implicit types, IF and \overline{IF} maybe should be de-emphasized.
Also, it is an ill-defined notation. Is the I an operator? If so, why does the overline go above both symbols? If not, when I have two formats called F and G, how do I justify the notations \overline{IF} and \overline{IG}?
So I think I *will* introduce \overline{\mathbb{I}}, call it \Itype, as the operator that maps a subset F of R* (possibly F=R*) to the set of intervals whose bounds belong to F. So when F is a number format, \Itype maps F to its derived inf-sup type T (modulo the "tagging" by a name for T).
That implies
current \overline{\mathbb{IR}} becomes \overline{\mathbb{I}} \mathbb{R}
i.e. overline on one letter instead of two. Similarly with F, or anything else, instead of R. And putting parenthesis round the R or F is allowed since it is an argument, so I can denote binary64 inf-sup as
\overline{\mathbb{I}}(\mathtt{binary64})
All this abbreviated with suitable macros of course. What think you?
> §3.2.1 (arithmetic operation): "interval non-arithmetic operation" is
> mentioned but not defined.
Added.
> §3.2.6 (fma): "with only one rounding" -> This is Level 2!
I simply deleted "with only one rounding", but wonder if a reference to Level 2 should be made.
> §4.1: OK.
>
> §5.5.1 (editorial): "2y" -> "(2y)"
Done
> §5.5.2: "The implementation's library contains all computable versions
> of all provided arithmetic operations" -> What is meant by "all"?
The first "all", I guess you mean. A poor sentence. It is intended as a definition, not a requirement. Will this do instead?
"An implementation’s library by definition comprises all its computable versions of required or recommended operations that it provides for any of its supported interval types, as specified in §5.6, §5.7 and in Clause 6."
> §5.6, Table 2 page 17 (editorial):
> * "R² \ {y = 0}" -> "R² \ (R × {0})" or "R × (R \ {0})"?
> Similar change for pow(x,y)?
That's a matter of taste. I explain the notation in note (a), & personally find mine more readable.
> * The notation (x,y) is used with two different meanings: a set
> (open interval) and an ordered pair. For sets, I suggest the
> use of [x,y[, ]x,y] and ]x,y[.
Yes. Classical math notation has its faults. But changing to the ]x,y] style everywhere will need SO much work and some people (myself included) don't like it much. I'll try using visibly different parentheses in these tables for the ordered pair meaning, with a note about it.
> * "case(b,g,h)" -> "case(c,g,h)" for consistency with §5.6.2.
Yes
> Note e of Table 2: this is also true for exp and tanh.
I don't understand, please clarify.
> §5.6.6, Table 4 page 19:
> * I would prefer NaN for mid(x) on an unbounded interval, because
> on non-Entire unbounded intervals, there are no centers of
> symmetry, and for Entire, every real number is a center of
> symmetry.
I changed this already. Also, following my current policy, I have changed all NaN values of functions at Level 1 to "undefined".
> * What about mag(Empty) = -inf and mig(Empty) = +inf?
Applies also to sup(Empty) = -inf and inf(Empty) = +inf. (Double use for inf, sorry!) I support this as a mathematician. Non-mathematicians often seem to object. I suggest a vote on these details is needed at a later stage.
One problem with mag(Empty) is that one can argue it should be 0, on the grounds that that is the smallest value that can be taken for all nonempty arguments.
> * I think that at Level 1, NaN could exist only as a result
> and should be a synonym of "undefined".
Seems you agree with my policy.
> §5.6.8 (dot product function): if the interval extension is not
> required, this function shouldn't belong to §5.6.
But it *is* a required operation. I've changed §5 first paragraph appropriately, I hope.
> §5.7.1, Table 5 page 20:
> * Range of atanPi: [-1/2,1/2] -> (-1/2,1/2) or ]-1/2,1/2[.
> * Domain of atan2Pi: (0,0) should be excluded (like for atan2).
Dear me. Done.
> §5.7.2, Table 6 page 21:
> * Range of cosSlope2: [0,1] or (0,1]?
Doesn't it =0 at x = 2\pi ?
Attachment:
20120131RevisedLevel1textV4.3Sent.pdf
Description: Adobe PDF document