Re: Motion 42: NO
On 2013-02-13 12:49:31 +0000, John Pryce wrote:
> On 31 Jan 2013, at 17:13, Vincent Lefevre wrote:
> > §5.2, paragraph 2: "no other intervals belong to all of them" to be
> > changed to "no other intervals belong to the set of all of them"?
> How about "..., and there is no interval outside IR that is
> supported in all these flavors"?
..., and there are no intervals outside IR that are supported in all
these flavors
> > §5.3, first paragraph:
> Last para of 5.2 I think.
No, it was §5.3 "Loose common evaluations".
> > If I understand correctly, the notion of
> > "loose" / "tight" is mainly for Level 1 and is aimed to be similar
> > to the notion of accuracy modes at Level 2.
> No, it is intended to apply to both Levels, in fact mainly to Level 2
> in practice.
But in practice, a Level 2 evaluation cannot be tight in general,
because of rounding (the only tight evaluation being the range of
the function over the input intervals).
[New text about sharing]
> Is that OK?
Yes.
> > §6.1, paragraph 5 ("Especially..."): it is said "f restricted to x
> > being continuous", but this is not the same as f being continuous
> > at each point of x (used for common intervals). In §8.8.2, dac uses
> > the latter property, contrary to com (§5.2 and §8.8.10). Is this
> > difference intentional? If yes, I think this should be emphasized
> > (here and/or later). IIRC, this point was unclear in our private
> > discussions (in particular when "bdc" was introduced).
>
> Intentional. I added an explanation in the examples at the end of
> draft 6.2 §5.2 (now draft 7.0 §6.2). I would be glad if you can
> check the draft 7.0 text & say what other places should
> cross-reference this.
It seems this I don't have the latest version of Draft 7.0 (where it
is still §5.2). The clause on the com decoration (§10.10 in the draft
I have) could cross-reference this.
> > §6.2, paragraph 3: "For diagnostic use it may convey Level 3 or 4
> > information, e.g., how an interval is represented, or how memory is
> > used." would be possible only for specific intervals, in particular
> > not in a common evaluation (unless only one flavor is provided), as
> > the "com" decoration shall be used. This is a bit misleading.
>
> I don't follow. Common-ness is only about numerical behaviour. A
> program running in some debugging mode, say, can store whatever it
> likes in a tag to an interval (machine addresses, time of day, links
> to the latest BBC news, ...) without changing the numerics.
Currently we have the interval part and the decoration part, and
nothing else. This paragraph is about the decoration part. If you
change the decoration part to something other than com, it would
be wrong. Adding a third kind of information would be OK, but it
would not be a decoration, and this isn't the right place to talk
about that.
> > §8.8.1, paragraph 2: §8.8.8 is missing.
> Strange. In my copy of what was circulated it's there,
> "User-supplied functions".
I have:
The system is specified here at a mathematical level, with the
finite-precision aspects in §9.13. §8.8.2, 8.8.3, 8.8.4 give the
basic concepts. §8.8.5, 8.8.6 define how intervals are given an
initial decoration, and how decorations are bound to library
interval operations to give correct propagation through expressions.
§8.8.7 lists operations that do not propagate decorations. §8.8.9
discusses the decoration of user-defined arithmetic operations.
§8.8.10 specifies the sixth decoration com, which is required in a
multi-flavor implementation. §8.8.11 defines a restricted decorated
interval arithmetic that suffices for some important applications
and is easier to implement efficiently.
I've just checked. This is the same text as in the file on the web
site (dated January 14, 2013).
> > §8.8.3: It should be made clear that NaI must not be returned if
> > the interval interpretation would not return an empty interval,
> > even in the case where the true decoration is ill (this was from
> > my remarks in our private discussion). For instance, even though
> > the implementation may return NaI
> NaN, perhaps?
? I'm talking about a decorated interval (NaN is for the number
formats).
> > for sqrt(-1-x^2) for any x, it
> > must not return NaI for sqrt(-1-x*x) where x = [-1,1], because
> > at Level 1: x*x = [-1,1], -1-x*x = [-2,0], sqrt(-1-x*x) = [0,0].
>
> This is an important technical issue, related to Guillaume's recent ideas.
> If one takes the view that "ill" should be used whenever one finds
> the domain of a function is empty, then IMO your stance is quite
> illogical.
No, I've explained why in other mail. The reason is that intervals
(the interval part) may be used for different purpose, while the
decoration part must be associated with a point function.
> But if one takes the view that NaI is a pragmatic object, that only
> occurs as a result of bad constructions, is your view logical? I
> still don't find it so, for the "half the job" reason.
sqrt(-1-x*x) isn't necessarily a bad construction.
> > The reason to decorrelate the variables is that the implementation
> > doesn't know what a variable means exactly (this may be specified
> > by the language, but the exact meaning may also be left to the end
> > user). By default, the implementation should behave in a safe way.
> > Indeed, a variable may represent several mathematical values. For
> > instance, a math problem may have its own x_i's, where the index i
> > can take a huge number of values, and it would be inefficient (or
> > even impossible) to take care of all these different x_i's in a
> > program. So, the user may choose to represent each x_i by a single
> > interval variable x such that x_i is in x for all i.
>
> One can argue such things but math says what math says, and I'm
> unconvinced.
The above is math. Math on *intervals* (functions are thought
as taking directly intervals as inputs, no longer real numbers
[or symbolic variables] represented by intervals).
--
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)