Re: Reasons to vote Motion 27: NO
> Subject: Reasons to vote Motion 27: NO
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Mon, 1 Aug 2011 16:36:07 -0400
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Jürgen, Marco and Nate -- and P1788
>
> On 29 Jul 2011, at 16:09, Jürgen Wolff von Gudenberg wrote:
> > you are comparing apples with pears. Motion 26 is part of the text whereas motion 27 is written as a position paper.
> > The main differences are:
> > motion 26 the containment order of decorations, the FTDIA
> > motion 27 decorations describe the history of computation, they have NO impact on comparisons, therefore an explicit FTDIA is not necessary the usual FTIA is sufficient
>
> (I am referring to your version 1.5 dated 8 July.)
> OK, it's fair to express a position paper more informally than text intended as part of the standard, but Motion 27 goes beyond just being informal.
>
> What to make of your 1.1
> "Decorations are properties that carry information on the history of the interval"?
> Well, yes by-the-by, but what they do that is OF INTEREST is your
> "A decoration is determined when a function f is applied on an interval (box) xx"
>
> Namely this decoration says whether f is (known to be) defined, continuous, etc., on xx.
> - That's what your Definitions 1 & 2 SAY explicitly.
> - And what you, or Arnold, or I, or anyone else USES when we include
> this feature in code.
> That's why the argument about "static versus tracking" is completely pointless. OPERATIONALLY, your scheme does the same as mine/Arnold's in all the central features. CONCEPTUALLY, it also does the same because you, like I, draw conclusions such as "everywhere defined on the box" -- as Nate does, to justify his B&B algorithm.
John et al,
(I am going to discuss something a bit off topic here but
I believe it touches on this issue.)
While I do not agree that 'static versus tracking' is
pointless, I agree it can be MADE pointless.
It depends on whether or not you want them to participate
in inclusion isotonocity.
During our face-to-face last week (which was, for me,
a phone-to-face :-), Jurgen took the position that they
should NOT participate. Which I pointed out made the
FTDIA no different than the FTIA. Jurgen took this as
a good thing.
I do not agree. For if there are no inclusion isotonicity
rules to be applied to decorations then I believe we risk
having decorations THEMSELVES verge on uselessness.
I believe the whole point of an FTDIA is to make
decorations something that can be counted on when searching
through intervals for some nugget of truth.
(This is not entirely true. Decorations can also have a
diagnostic function. But even this must allow one to search
for the bug in a sensible manner.)
This is part of why I moved from tracking to static some
months ago. But it is not required.
You see, I will go so far as to agree that the distinction
is subtle. Indeed, I would be OK with a tracking
interpretation so long as inclusion isotonicity preserves
some sort of sensible partial ordering on decorations.
But in our face to face, someone (Jurgen?) cited examples
in which decorations could get both stronger & weaker in
subsets compared to the outer set.
I believe we should not permit this.
I would go so far as to say that we should define (shall)
the inclusion isotonicity behavior of decorations BEFORE
we define their tracking characteristics. The FTDIA will
follow from that alone.
After that, any inheritance behavior that does not violate
the FTDIA is fine with me.
Look into it if you like. I believe you will find that
some tracking behaviors are excluded by the requirement
of inclusion isotonicity alone.
Yours,
Dan
>
> ("Non-central" features are stuff like: how many decoration values we support; whether the intersection of decorated intervals returns a bare, or a decorated, interval; "bare object" arithmetic. Those are issues of design, not of fact.)
>
> No FTDIA is needed?? Of course it's needed, for exactly the same reason as an FTIA is needed:
>
> Us, to Interested Person (IP):
> "What we call applying straight-forward interval computation to a function
> over a box always gives an interval enclosing the range of the function ..."
> IP: "Amazing! I find it hard to believe. What, always?"
> Us: "Yes, always."
> IP: "Even on a computer, with roundoff error? Convince me!"
> Us: "Even then. Well, we have to be more precise about what functions it applies
> to and how to do it on a computer... Now to tell you just why it's true..."
> ... Proceed to explain proof of FTIA.
>
> Us, again, to IP:
> "You know we were discussing straight-forward interval computation. Well,
> we have this new method that can tell you if the function is continuous on
> the box, and stuff like that."
> IP: "Wow. Even harder to believe. What, always?"
> Us: "Well, sometimes the function is continuous but the method can't tell.
> But when it SAYS continuous, then the function is guaranteed to be
> continuous."
> IP: "Even on a computer, with roundoff error? Convince me!"
> Us: "Even then. Well, we have to be more precise...
> Now to tell you just why it's true..."
> ... Proceed to explain proof of FTDIA.
>
> That's what the FTDIA is! Merely a justification that the method (decorations in this case) gives valid results.
>
> And, guys, you have an FTDIA. Your FTIA is Theorem 2, and your FTDIA is Theorem 3. But your Theorem 3 is either FALSE, or means something other than its obvious meaning, see my 19 July email (below) to you, Jürgen, which according to my records you haven't answered.
>
> But you write in 2.2 "We do NOT need a version of the FTIA concerning decorations". What would you? When the Interested Person says "Convince me!" are you just going to say "Umm, well it seems to work"??
>
> So I urge P1788 members to vote against this Motion 27 document in its present form. Being informal is fine, but crucial assertions being vague to the point of allowing utterly conflicting interpretations (like Theorem 3) is not fine. Basing the standard on "Umm, well it seems to work" instead of "This is why it works" is not fine.
>
> There are also technical slips. Since one wants to understand what one is voting on, that is not fine. The main one, I think, is that Definition 7 line 2 indicates that a Decorated Expression Tree (DET) is a pair (t,d), while line 3 contradicts this, saying it is (recursively) a tuple ((f,df),(t_1,d_1),...,(t_k,d_k)). I suspect it should say
> "If t_1,...,t_k are DETs and f is a k-ary decorated function then t = ((f,df),t_1,...,t_k) is a DET".
>
> (Then the decoration associated with t is the df extracted from the head of this list.)
>
> In the next day or two I aim to re-issue the Motion 26 document with a PROOF of its FTDIA appended. This proof has become remarkably short. Its correctness has now been attested by Ned Nedialkov, and I am waiting for it to be attested also by Arnold Neumaier, who has contributed greatly to it.
>
> Regards
>
> John Pryce
>
> . . .