Re: Motion 31: V04.2 + V.Lefevre + M.Hack = V04.3
On 2012-01-31 21:43:40 +0000, John Pryce wrote:
> Appended also is my response to Vincent's comments, which I sent to
> him privately yesterday.
Here are my comments to the private mail. I haven't looked at V04.3 yet.
On 2012-01-30 22:01:59 +0000, John Pryce wrote:
> On 11 Jan 2012, at 15:25, Vincent Lefevre wrote:
> > 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.
The introduction is too general. I really mean a rationale, with
explanations that would normally not be in an introduction, e.g.
concerning the definition of mid() on special cases.
> > §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.
In France, R* is a well-known notation for R \ {0}, ditto for the
other fields (for rings, it is ambiguous since depending on the
context, it can mean the ring without 0 or its group of units).
> An alternative is \overline{R} (with mathbb).
Yes, this is the notation I generally see. It is used here:
http://en.wikipedia.org/wiki/Extended_real_number_line
and here:
http://mathworld.wolfram.com/AffinelyExtendedRealNumbers.html
where it is said:
"Although the notation for this set is not completely standardized,
\overline{R} is commonly used."
> 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.
I don't see it as incompatible. \overline{IR} is also the set of
all closed intervals whose *bounds* are in \overline{R}, so that
I think that's fine.
> > §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?
The definition of F. I think it should be explicitly said that
-inf and +inf are part of F.
> > §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.
Yes.
> Also, it is an ill-defined notation. Is the I an operator?
I don't see it as an operator. Otherwise the case of the empty set
should be made consistent.
> 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}?
I think it should just be seen as a notation (a notational operator
if you want).
> 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).
Note that currently, the empty set doesn't belong to IR, but belongs
to \overline{IR}.
> That implies
> current \overline{\mathbb{IR}} becomes \overline{\mathbb{I}} \mathbb{R}
> i.e. overline on one letter instead of two.
I wonder where it is better to keep the overline over R as the
bounds are in \overline{R}, i.e. include +inf and -inf.
> 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?
And what about the bounded intervals? \mathbb{I}(\mathtt{binary64})?
Including the empty set?
> > §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.
This reference would typically be in a rationale.
> > §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."
I still don't understand. The problem may be the meaning of "computable"
and there may be some confusion between Level 1 and Level 2.
> > Note e of Table 2: this is also true for exp and tanh.
>
> I don't understand, please clarify.
Since intervals are closed, the range for exp with be [0,+inf],
thus including 0, which is not in the mathematical range.
Ditto for tanh with -1 and 1.
[...]
> I changed this already. Also, following my current policy, I have
> changed all NaN values of functions at Level 1 to "undefined".
I agree.
> > * 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.
OK. It would also be useful to know what is the best choice in practice.
> 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.
The drawback concerning 0 is that mag({0}) will already give 0.
Since -Inf and +Inf are not real numbers, getting -Inf for a sup{...}
and +Inf for an inf{...} necessarily means that the argument was the
empty set, whatever the definition of the function.
> > §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.
Ah, OK. But I disagree on the fact that it should be a required
operation. Title of P1788 is "IEEE Standard For Interval Arithmetic"
so that it shouldn't require anything concerning point functions of
point values (though it can be more or less a pratical consequence
of some required interval function -- but this is not the case here).
> > §5.7.2, Table 6 page 21:
> > * Range of cosSlope2: [0,1] or (0,1]?
> Doesn't it =0 at x = 2\pi ?
Hmm... yes (I misinterpreted output given by PARI's plotting function).
On 2012-01-31 07:57:43 +0000, John Pryce wrote:
> What do you think of the revised \overline{I} notation? The overline
> looks rather inconspicuous, maybe should be wider.
I'm not sure. Before the notation, the spec should first be clear.
On 2012-01-31 09:54:09 +0000, John Pryce wrote:
> Notation again, sorry. But you brought up R^* (call it R*) versus
> \overline{R} (call it Rbar), etc, and I would like to have your
> ideas & hopefully agreement.
See above.
> I looked at the page you referenced, about ISO_31-11, and saw R*
> indeed means (R with 0 removed) there. Never used that, but as a
> standard worker I'd better respect other folk's standards.
AFAIK, all French math books use this notation.
What about English ones?
> Looking in my library:
> - To my surprise I saw I had used Rbar for the extended reals in my book "Basic methods of linear functional analysis" (1973), just reprinted by Dover.
:)
> - M.E. Munroe "Measure & Integration" (1953) uses the set of extended reals but avoids giving it a name.
> - The IEEE754-2008 standard doesn't give it a name.
> - A.J. Weir "Lebesgue Integration & Measure" (1973) amazingly avoids the use of infinity as an "actual thing" entirely.
> I couldn't find it used in any other book on my shelves.
>
> And Wikipedia's page on extended reals uses Rbar. So there is a good
> argument for changing to it, and I use it below.
and MathWorld (that I mentioned in my reply above).
> Now, for "interval type" notation, here are some possibilities.
> R and I shall be in mathbb font unless otherwise said.
I agree.
> (a) I and Ibar (= \overline{I}) are 2 separate operators. For any subset A of Rbar,
> I A, or I(A), comprises all intervals whose endpoints are (possibly infinite) members of A. (So, they are all nonempty.)
Nonempty should be said explicitly (because [1,0] could be seen as the
empty set, for instance).
> Ibar A, or Ibar(A), comprises the empty set together with all intervals whose endpoints are (possibly infinite) members of A.
But if -Inf and +Inf and members of F, there is no longer a way to
denote the bounded, nonempty itervals whose endpoints are members
of F (see the current IF).
> The effect of this is that I(R) is the classical set of intervals
> used by Moore, and Ibar(Rbar) is P1788's set of intervals.
> [Ibar(R) and I(Rbar) are different from these & from each other.]
> But then the bar on top just signifies "include the empty set",
> which is a rather unnatural use of notation.
Yes.
> (b) Just use one of these operators. For simplicity use I:
> I A, or I(A), comprises the empty set together with all intervals whose endpoints are (possibly infinite) members of A.
>
> Then, I Rbar or I(Rbar) is P1788's set of intervals.
>
> I(R) is not the same as the classical set since it contains Empty.
> Perhaps a super- or sub-script "-" could be used to mean Empty is
> omitted, as in I^-(R) ? It doesn't seriously matter, since we don't
> use the classical set, but we may like to refer to it.
>
> I rather favour choice (b).
But what about the bounded intervals (for F)? Are they needed?
If yes, I(A) could mean "bounded, nonempty, closed intervals"
and Ibar(A) could mean "closed intervals".
Regards,
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)