Reasons to vote Motion 27: NO
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.
("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
On 19 Jul 2011, at 06:51, John Pryce wrote:
> Jürgen
> Would you like to clarify to the group whether your Theorem 3 means what I think, or what Nate thinks?
> John
>
> On 16 Jul 2011, at 18:13, Nate Hayes wrote:
>>> JDP: I disagree with the omitted bit
>>>> NH: (which is what Theorem 3 says)
>>> JDP: Theorem 3 is imprecisely stated, but the only meaning I can attribute to
>>> it is
>>> (Computed decoration of f over xx) <= (true decoration of f over xx).
>>>
>>> IF THAT IS ALL ONE CAN TRUST TO BE TRUE, one cannot justify your B&B
>>> method.
>>
>> Ok. Thanks for the clarification.
>>
>> However, in my reading of the text, it simply says (in so many words):
>>
>> "By Definition 8, the worst decoration in the DET is propagated to the
>> end."
>>
>> That's all the B&B method requires, so in this interpretation Theorem 3 is
>> valid.
>>
>>> So I stand by what I said. The algorithm is right,
>>
>> Yes.
>>
>>> the theory is wrongly stated.
>>
>> As noted, I don't see it gives the meaning you ascribe to it above.
>>
>> In any case, I wouldn't object wordsmithing it for better clarity, so it
>> doesn't have double meanings depending on one's interpretation of the text.