Thread Links			Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Re: OFFICIAL result, Motion 26 FAILS

To: stds-1788@xxxxxxxxxxxxxxxxx
Subject: Re: OFFICIAL result, Motion 26 FAILS
From: Ian McIntosh <ianm@xxxxxxxxxx>
Date: Mon, 22 Aug 2011 21:21:43 -0400
Delivered-to: mhonarc@xxxxxxxxxxxxxxxx
In-reply-to: <6EA2C530-9D31-4D1B-8A23-35E0249F124C@xxxxxxxxxxxxx>
List-help: <http://listserv.ieee.org/cgi-bin/wa?LIST=STDS-1788>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO%20STDS-1788>
List-owner: <mailto:STDS-1788-request@LISTSERV.IEEE.ORG>
List-subscribe: <mailto:STDS-1788-subscribe-request@LISTSERV.IEEE.ORG>
List-unsubscribe: <mailto:STDS-1788-unsubscribe-request@LISTSERV.IEEE.ORG>
References: <6EA2C530-9D31-4D1B-8A23-35E0249F124C@xxxxxxxxxxxxx>
Sender: stds-1788@xxxxxxxx

My suggestion is that the work on decorations continue by discussing what all the requirements should be, without worrying yet about the implementation.

- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development

"Corliss, George" ---08/18/2011 09:44:24 PM---P1788,

From:
"Corliss, George" <george.corliss@xxxxxxxxxxxxx>

To:
Ian McIntosh/Toronto/IBM@IBMCA

Date:
08/18/2011 09:44 PM

Subject:
OFFICIAL result, Motion 26 FAILS

P1788, Official tally: M0026.01: Yes - 17; No - 21 Required for quorum: 36 (with two additions to the roster) Discussion messages, especially reasons for voting "No", are appended below. There is no new, and much redundant, information here. My hope is that by collecting all messages I find offering opinions and arguments on Motion 26, the concept of decorations may be refined. M0028.01 Containment Only (Walster/Zuras) is open for discussion through 2011-08-25 (Thursday) George Corliss P1788 Voting Tabulator Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Motion 26: NO > Date: July 28, 2011 10:34:08 AM CDT > To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > I vote no on Motion 26. > > To summarize, here are a few reasons: > > -- I don't believe the theory as presented in Motion 26 is valid (e.g., > there are still contradictions, pointed out earlier by Vincent Lefevre). > > -- The bounded decoration is problematic, and I don't know an > algorithm that requires it. > > -- At Level 1, there should not be anything ill-formed. > > -- Not giving any specification for how intersection and union handle > decorations means users will invent their own (probably wrong) rules, i.e., > what is the standard? Examples were given that show how incorrect handling > of decorations with intersection or union can lead to catastrophic failures, > so this is not something that should be left up to users. > > -- Structural induction (Motion 27-A1) is enough; we don't need a FTDIA > to compute decorations reliably when composing elementary operations into > complicated _expression_ trees. Note the structural induction method has > precedent: it was used in the thesis of Jeff Tupper and his GrafEq program. > > -- If an implementer is using other methods (like endpoint analysis) to > add a function to an interval library, only the definitions for decorations > in Motion 27-A1 are required. > > Sincerely, > > Nate Hayes > Sunfish Studio, LLC Begin forwarded message: > From: Arnold Neumaier <arnold.neumaier@xxxxxxxxxxxx> > Subject: Re: Motion 26: NO > Date: July 28, 2011 1:46:59 PM CDT > To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On Thu, July 28, 2011 17:34, Nate Hayes wrote: >> >> -- Not giving any specification for how intersection and union handle >> decorations means users will invent their own (probably wrong) rules, >> i.e., >> what is the standard? Examples were given that show how incorrect handling >> of decorations with intersection or union can lead to catastrophic >> failures, >> so this is not something that should be left up to users. > > I had given an example where Motion 27 gives erroneous results for > decorated intersections: > > The _expression_ f(x)= x/((x+1) intersect x^2) is undefined for any x in > [1,3], but Definition 7 claims a safe answer for f([1,3]). > > It is far better to have no decorations at all for union and intersection > than to have decorations based on a logically faulty basis. > > According to Motion 26 (which explicitly forbids mixed bare/decorated > interval operations), such users will get an error when trying to > propagate intersections with decorations. Thus they'll not use it. If they > work around these errors by decorating things by hand, it is at their own > risk, as in any programming language. > > The inexperienced user will probably use union and intersection only for > handling domains (where no decorations are required), not for handling > ranges. The latter requires expertise no matter how the decoration > scheme is devised. > > > Arnold Neumaier Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Intersection example (was Re: Motion 26: NO) > Date: July 28, 2011 3:30:02 PM CDT > To: Arnold Neumaier <arnold.neumaier@xxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Arnold Neumaier wrote: >>> -- Not giving any specification for how intersection and union handle >>> decorations means users will invent their own (probably wrong) rules, >>> i.e., >>> what is the standard? Examples were given that show how incorrect >>> handling >>> of decorations with intersection or union can lead to catastrophic >>> failures, >>> so this is not something that should be left up to users. >> >> I had given an example where Motion 27 gives erroneous results for >> decorated intersections: >> >> The _expression_ f(x)= x/((x+1) intersect x^2) is undefined for any x in >> [1,3], but Definition 7 claims a safe answer for f([1,3]). > > Arnold, this is not any example of erroneous results. > > First of all: > > ( [1,3] + 1 ) intersect [1,3]^2 > = [2,4] intersect [1,9] > = [2,4] > > and [1,3] / [2,4] = [1/4,3/2]. The function is not undefined anywhere on > [1,3]. > > I'm assuming instead you meant f(x) = u(x) intersect v(x) where > u(x) = x/(x+1) > v(x) = x^2. > In this case u([1,3]) = [1/4,3/2] and v([1,3]) = [1,9]. The intersection of > the true ranges of u([1,3]) and v([1,3]) is empty; but even in this case the > decoration must be safe since u([1,3]) and v([1,3]) are continuous. The > nonempty intersection caused by overestimation is safe for the same reasons. > > As I've noted several times before, giving another semantics for the > intersection operation leads to catastophic failures in certain algorithms, > like those depicted in the PDF attached to: > http://grouper.ieee.org/groups/1788/email/msg03570.html> > > >> It is far better to have no decorations at all for union and intersection >> than to have decorations based on a logically faulty basis. > > You have not demonstrated a faulty basis in providing the decorations; but > IMHO give another example why they are necessary. > > Nate Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Intersection example (was Re: Motion 26: NO) > Date: July 28, 2011 3:30:02 PM CDT > To: Arnold Neumaier <arnold.neumaier@xxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Arnold Neumaier wrote: >>> -- Not giving any specification for how intersection and union handle >>> decorations means users will invent their own (probably wrong) rules, >>> i.e., >>> what is the standard? Examples were given that show how incorrect >>> handling >>> of decorations with intersection or union can lead to catastrophic >>> failures, >>> so this is not something that should be left up to users. >> >> I had given an example where Motion 27 gives erroneous results for >> decorated intersections: >> >> The _expression_ f(x)= x/((x+1) intersect x^2) is undefined for any x in >> [1,3], but Definition 7 claims a safe answer for f([1,3]). > > Arnold, this is not any example of erroneous results. > > First of all: > > ( [1,3] + 1 ) intersect [1,3]^2 > = [2,4] intersect [1,9] > = [2,4] > > and [1,3] / [2,4] = [1/4,3/2]. The function is not undefined anywhere on > [1,3]. > > I'm assuming instead you meant f(x) = u(x) intersect v(x) where > u(x) = x/(x+1) > v(x) = x^2. > In this case u([1,3]) = [1/4,3/2] and v([1,3]) = [1,9]. The intersection of > the true ranges of u([1,3]) and v([1,3]) is empty; but even in this case the > decoration must be safe since u([1,3]) and v([1,3]) are continuous. The > nonempty intersection caused by overestimation is safe for the same reasons. > > As I've noted several times before, giving another semantics for the > intersection operation leads to catastophic failures in certain algorithms, > like those depicted in the PDF attached to: > http://grouper.ieee.org/groups/1788/email/msg03570.html> > > >> It is far better to have no decorations at all for union and intersection >> than to have decorations based on a logically faulty basis. > > You have not demonstrated a faulty basis in providing the decorations; but > IMHO give another example why they are necessary. > > Nate Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Intersection example (was Re: Motion 26: NO) > Date: July 31, 2011 2:16:37 PM CDT > To: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Arnold Neumaier wrote: >> On 07/28/2011 10:30 PM, Nate Hayes wrote: >>> Arnold Neumaier wrote: >>>>> -- Not giving any specification for how intersection and union handle >>>>> decorations means users will invent their own (probably wrong) rules, >>>>> i.e., >>>>> what is the standard? Examples were given that show how incorrect >>>>> handling >>>>> of decorations with intersection or union can lead to catastrophic >>>>> failures, >>>>> so this is not something that should be left up to users. >>>> >>>> I had given an example where Motion 27 gives erroneous results for >>>> decorated intersections: >>>> >>>> The _expression_ f(x)= x/((x+1) intersect x^2) is undefined for any x in >>>> [1,3], but Definition 7 claims a safe answer for f([1,3]). >>> >>> Arnold, this is not any example of erroneous results. >>> >>> First of all: >>> >>> ( [1,3] + 1 ) intersect [1,3]^2 >>> = [2,4] intersect [1,9] >>> = [2,4] >>> >>> and [1,3] / [2,4] = [1/4,3/2]. The function is not undefined anywhere on >>> [1,3]. >> >> Your argument proves nothing. For example, the _expression_ is undefined for >> x=1, for x=2, and for x=3, although all these are in [1,3]. >> >> The fact that no exception occurred in your calculation shows that the >> calculation only says something about this particular interval, not (like >> everywhere else in range computations) about the possible values of >> elements from that interval. >> >> But to be safe for the application of mathematical theorems, they must >> provide information about the functions evaluated, not just about the >> history of possible exceptions. > > > u(1) = (1+1) = 2 > v(1) = 1^2 = 1 > > f(1) = 1/(u(1) intersect v(1)) > = 1/(2 intersect 1) > = 1/empty > = empty > > The set-theoretic intersection of u(1) and v(1) is empty and is not > undefined (it is safe). > > f(1) =1/empty is not undefined, it is safe because the input is empty. > > So why is f(1) undefined? > > >> >> >>> As I've noted several times before, giving another semantics for the >>> intersection operation leads to catastophic failures in certain >>> algorithms, >>> like those depicted in the PDF attached to: >>>http://grouper.ieee.org/groups/1788/email/msg03570.html>> >> I consider this a misuse of the intersection operation, which happens to >> work in this particular case although there is no coherent semantics >> behind it. > > The coherent semantics are: the set-theoretic intersection operation is safe > if its operands are safe. By this semantic it is a valid application and not > a misuse. > > It is only misuse if one chooses to give some other definition/semantic for > the intersection operation. But you and John are not proposing any such > alternative. > > > > >> The mathematically correct way of treating your example (with >> identical results) was given by John Pryce some time ago. > > IMO all John did was sidestep the issue by using addition. > > Nate Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Intersection example (was Re: Motion 26: NO) > Date: July 31, 2011 3:21:54 PM CDT > To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Arnold Neumaier wrote: >> On 07/31/2011 09:16 PM, Nate Hayes wrote: >>> Arnold Neumaier wrote: >>>> On 07/28/2011 10:30 PM, Nate Hayes wrote: >>>>> Arnold Neumaier wrote: >>>>>> I had given an example where Motion 27 gives erroneous results for >>>>>> decorated intersections: >>>>>> >>>>>> The _expression_ f(x)= x/((x+1) intersect x^2) is undefined for any x in >>>>>> [1,3], but Definition 7 claims a safe answer for f([1,3]). >>>>> >>>>> Arnold, this is not any example of erroneous results. >>>>> >>>> For example, the _expression_ is undefined >>>> for >>>> x=1, for x=2, and for x=3, although all these are in [1,3]. >>> >>> u(1) = (1+1) = 2 >>> v(1) = 1^2 = 1 >>> >>> f(1) = 1/(u(1) intersect v(1)) >>> = 1/(2 intersect 1) >>> = 1/empty >>> = empty >>> >>> The set-theoretic intersection of u(1) and v(1) is empty and is not >>> undefined (it is safe). >> >> Never before I was told that the set theoretic intersection of two numbers >> should be empty. >> >> >> There are three main traditions for defining numbers. >> >> In Zermelo-Fraenkel set theory, the intersection of two cardinal numbers >> is the smaller one. >> >> In Dedekind's definition of real numbers as , the intersection of two real >> numbers is also the smaller one. >> >> In Peano's definition of natural number, the intersection of two natural >> numbers is undefined. >> >> In no case, the intersection is empty. > > My understanding is the "meet" between two real numbers (usually symbolized > by the upside-down vee) is the smaller of the two numbers: > 1 meet 2 = 1 > this is different than the set-theoretic intersection (symbolized by the > cap) of two singleton sets: > [1,1] intersect [2,2] = empty > e.g., this is why in modal intervals there is meet operation but no > intersection operation (and hence no empty set), eg.: > [1,1] meet [2,2] = [2,1]. > But P1788 so far (that I'm aware of) only considers the intersection of > singleton sets, so I assume in your example > 1 intersect 2 > is meant to be shorthand for > [1,1] intersect [2,2]. > > Nate Begin forwarded message: > From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Subject: Re: Intersection example (was Re: Motion 26: NO) > Date: August 1, 2011 6:01:49 AM CDT > To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 07/31/2011 10:21 PM, Nate Hayes wrote: >> Arnold Neumaier wrote: >>> On 07/31/2011 09:16 PM, Nate Hayes wrote: >>>> Arnold Neumaier wrote: >>>>> On 07/28/2011 10:30 PM, Nate Hayes wrote: >>>>>> Arnold Neumaier wrote: >>>>>>> I had given an example where Motion 27 gives erroneous results for >>>>>>> decorated intersections: >>>>>>> >>>>>>> The _expression_ f(x)= x/((x+1) intersect x^2) is undefined for any >>>>>>> x in >>>>>>> [1,3], but Definition 7 claims a safe answer for f([1,3]). >>>>>> >>>>>> Arnold, this is not any example of erroneous results. >>>>>> >>>>> For example, the _expression_ is undefined >>>>> for >>>>> x=1, for x=2, and for x=3, although all these are in [1,3]. >>>> >>>> u(1) = (1+1) = 2 >>>> v(1) = 1^2 = 1 >>>> >>>> f(1) = 1/(u(1) intersect v(1)) >>>> = 1/(2 intersect 1) >>>> = 1/empty >>>> = empty >>>> >>>> The set-theoretic intersection of u(1) and v(1) is empty and is not >>>> undefined (it is safe). >>> >>> Never before I was told that the set theoretic intersection of two >>> numbers >>> should be empty. >>> >>> >>> There are three main traditions for defining numbers. >>> >>> In Zermelo-Fraenkel set theory, the intersection of two cardinal numbers >>> is the smaller one. >>> >>> In Dedekind's definition of real numbers as , the intersection of two >>> real numbers is also the smaller one. >>> >>> In Peano's definition of natural number, the intersection of two natural >>> numbers is undefined. >>> >>> In no case, the intersection is empty. >> >> My understanding is the "meet" between two real numbers (usually symbolized >> by the upside-down vee) is the smaller of the two numbers: >> 1 meet 2 = 1 >> this is different than the set-theoretic intersection (symbolized by the >> cap) of two singleton sets: >> [1,1] intersect [2,2] = empty > > Set theoretically, a number x is always distinct from the singleton set {x} containing it. In particular, in ZF set theory, with the standard definition given e.g., inhttp://en.wikipedia.org/wiki/Natural_number#Constructions_based_on_set_theory , > we have {0}=1, and the set-theoretic intersection (symbolized by the cap) of the natural numbers m and n is > m \cap n = min(m,n). > > >> e.g., this is why in modal intervals there is meet operation but no >> intersection operation (and hence no empty set), eg.: >> [1,1] meet [2,2] = [2,1]. > > We are not discussing modal arithmetic but standard interval arithmetic. > > >> But P1788 so far (that I'm aware of) only considers the intersection of >> singleton sets, so I assume in your example >> 1 intersect 2 >> is meant to be shorthand for >> [1,1] intersect [2,2]. > > If you argue that the meaning of an _expression_ for real input is the special case of the meaning of the corresponding interval _expression_, you'd also conclude that > 1/0=[1,1]/[0,0]=Empty, 0/0=[0,0]/[0,0]=Entire, > If this argumentation applies, division is always defined, and the decoration should be at least def. (Though this is useless for the applications.) > > But so far in P1788, the argumentation was _always_ the reverse: the interval _expression_ gets its semantics from the corresponding real _expression_. (This is the mode needed in the applications.) > If this argumentation applies, intersection is not always defined, > and the decoration should be at most con. > > Your scheme violates the conclusion of both cases. > > > Arnold Neumaier Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Intersection example (was Re: Motion 26: NO) > Date: August 1, 2011 9:36:20 AM CDT > To: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Arnolde Neumaier wrote: >> On 07/31/2011 10:21 PM, Nate Hayes wrote: >>> Arnold Neumaier wrote: >>>> On 07/31/2011 09:16 PM, Nate Hayes wrote: >>>>> Arnold Neumaier wrote: >>>>>> On 07/28/2011 10:30 PM, Nate Hayes wrote: >>>>>>> Arnold Neumaier wrote: >>>>>>>> I had given an example where Motion 27 gives erroneous results for >>>>>>>> decorated intersections: >>>>>>>> >>>>>>>> The _expression_ f(x)= x/((x+1) intersect x^2) is undefined for any >>>>>>>> x in >>>>>>>> [1,3], but Definition 7 claims a safe answer for f([1,3]). >>>>>>> >>>>>>> Arnold, this is not any example of erroneous results. >>>>>>> >>>>>> For example, the _expression_ is undefined >>>>>> for >>>>>> x=1, for x=2, and for x=3, although all these are in [1,3]. >>>>> >>>>> u(1) = (1+1) = 2 >>>>> v(1) = 1^2 = 1 >>>>> >>>>> f(1) = 1/(u(1) intersect v(1)) >>>>> = 1/(2 intersect 1) >>>>> = 1/empty >>>>> = empty >>>>> >>>>> The set-theoretic intersection of u(1) and v(1) is empty and is not >>>>> undefined (it is safe). >>>> >>>> Never before I was told that the set theoretic intersection of two >>>> numbers >>>> should be empty. >>>> >>>> >>>> There are three main traditions for defining numbers. >>>> >>>> In Zermelo-Fraenkel set theory, the intersection of two cardinal numbers >>>> is the smaller one. >>>> >>>> In Dedekind's definition of real numbers as , the intersection of two >>>> real numbers is also the smaller one. > > [...] > >>> But P1788 so far (that I'm aware of) only considers the intersection of >>> singleton sets, so I assume in your example >>> 1 intersect 2 >>> is meant to be shorthand for >>> [1,1] intersect [2,2]. >> >> If you argue that the meaning of an _expression_ for real input is the >> special case of the meaning of the corresponding interval _expression_, >> you'd also conclude that >> 1/0=[1,1]/[0,0]=Empty, 0/0=[0,0]/[0,0]=Entire, >> If this argumentation applies, division is always defined, and the >> decoration should be at least def. (Though this is useless for the >> applications.) > > > Motion 5 says: > "when evaluating a function... points outside its domain are simply > ignored" > > > >> But so far in P1788, the argumentation was _always_ the reverse: the >> interval _expression_ gets its semantics from the corresponding real >> _expression_. (This is the mode needed in the applications.) >> If this argumentation applies, intersection is not always defined, >> and the decoration should be at most con. >> >> Your scheme violates the conclusion of both cases. > > > Motion 5 says: > "the result of an operation is a set" > So the intersection operation in the function does not operate on real > numbers. > > Nate Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Reasons to vote Motion 27: NO > Date: August 1, 2011 3:36:07 PM CDT > 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. > > ("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 Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 1, 2011 4:43:05 PM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > John Pryce wrote: >> That's what the FTDIA is! Merely a justification that the method (decorations in this case) gives valid results. > > John, be careful. Your theorem in its present form has contradictions, so it can't be valid. The contradictions were pointed out by Vincent Lefevre, and you aknowledged them. But neither you nor Arnold ever addressed this. > > Also, you have no coherent theory for intersection and union. Saying there should be no standard for these operations is less than a mathematical punt: it is simply not acceptable. > > > >> 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"?? > > The propagation of decorations from the leafs of the DET to the root is a proof by structural induction. After all this time, do you seriously still not understand that? Tupper already knew this many years ago... > > > P1788 appears to be at a crossroads. John, we've been having this argument for almost a whole year now, but I am NOT convinced. > > As I've noted before, I'm along for the ride to the end, for better or worse. My continued participation in P1788 is not contingent on any particular motion passing. However, I am pretty skeptical at this point P1788 will succeed unless it passes Motion 27-A1. > > Nate Begin forwarded message: > From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx> > Subject: Re: Reasons to vote Motion 27: NO > Date: August 1, 2011 8:25:35 PM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx> > Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx> > >> 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 Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 2, 2011 5:50:37 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Nate > > On 1 Aug 2011, at 17:43, Nate Hayes wrote: >> John Pryce wrote: >>> That's what the FTDIA is! Merely a justi fication that the method (decorations in this case) gives valid results. >> >> John, be careful. Your theorem in its present form has contradictions, so it can't be valid. The contradictions were pointed out by Vincent Lefevre, and you aknowledged them. But neither you nor Arnold ever addressed this. > > Vincent, please remind me what those were. Finding the source of contradictions is one function of a proof. The shorter the proof the easier to find any contradictions. Either the proof has wrong steps (which, because of its increased simplicity, I now doubt) or the hypotheses of the theorem are in dispute (much more likely). > >> Also, you have no coherent theory for intersection and union. Saying there should be no standard for these operations is less than a mathematical punt: it is simply not acceptable. > > I do indeed have a coherent theory, clearly stated. It is that no coherent theory exists. More precisely: > On 1 Jul 2011, at 06:07, John Pryce wrote: >> My rationale is that ALL the various examples so far shown build to the conclusion that union/intersection are not free-standing operations in the way that, say, an interval extension of a point function is. Their decoration logic is too contingent on the environment in which they are used, to be fixed in this standard. If we do fix it, these operations will become illustrations of the proverb "If all you have is a hammer, everything looks like a nail". > > Please write, and put in your library, a decorated version of intersection that fits your applications. Offer its API for general use. Let others do the same. Just ensure they all have different names. Those that are seen to be useful in several contexts will become popular. At some future date when 1788 is revised, the popular ones can become part of the standard. > > Finally >> The propagation of decorations from the leafs of the DET to the root is a proof by structural induction. > NO! It is a mechanism. You are confusing two concepts of "proof". I suspect you have been doing so for a long time. > > Each correctly formed piece of decorated interval code, applied to an instance of data, instantiates a proof that a specific function has certain properties over a specific box. E.g., f(x) = sqrt(1-x) applied to xx=[0.36,0.99], using decorated library functions (and exact arithmetic!), gives a sequence of computations summarised by > sqrt( [1,1]_saf - [0.36,0.99]_saf ) = sqrt( [0.01,0.64]_saf ) = [0.1,0.8]_saf (*) > > > thus instantiating a "proof" that sqrt(1-x) is defined and continuous on this box xx, and its range over xx is contained in [0.1,0.8]. But that "proof" only is a bona-fide proof IF THE MECHANISM IS VALID. > > An FTDIA, or any similar theorem of that kind, is a proof that the mechanism is valid: that the mechanism always spews out correct instances of proofs. You could regard it as a "meta-proof". > > It's much the same as a compiler. Indeed, a debugging compiler could be taught to print out stuff like (*) to help humans check what it is doing. But if there is a bug in the compiler, then the "proof"-instance described by (*) may not be a proof at all, no matter how much you argue that "it is structural induction". > > To summarise: a compiler generates code. But is it correct code? Bluntly put, you only seem interested in running the code, whereas I am interested in validating the compiler. > > John Begin forwarded message: > From: "J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > Subject: Re: Reasons to vote Motion 27: NO > Date: August 2, 2011 7:23:12 AM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Am 01.08.2011 22:36, schrieb John Pryce: >> 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. >> .. . >> 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. > Theorem 3 means that the _expression_ given as an extention of a function is calculated by a DET following(1). > > Theorem 3 reformulated > Given a DET f~ for an extension of f. The mechanism (1) then calculates a decorated interval (e,d) where d<= di for all di appearing in the DET > That gives a proof that only functions with properties described by the decoration d have been applied > if d = saf f is everywhere defined and continuous > if d = def f is everywhere defined >> 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. >> > Intersection is included since it is very common in interval computations. > Arnold's example shows a peculiar fact that a function can be undefined for each point interval but is defined for the full interval [1,3] > That is no contradiction to theorem 3 because we there is no intersection of real numbers. >> 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.) >> > yes, sorry, i read my definition like this. Perhaps I should have left out the $t=$ in line 3 >> 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 > Juergen Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: FTDIA revisited > Date: August 2, 2011 10:03:32 AM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > John Pryce wrote: >> Finally >>> The propagation of decorations from the leafs of the DET to the root is a >>> proof by structural induction. >> NO! It is a mechanism. You are confusing two concepts of "proof". > > Yes, structural induction is a proof method, e.g.. > http://en.wikipedia.org/wiki/Structural_induction> and this is tightly coupled to the implementation in code. I think this much we agree. > >> I suspect you have been doing so for a long time. >> >> Each correctly formed piece of decorated interval code, applied to an >> instance of data, instantiates a proof that a specific function has >> certain properties over a specific box. E.g., f(x) = sqrt(1-x) applied to >> xx=[0.36,0.99], using decorated library functions (and exact arithmetic!), >> gives a sequence of computations summarised by >> sqrt( [1,1]_saf - [0.36,0.99]_saf ) = sqrt( [0.01,0.64]_saf ) = >> [0.1,0.8]_saf (*) >> >> >> thus instantiating a "proof" that sqrt(1-x) is defined and continuous on >> this box xx, and its range over xx is contained in [0.1,0.8]. But that >> "proof" only is a bona-fide proof IF THE MECHANISM IS VALID. >> >> An FTDIA, or any similar theorem of that kind, is a proof that the >> mechanism is valid: that the mechanism always spews out correct instances >> of proofs. You could regard it as a "meta-proof". > > Yes, I understand. > >> >> It's much the same as a compiler. Indeed, a debugging compiler could be >> taught to print out stuff like (*) to help humans check what it is doing. >> But if there is a bug in the compiler, then the "proof"-instance described >> by (*) may not be a proof at all, no matter how much you argue that "it is >> structural induction". > > Yes. > >> >> To summarise: a compiler generates code. But is it correct code? Bluntly >> put, you only seem interested in running the code, whereas I am interested >> in validating the compiler. > > I agree with Jurgen, e.g., that > Given a DET f~ for an extension of f. The mechanism (1) then > calculates a decorated interval (e,d) where d<= di for all di appearing > in the DET > That gives a proof that only functions with properties described by the > decoration d have been applied > if d = saf f is everywhere defined and continuous > if d = def f is everywhere defined > etc. > This can all be done at LEvel 1 to verify a compiler, if one wishes. However, the main purpose of IEEE 1788 is to standardize the computation of interval expressions. > > BTW: > > I don't object to the idea of FTDIA, but I am rather convinced the "containment order" formulation in Motion 26 is not valid. For example, def is set of all (f,xx) pairs with nonempty xx and ein is set of all (f,xx) pairs with empty xx. But ein is a subset of def?? > > Dominique once showed me a formulation that instead uses the special comparison operator <=_DI such that for two decorated intervals: > > (I1,D1) <=_DI (I2,D2) <==> I2 \subseteq I1 and D1 <=_D D2 > > where <=_D is the order > > con <=_D def <=_D dac <=_D ein > con <=_D ndf <=_D ein > > I think this is likely to be a more promising direction to try and formulate a FTDIA. > > Nate Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 2, 2011 11:06:42 AM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > >> On 1 Jul 2011, at 06:07, John Pryce wrote: >>> My rationale is that ALL the various examples so far shown build to the >>> conclusion that union/intersection are not free-standing operations in >>> the way that, say, an interval extension of a point function is. Their >>> decoration logic is too contingent on the environment in which they are >>> used, to be fixed in this standard. If we do fix it, these operations >>> will become illustrations of the proverb "If all you have is a hammer, >>> everything looks like a nail". > > Once can also view this position as a cop-out. I mean, what is the purpose > of having all the formalism for a FTDIA if a user's program can no longer be > validated by it as soon as they include a single intersection or union > operation? > > Intersection and union are very common operations in interval programs and > algorithms... so perhaps the majority of programs will be beyond the reach > of FTDIA to verify. > > For me, this is not convincing. > > Nate Begin forwarded message: > From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 2, 2011 11:51:36 AM CDT > To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Cc: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 08/02/2011 06:06 PM, Nate Hayes wrote: > > >> I mean, what is the purpose >> of having all the formalism for a FTDIA if a user's program can no >> longer be >> validated by it as soon as they include a single intersection or union >> operation? >> >> Intersection and union are very common operations in interval programs and >> algorithms... > > Motion 26 has a concept of intersection and union, hence supports all such calculations. But for safety reasons it requires that the result is always a bare interval -- since the decoration it should get (if any) must depend on the context. > > >> so perhaps the majority of programs will be beyond the reach >> of FTDIA to verify. > > Traditional interval arithmetic without decorations has no FTIA for computations with intersection. Nevertheless, many verifying interval algorithms using intersection are in use. > > Interval techniques usually validate things without decorations - otherwise they couldn't have thrived in the past. > > For verification, decorations are only needed for checking the hypotheses of fixed point theorems. Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 2, 2011 12:35:21 PM CDT > To: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Cc: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Arnold Neumaier wrote: >>> I mean, what is the purpose >>> of having all the formalism for a FTDIA if a user's program can no >>> longer be >>> validated by it as soon as they include a single intersection or union >>> operation? >>> >>> Intersection and union are very common operations in interval programs >>> and >>> algorithms... >> >> Motion 26 has a concept of intersection and union, hence supports all such >> calculations. But for safety reasons it requires that the result is always >> a bare interval -- since the decoration it should get (if any) must depend >> on the context. > > Can you please give several real-world (Level 1) examples demonstrating each different context? > > I'm very skeptical of this statement. > > > >>> so perhaps the majority of programs will be beyond the reach >>> of FTDIA to verify. >> >> Traditional interval arithmetic without decorations has no FTIA for >> computations with intersection. Nevertheless, many verifying interval >> algorithms using intersection are in use. > > IMO, this will be true for decorated intervals, as well, and is why > decoration semantics for these operations need to be standardized (not left > to chance). > > Note: the bare semantics of intersection and union are pretty much > standardized even in such existing cases. > > Second note: most existing semantics that I'm aware of have intersection and > union operating on sets (as in Motion 27), not real numbers. > > > >> Interval techniques usually validate things without decorations - >> otherwise they couldn't have thrived in the past. >> >> For verification, decorations are only needed for checking the hypotheses >> of fixed point theorems. > > Hmmm. I've already seen/given examples for other purposes, e.g., finding the > common domain where two functions are both defined but not necessarily > equal. > > Nate Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 2, 2011 6:51:16 PM CDT > To: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Arnold Neumaier wrote: >> On 08/02/2011 07:35 PM, Nate Hayes wrote: >>> Arnold Neumaier wrote: >>>>> I mean, what is the purpose >>>>> of having all the formalism for a FTDIA if a user's program can no >>>>> longer be >>>>> validated by it as soon as they include a single intersection or union >>>>> operation? >>>>> >>>>> Intersection and union are very common operations in interval programs >>>>> and >>>>> algorithms... >>>> >>>> Motion 26 has a concept of intersection and union, hence supports all >>>> such >>>> calculations. But for safety reasons it requires that the result is >>>> always >>>> a bare interval -- since the decoration it should get (if any) must >>>> depend >>>> on the context. >>> >>> Can you please give several real-world (Level 1) examples demonstrating >>> each different context? >>> >>> I'm very skeptical of this statement. >> >> Apparently there are not just a few different contexts; > > It should not be difficult for you to provide at least, say, three or four > such examples, then. > > > >> at least finding correct definitions of these contexts would require extra >> research. >> >> My example from the decoration file last December was of this kind. > > For those that might be trying to follow along, here is the link to what > Arnold refers to: > http://grouper.ieee.org/groups/1788/email/msg03570.html> He is speaking of the example appended to the end of the e-mail entitled > "Appendix 2: a detailed example for intersection" > (not the PDF which is also attached to that e-mail). > > The example involves the program "fgood", defined as: > > function f = fgood(x,y) > f=(2x+2y)/(2x+y); > f1=2-2/(2+y/x); > f2=1+1/(1+2x/y); > f = f intersect f1 intersect f2 > end > > In practice, fgood is simply trying to compute a tight range enclosure on f. > This is the reason for intersecting the ranges of f, f1, and f2. However, f1 > and f2 are not equivalent expressions of f. Hence, they are undefined at > different points than f. For example, f1([0,0],[3,4]) is empty/undefined > even though f([0,0],[3,4]) is safe, so taking the intersection gives an > empty/undefined result for fgood([0,0],[3,4]). > > Since the theory of decorated intersection being advocated by John and > Arnold at that point in time predicted fgood should be safe in this case, it > was evidence the theory is invalid: thankfully John has at last finally > removed those definitions for decorated intersection and union from the most > recent version of Motion 26, so it is no longer on the table (of that much I > am grateful). > > Indeed, from a purely mathematical point of view and by all standards and > interpretations, fgood([0,0],[3,4]) *SHOULD* be empty/undefined. I believe > very strongly it will never be a good idea for P1788 or any standards body > to try and invent a decoration system that gives another interpretation, as > this surley will be violation of the "thou shall not lie" commandment. > > However, we all know and understand, in practice, what Arnold is trying to > do in the fgood program: he's trying to employ (useful) programming tricks > to give tighter range enclosure on his function so his program will run
> faster. So of course in this respect what he's trying to accomplish is > completely legitimate... I do it all the time in my own software. > > The problem, therefore, is a bug in the fgood program, not the decoration > system. In particular, the expert programmer (Arnold in this case) was > thinking as he wrote the program: > > "Even though I am completely aware that f1 and f2 are not equivalent > expressions of f, I am intentionally going to take thier intersections in > order to obtain a tighter range enclosure of f, which is the function I > really care about." > > But as noted, the purpose of the decoration system is to detect that f1 and > f2 are not equivalent expressions of f and that taking their intersections > may lead to empty/undefined results. > > So the problem is: the intent of the programmer was never adequately > captured in the fgood program. (for those of you familliar with Stanley > Kubrik's "2001 Space Odessy," it is not dissimilar to the programming bug > that caused the HAL computer to go on a killing spree) > > The bottom line its not reasonable to expect a decoration system designed to > report undefined results should give a "safe" result just because the > programmer had this in mind. The intent of the programmer needs to be > expressed excplicitly in the program code of the fgood program. For example > the decorations of f1 and f2 should be checked, and the respective > intersections should be taken only of these decorations are safe. > > > >> After your response with the counterexample, I tried to find a _general_ >> rule that allows to decide when such constructions are valid without a >> separate analysis for each case, and didn't find any. > > As noted above, you will NEVER find such a general rule because it should > never exist. The decorations should never lie, even if the programmer has a > bug in the software. > > >> My conclusion (after discussing things with John Pryce, who originated the >> proposal now realized in Motion 26) was that all more than trivial >> instances require individual attention. > > If there are not any further examples, the now I am really convinced that > Motion 27-A1 must be passed. > > Nate Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Re: FTDIA revisited > Date: August 4, 2011 7:58:19 PM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Nate & P1788 > > Sorry to be late replying to this, but I'm visiting Ned Nedialkov at McMaster. He is keeping me very busy on other research topics, which has put me behind. That, and a trip to Toronto yesterday. I saw Ken Jackson at U of T, who sends his best wishes to P1788. > > On 2 Aug 2011, at 11:03, Nate Hayes wrote: >> BTW: >> >> I don't object to the idea of FTDIA, but I am rather convinced the "containment order" formulation in Motion 26 is not valid. For example, def is set of all (f,xx) pairs with nonempty xx and ein is set of all (f,xx) pairs with empty xx. But ein is a subset of def?? > > I think that was an error once, but corrected some time ago, certainly in the current version (I hope), which says >> p_ein(f,xx) : xx is empty (i.e., has some empty component); >> p_bnd(f,xx) : xx is a subset of Domain f, and the restriction of f >> to xx is continuous and bounded; >> p_dac(f,xx) : xx is a subset of Domain f, and the restriction of f >> to xx is continuous; >> p_def(f,xx) : xx is a subset of Domain f; >> p_con(f,xx) : always true; >> p_emp(f,xx) : xx is nonempty and disjoint from Domain f; >> p_ill(f,xx) : xx is nonempty and Domain f is empty. > > Note, in Motion 27 Definition 1, you have chosen to make the different p_d predicates of its scheme *logically disjoint* (exclusive), while ours get logically narrower as one goes away from con. So > your "def" is our "def and not dac" > your "con" is our "con and not def and not emp" > and so on. > > As you raise technicalities ... I raise a corresponding issue about Motion 27. Theorem 3 is FALSE as regards ndf, and I'm still waiting for your revision that will correct it. > > Suppose you do an evaluation as described in Motion 27, with the 4-decoration system. > > - If you get the result saf, then certainly Theorem 3's > "the decoration" (which I take to mean the unique d in > {saf,def,con,ndf} such that p_d(f,xx) is true) equals saf. > > - If you get def then "the decoration" can be either def or saf. > > - But if you get con? Ah, there's the rub of Motion 27. > Theorem 3's "lower bound" implies "the decoration" can be > any of con, def or saf. > NO! It could be ndf, as numerous worked examples have illustrated. > > - And if you get ndf? Theorem 3 implies "the decoration" can be > any of ndf, con, def or saf. > NO! again. If you get ndf, then the result is CERTAINLY ndf. > Nate knows this perfectly well, and knows his B&B algorithm > would not work if this were not the case. > > So, Motion 26 guys, get your act together and produce a Theorem 3 that is both understandable and true. > > John P Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 4, 2011 8:09:41 PM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > P1788 > > On 4 Aug 2011, at 13:09, Nate Hayes wrote: >> Arnold Neumaier wrote: >>> Motion 26 protects the inexperienced user, while the expert user can judge >>> for themselves how to make use of the decorations. >> >> All Motion 26 does in this regard is allow users to write unreliable >> programs. Since there is no standard, a user may run a program on one >> conforming implementation that uses a certain set of semantics and get valid >> results (by coincidence) and then run the same program on another conforming >> implementation and fail catastrophically. > > What I wrote is intended to preclude that: > On 2 Aug 2011, at 06:50, John Pryce wrote: >> Please write, and put in your library, a decorated version of intersection that fits your applications. Offer its API for general use. Let others do the same. Just ensure THEY ALL HAVE DIFFERENT NAMES. > > John Pryce Begin forwarded message: > From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 5, 2011 6:21:47 AM CDT > To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 08/04/2011 07:09 PM, Nate Hayes wrote: >> Arnold Neumaier wrote: >>> Motion 26 protects the inexperienced user, while the expert user can >>> judge >>> for themselves how to make use of the decorations. >> >> All Motion 26 does in this regard is allow users to write unreliable >> programs. Since there is no standard, a user may run a program on one >> conforming implementation that uses a certain set of semantics and get >> valid >> results (by coincidence) and then run the same program on another >> conforming >> implementation and fail catastrophically. > > One can write unreliable programs no matter how the decoration system works, since the user can always set decorations arbitrarily. > > With Motion 26, the user gets type errors when trying to use an intersection result in a decorated operation (which is the potentially unreliable bit) without having set decorations explicitly (and thereby declaing that what is done is intentional). > > With Motion 27, no such error occurs, and the result is whitewashed to safe, no matter what was going on. > > > Arnold Neumaier Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 5, 2011 9:02:39 AM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > John Pryce wrote: >> On 4 Aug 2011, at 13:09, Nate Hayes wrote: >>> Arnold Neumaier wrote: >>>> Motion 26 protects the inexperienced user, while the expert user can >>>> judge >>>> for themselves how to make use of the decorations. >>> >>> All Motion 26 does in this regard is allow users to write unreliable >>> programs. Since there is no standard, a user may run a program on one >>> conforming implementation that uses a certain set of semantics and get >>> valid >>> results (by coincidence) and then run the same program on another >>> conforming >>> implementation and fail catastrophically. >> >> What I wrote is intended to preclude that: >> On 2 Aug 2011, at 06:50, John Pryce wrote: >>> Please write, and put in your library, a decorated version of >>> intersection that fits your applications. Offer its API for general use. >>> Let others do the same. Just ensure THEY ALL HAVE DIFFERENT NAMES. > > > It doesn't matter. If an inexperienced user takes the three intersections in > the fgood program to give a bare interval result as you are suggesting, then > fgood([0,0],[3,4]) will still be empty; and this is not the intended result > (it should be nonempty). > So the program may still experience catastrophic failure. > The user in this case, however, can't be accused of writing buggy code > because by all standards in Motion 26 the user did nothing wrong. So the > mantle of responsibility for any consequences of such failure fall squarely > on this P1788 committe, should they pass the motion. > Regardless whether the motion passes or not, I would never write or > distribute such a library, as it would put me and my company at risk. > Nate Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 5, 2011 9:02:44 AM CDT > To: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Arnold Neumaier wrote: >> On 08/04/2011 07:09 PM, Nate Hayes wrote: >>> Arnold Neumaier wrote: >>>> Motion 26 protects the inexperienced user, while the expert user can >>>> judge >>>> for themselves how to make use of the decorations. >>> >>> All Motion 26 does in this regard is allow users to write unreliable >>> programs. Since there is no standard, a user may run a program on one >>> conforming implementation that uses a certain set of semantics and get >>> valid >>> results (by coincidence) and then run the same program on another >>> conforming >>> implementation and fail catastrophically. >> >> One can write unreliable programs no matter how the decoration system >> works, since the user can always set decorations arbitrarily. > > As I noted to john, the difference is where can the source of the failure be > traced back to. > With motion 27, the decorations never lie: the failure is traced back to the > user's buggy code. > With motion 26, the decorations may lie: the failure is traced back to this > P1788 committe for designing a standard that, when used "properly" still may > give unreliable results. > > >> With Motion 26, the user gets type errors when trying to use an >> intersection result in a decorated operation (which is the potentially >> unreliable bit) without having set decorations explicitly (and thereby >> declaing that what is done is intentional). > It doesn't matter. See my post to John. > In any case. Most interval programs use lots of intersection and union > operations. So this means none of them will compile if users are trying to > perform decorated calculations. > >> >> With Motion 27, no such error occurs, and the result is whitewashed to >> safe, no matter what was going on. > You have not given any of the examples I requested. > Nate Begin forwarded message: > From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 5, 2011 9:17:32 AM CDT > To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Cc: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 08/05/2011 04:02 PM, Nate Hayes wrote: >> Arnold Neumaier wrote: >>> On 08/04/2011 07:09 PM, Nate Hayes wrote: >>>> Arnold Neumaier wrote: >>>>> Motion 26 protects the inexperienced user, while the expert user can >>>>> judge >>>>> for themselves how to make use of the decorations. >>>> >>>> All Motion 26 does in this regard is allow users to write unreliable >>>> programs. Since there is no standard, a user may run a program on one >>>> conforming implementation that uses a certain set of semantics and get >>>> valid >>>> results (by coincidence) and then run the same program on another >>>> conforming >>>> implementation and fail catastrophically. >>> >>> One can write unreliable programs no matter how the decoration system >>> works, since the user can always set decorations arbitrarily. >> >> As I noted to john, the difference is where can the source of the >> failure be >> traced back to. >> With motion 27, the decorations never lie: the failure is traced back to >> the >> user's buggy code. >> With motion 26, the decorations may lie: > > No. There is a proof that they are correctly designed. > > Note that the example I had discussed in December does not conform to Motion 26, so you cannot use it to accuse Motion 26 of being buggy. > > >>> With Motion 26, the user gets type errors when trying to use an >>> intersection result in a decorated operation (which is the potentially >>> unreliable bit) without having set decorations explicitly (and thereby >>> declaing that what is done is intentional). >> It doesn't matter. See my post to John. > > I answered that just a moment ago. > > >> In any case. Most interval programs use lots of intersection and union >> operations. So this means none of them will compile if users are trying to >> perform decorated calculations. > > They get intersection results without decoration, and can continue with decorated calculations of a new range by calling the domain function. This corresponds to what is usually done in branch and bound algorithms. > > >>> With Motion 27, no such error occurs, and the result is whitewashed to >>> safe, no matter what was going on. >> You have not given any of the examples I requested. > > I gave the example y=1/(x intersect (x+1)), which is nonsense but passes a Motion 27 conforming compiler necessarily with a safe result. > > > Arnold Neumaier Begin forwarded message: > From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 5, 2011 9:17:23 AM CDT > To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Cc: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 08/05/2011 04:02 PM, Nate Hayes wrote: >> John Pryce wrote: >>> On 4 Aug 2011, at 13:09, Nate Hayes wrote: >>>> Arnold Neumaier wrote: >>>>> Motion 26 protects the inexperienced user, while the expert user can >>>>> judge >>>>> for themselves how to make use of the decorations. >>>> >>>> All Motion 26 does in this regard is allow users to write unreliable >>>> programs. Since there is no standard, a user may run a program on one >>>> conforming implementation that uses a certain set of semantics and get >>>> valid >>>> results (by coincidence) and then run the same program on another >>>> conforming >>>> implementation and fail catastrophically. >>> >>> What I wrote is intended to preclude that: >>> On 2 Aug 2011, at 06:50, John Pryce wrote: >>>> Please write, and put in your library, a decorated version of >> >> intersection that fits your applications. Offer its API for general use. >>>> Let others do the same. Just ensure THEY ALL HAVE DIFFERENT NAMES. >> >> >> It doesn't matter. If an inexperienced user takes the three >> intersections in >> the fgood program to give a bare interval result as you are suggesting, >> then >> fgood([0,0],[3,4]) will still be empty; and this is not the intended result >> (it should be nonempty). > > Which fgood function??? > > Note that the example I had discussed in December does not conform to Motion 26, so you cannot use it to accuse Motion 26 of being buggy. > > >> So the program may still experience catastrophic failure. >> The user in this case, however, can't be accused of writing buggy code >> because by all standards in Motion 26 the user did nothing wrong. > > An environment conforming to Motion 26 will get a type error when trying to execute the fgood from dec.txt. > > > Arnold Neumaier Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: FTDIA revisited > Date: August 5, 2011 9:02:34 AM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > John Pryce wrote: >> On 2 Aug 2011, at 11:03, Nate Hayes wrote: >>> BTW: >>> >>> I don't object to the idea of FTDIA, but I am rather convinced the >>> "containment order" formulation in Motion 26 is not valid. For example, >>> def is set of all (f,xx) pairs with nonempty xx and ein is set of all >>> (f,xx) pairs with empty xx. But ein is a subset of def?? >> >> I think that was an error once, but corrected some time ago, certainly in >> the current version (I hope), which says >>> p_ein(f,xx) : xx is empty (i.e., has some empty component); >>> p_bnd(f,xx) : xx is a subset of Domain f, and the restriction of f >>> to xx is continuous and bounded; >>> p_dac(f,xx) : xx is a subset of Domain f, and the restriction of f >>> to xx is continuous; >>> p_def(f,xx) : xx is a subset of Domain f; >>> p_con(f,xx) : always true; >>> p_emp(f,xx) : xx is nonempty and disjoint from Domain f; >>> p_ill(f,xx) : xx is nonempty and Domain f is empty. >> >> Note, in Motion 27 Definition 1, you have chosen to make the different p_d >> predicates of its scheme *logically disjoint* (exclusive), while ours get >> logically narrower as one goes away from con. So >> your "def" is our "def and not dac" >> your "con" is our "con and not def and not emp" >> and so on. > > Precisely. This is exactly where Dominique gets the order <=_D that I > mentioned earlier: > > con <=_D def <=_D dac <=_D ein > con <=_D ndf <=_D ein > > If (I1,D1) is the true decorated range of some function f and (I2,D2) is the > decorated interval computed by Motion 27, then: > > (I1,D1) <=_DI (I2,D2) <==> I2 \subseteq I1 and D1 <=_D D2 > (*) > > This is the FTDIA that verifies the results computed by motion 27. Dominique > has shown me a proof for this, as well. > > >> As you raise technicalities ... I raise a corresponding issue about Motion >> 27. >> Theorem 3 is FALSE as regards ndf, and I'm still waiting for your revision >> that will correct it. > > It is not false. Jeurgen has already pointed this out several times and > clarified in the past few days. Are you reading the e-mails? > > >> >> Suppose you do an evaluation as described in Motion 27, with the >> 4-decoration system. >> >> - If you get the result saf, then certainly Theorem 3's >> "the decoration" (which I take to mean the unique d in >> {saf,def,con,ndf} such that p_d(f,xx) is true) equals saf. >> >> - If you get def then "the decoration" can be either def or saf. >> >> - But if you get con? Ah, there's the rub of Motion 27. >> Theorem 3's "lower bound" implies "the decoration" can be >> any of con, def or saf. >> NO! It could be ndf, as numerous worked examples have illustrated. > > No John, you continue to be wrong. By theorem 3 the result will be ndf iff > at least one operation in the DET is ndf; it will be con iff at least one > operation in the DET was somehere defined, somewhere undefined and all other > operations were better. > > Theorem 3 is not the FTDIA (*) above, which you continue to confuse it to > be. > > >> - And if you get ndf? Theorem 3 implies "the decoration" can be >> any of ndf, con, def or saf. >> NO! again. If you get ndf, then the result is CERTAINLY ndf. >> Nate knows this perfectly well, and knows his B&B algorithm >> would not work if this were not the case. > > No John, you are wrong again. > As noted above by theorem 3 the result is ndf iff at least one operation in > the DET was ndf. The problem is you continue to compare apples and pears, > i.e., Motion 26 to Motion 27. Theorem 3 is not the FTDIA, and is not > comparing the computed decoration to the true decoration. The lower bound > computed is that of all operations in the DET. This is where you keep going > astray. > > >> >> So, Motion 26 guys, get your act together and produce a Theorem 3 that is >> both understandable and true. > > It is already true. And (*) above verifies the results. > > Nate Begin forwarded message: > From: "J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 5, 2011 10:38:31 AM CDT > To: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Cc: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>, P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > > > Am 05.08.2011 16:17, schrieb Arnold Neumaier: >> On 08/05/2011 04:02 PM, Nate Hayes wrote: >>> Arnold Neumaier wrote: >>>> On 08/04/2011 07:09 PM, Nate Hayes wrote: >>>>> Arnold Neumaier wrote: >>>>>> Motion 26 protects the inexperienced user, while the expert user can >>>>>> judge >>>>>> for themselves how to make use of the decorations. >>>>> >>>>> All Motion 26 does in this regard is allow users to write unreliable >>>>> programs. Since there is no standard, a user may run a program on one >>>>> conforming implementation that uses a certain set of semantics and get >>>>> valid >>>>> results (by coincidence) and then run the same program on another >>>>> conforming >>>>> implementation and fail catastrophically. >>>> >>>> One can write unreliable programs no matter how the decoration system >>>> works, since the user can always set decorations arbitrarily. >>> >>> As I noted to john, the difference is where can the source of the >>> failure be >>> traced back to. >>> With motion 27, the decorations never lie: the failure is traced back to >>> the >>> user's buggy code. >>> With motion 26, the decorations may lie: >> >> No. There is a proof that they are correctly designed. >> >> Note that the example I had discussed in December does not conform to Motion 26, so you cannot use it to accuse Motion 26 of being buggy. >> >> >>>> With Motion 26, the user gets type errors when trying to use an >>>> intersection result in a decorated operation (which is the potentially >>>> unreliable bit) without having set decorations explicitly (and thereby >>>> declaing that what is done is intentional). >>> It doesn't matter. See my post to John. >> >> I answered that just a moment ago. >> >> >>> In any case. Most interval programs use lots of intersection and union >>> operations. So this means none of them will compile if users are trying to >>> perform decorated calculations. >> >> They get intersection results without decoration, and can continue with decorated calculations of a new range by calling the domain function. This corresponds to what is usually done in branch and bound algorithms. >> >> >>>> With Motion 27, no such error occurs, and the result is whitewashed to >>>> safe, no matter what was going on. >>> You have not given any of the examples I requested. >> >> I gave the example y=1/(x intersect (x+1)), which is nonsense but passes a Motion 27 conforming compiler necessarily with a safe result. >> >> >> Arnold Neumaier > That function is not an extension of a real function .But as a function IR -> IR it can be evaluated with decorated intervals > giving the expected result. > > Jürgen Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Re: Reasons to vote Motion 27: NO > Date: August 5, 2011 12:07:16 PM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Jürgen and P1788 > > I overlooked your 2 Aug email, and replied yesterday without taking it into account. Apologies. However your response doesn't change my view, for the reasons below. > > On 2 Aug 2011, at 08:23, J. Wolff von Gudenberg wrote: >>> 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. >> Theorem 3 means that the _expression_ given as an extention of a function is calculated by a DET following(1). >> >> Theorem 3 reformulated >> Given a DET f~ for an extension of f. The mechanism (1) then calculates a decorated interval (e,d) where d<= di for all di appearing in the DET >> That gives a proof that only functions with properties described by the decoration d have been applied > > Already this is false, because the decorations are specified in Definition 1 to be logically disjoint. E.g., the predicate of "def" includes the clause "f is not continuous on xx". I had taken this to be one of the "minor technical slips" in Motion 27, but you argue inconsistently so it is necessary to ask if this is what you really intend.
> >> if d = saf f is everywhere defined and continuous > Yes > >> if d = def f is everywhere defined > Yes, but it doesn't mean "the decoration of f" is def. (d is the computed decoration, and "the decoration of f" is the true decoration.) > f might be continuous as well, so >> if d = def the decoration of f is either def or saf >> (which means f is everywhere defined, as you say) > > What if d = con? Then the decoration of f could be con or def or saf according to your definition. > But what you don't seem to have taken into account is that the decoration of f could also be ndf! > Consider f(x)=sqrt(-1-x*x) on xx=[-2,2]. > We have sqrt(-1 - [-2,2]*[-2,2]) = sqrt(-1=[-4,4]) = sqrt([-5,3]), which gives d = con, but > the true decoration is ndf!!! > > So your formula does NOT give a lower bound for the true decoration of f. I would suggest that, if we continue discussing this, you should provide mathematically sound text. There are simply gaps that > should not be there in the first place. > > This is the actual state of affairs ASSUMING your decorations are exactly as specified in Definition 1: > Computed d | Possible values of true decoration of f > saf | saf > def | def or saf > con | ndf or con or def or saf > ndf | ndf (Nothing else is possible, which is > | another thing not made clear by Theorem 3) > > So your "obvious" Theorem 3 comes nowhere near describing the truth! > > John Begin forwarded message: > From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx> > Subject: Re: P1788: Motions 26 & 27 PLEASE VOTE > Date: August 5, 2011 4:43:01 PM CDT > To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx> > Cc: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx> > > > > I vote no on both motions because decorations need not be required in an interval standard. Begin forwarded message: > From: Markus Neher <markus.neher@xxxxxxx> > Subject: Motions 26 and 27: No > Date: August 6, 2011 1:46:45 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > My vote on Motions 26 and 27 is no. Decorations are too > [ ] advanced [ ] ambitious [ ] complicated (tick where appropriate). > > While acknowledging the time and energy many of you put in the development of an interval standard, I regret to say that I've lost belief that we're still on the path for achieving our common goal. > > In my opionion, we've been overshooting for quite some time. We should agree on keeping the standard simple, we should agree on SOME standard, even if it may not be the optimal standard for each and everyone, and we should do so soon. We can't expect people outside our community accepting and supporting a standard that is so controversial among us. > > Best regards, > > Markus Begin forwarded message: > From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx> > Subject: Re: Motions 26 and 27: No > Date: August 6, 2011 10:04:27 AM CDT > To: Markus Neher <markus.neher@xxxxxxx> > Cc: P1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Markus, > > You can also include [ ] unnecessary, which is the reason I also voted no on both. > > Cheers, > > Bill Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Re: FTDIA revisited > Date: August 6, 2011 10:20:58 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > Nate, P1788 > > On 5 Aug 2011, at 10:02, Nate Hayes wrote: >>> Note, in Motion 27 Definition 1, you have chosen to make the different p_d >>> predicates of its scheme *logically disjoint* ... >> >> Precisely. This is exactly where Dominique gets the order <=_D that I >> mentioned earlier: >> con <=_D def <=_D dac <=_D ein >> con <=_D ndf <=_D ein >> >> If (I1,D1) is the true decorated range of some function f and (I2,D2) is the >> decorated interval computed by Motion 27, then: >> (I1,D1) <=_DI (I2,D2) <==> I2 \subseteq I1 and D1 <=_D D2 (*) >> >> This is the FTDIA that verifies the results computed by motion 27. Dominique >> has shown me a proof for this, as well. > > Maybe I am an unobservant idiot, but I really hadn't seen before that you regard this as part of Motion 27, especially as the latter says clearly on p8 "We do NOT need a version of the FTIA concerning decorations". > > And maybe I'm overcome by enthusiasm, but it seems to me (*) is wonderful! At a stroke the debate has transmuted (for me at least) from > a dispute between supporters of solidly grounded algorithms on one side, > and supporters of unsubstantiated ones on the other > to > a rational design choice between two or more reasonable alternatives. > > ... (Nate wrote) >>> NO! It could be ndf, as numerous worked examples have illustrated. >> No John, you continue to be wrong... Theorem 3 is not the FTDIA (*) above, which you continue to confuse it to be. > Yes, I was wrong. I took "the decoration" in Theorem 3 to mean "the true decoration of the function over the box", which I now accept is not the intended meaning, because that seemed the only place in Motion 27's text that could possibly be stating a crucial relation between "computed" and "true" values. > > Dominique's order is surely related to Motion 26's containment order, though not identical. I have no reason to doubt her theorem is true, and hope she will circulate a proof shortly. > > Best wishes > > John Pryce > > <silly analogy> > In the UK we have a group of eccentrics called trainspotters, one of whose pastimes is to spend all day by a railway line with a notebook, and record the serial number of every locomotive that goes past. (Maybe the aim is to see every locomotive on the network by the time they die?) > If a trainspotter uses this algorithm each time a locomotive goes past: > if (number of just seen locomotive) < (number in my book) { > erase number in book and replace by number just seen > } > then at the end of the day he can be sure the number in the book records the lowest serial number of any locomotive seen that day. And maybe boast about this to other trainspotters, but does it MEAN anything? > > I was thinking the proponents of Motion 27 are merely trainspotters. But now you state (*), that is changed. The trainspotter is an undercover cop, who goes home saying "now I have the evidence to crack this case". > </silly analogy> Begin forwarded message: > From: "Kreinovich, Vladik" <vladik@xxxxxxxx> > Subject: RE: Motions 26 and 27: No > Date: August 8, 2011 2:29:25 AM CDT > To: Markus Neher <markus.neher@xxxxxxx>, stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > We started with Arnold Neumaier's draft which was almost a ready standard, I think we did not deviate too much, and John Pryce has made the texts very standards-like looking, so I think there is hope that we will do exactly as you suggest > > ________________________________________ > From: stds-1788@xxxxxxxx [stds-1788@xxxxxxxx] On Behalf Of Markus Neher [markus.neher@xxxxxxx] > Sent: Saturday, August 06, 2011 12:46 AM > To: stds-1788 > Subject: Motions 26 and 27: No > > My vote on Motions 26 and 27 is no. Decorations are too > [ ] advanced [ ] ambitious [ ] complicated (tick where appropriate). > > While acknowledging the time and energy many of you put in the > development of an interval standard, I regret to say that I've lost > belief that we're still on the path for achieving our common goal. > > In my opionion, we've been overshooting for quite some time. We should > agree on keeping the standard simple, we should agree on SOME standard, > even if it may not be the optimal standard for each and everyone, and we > should do so soon. We can't expect people outside our community > accepting and supporting a standard that is so controversial among us. > > Best regards, > > Markus Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Motion 27-A1: withdrawn > Date: August 6, 2011 4:37:01 PM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > Dear P1788, > > In light of recent discussion, we withdraw the current motion and will resubmit an improved version when we are ready. > > Sincerely, > > Nate & Jurgen Begin forwarded message: > From: Dominique Lohez <dominique.lohez@xxxxxxx> > Subject: IEEE p1788wg Motion 26 Vote NO > Date: August 9, 2011 9:54:00 AM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, "Corliss, George" <george.corliss@xxxxxxxxxxxxx> > > My vote on this motion is NO > The main reason is that two overlapping decoration order relations are defined > while with an appropriate definition only one order relation is required > > Best regards > > Dominique LOHEZ Begin forwarded message: > From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx> > Subject: NO on motion 26... > Date: August 9, 2011 10:20:14 AM CDT > To: <stds-1788@xxxxxxxxxxxxxxxxx> > Cc: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx> > Reply-To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx> > > I will vote NO on this motion. > > Nate recently mentioned the following observation by > Dominique: > >> Dominique once showed me a formulation that instead uses the special >> comparison operator <=_DI such that for two decorated intervals: >> >> (I1,D1) <=_DI (I2,D2) <==> I2 \subseteq I1 and D1 <=_D D2 >> >> where <=_D is the order >> >> con <=_D def <=_D dac <=_D ein >> con <=_D ndf <=_D ein >> >> I think this is likely to be a more promising direction to try and >> formulate a FTDIA. > > > This is surely in the right direction for a correct FTDIA. > If Nate & Jurgen are working on something along these lines, > I'm sure I'll be able to support it. > > > Dan > > P.S. - Just a nit: I would reverse the sense of <=_D to > align with the subset direction. Its just a notational > difference but the reversal of I2 & I1 in the above is > subtle enough to be confusing. Since we're defining the > relation ourselves, there is no need for unnecessary > confusion. Begin forwarded message: > From: "J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > Subject: Re: IEEE p1788wg Motion 26 Vote NO > Date: August 9, 2011 11:52:20 AM CDT > To: Dominique Lohez <dominique.lohez@xxxxxxx> > Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>, "Corliss, George" <george.corliss@xxxxxxxxxxxxx> > > I also vote NO on motion 26 for the same reason as Dominique > Juergen Begin forwarded message: > From: Ian McIntosh <ianm@xxxxxxxxxx> > Subject: Re: P1788: Motion 26 - NO > Date: August 11, 2011 10:59:38 AM CDT > To: <stds-1788@xxxxxxxxxxxxxxxxx> > > I vote NO on Motion 26. I will also vote NO on Motion 27 when it is resurrected. > > I will vote NO to any decorations motion unless the authors and main proponents of motions 25, 26 and 27 agree on one motion. Among other things, I hope such a motion is clear and obvious, that the direction of the directions is right not reversed, and that the decoration names are words instead of TLAs. (For any unfamiliar with the term, Three Letter Acronyms, also used for TL Abbreviations. Also see FLAs.) > > - Ian McIntosh IBM Canada Lab Compiler Back End Support and Development Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Motion 26: NO > Date: August 14, 2011 5:31:40 PM CDT > To: P-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > I reiterate my NO vote with a few reasons I did not mention earlier: > > -- Only the linear quality order > ndf < con < def < dac < ein > of decorations implied by (15) of motion 26 is actually required to > *compute* decorations reliably (note the decorations in (15) are roughly the > same definitions given in withdrawn motions 25 and 27). > > -- I agree with Dominique the "containment order" of decorations given > in (8) is overlapping with the order (15), but that with appropriate > definitions order (8) is unnecessary to verify the computed results. > > -- Order (8) seems to imply that interval comparison relations will > depend on the decorations and not just the interval (particularly the > bounded decoration, which I think is unnecessary). > > -- Bare decorations should promote to Empty, not Entire. > > I'm still left really unconviced about P1788 not providing decorated > intersection and union operations on the premise the semantics of these two > operations should come from taking intersection or union of real numbers and > not sets. > > Nate Hayes > Sunfish Studio, LLC Begin forwarded message: > From: Chenyi Hu <chu@xxxxxxx> > Subject: Re: P1788: Motion 26 PLEASE VOTE > Date: August 15, 2011 8:35:41 AM CDT > To: George Corliss <george.corliss@xxxxxxxxxxxxx> > Cc: <stds-1788@xxxxxxxx> > > I vote no on this motion. > > However, I would vote yes if the description of the motion assures that proposed decorations will assure reliability repeatedly (i.e. on the same and different machines the intervals contain the solution although the intervals may not be the same exactly.) > > -Chenyi > Begin forwarded message: > From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx> > Subject: Re: P1788: Motion 26 PLEASE VOTE > Date: August 16, 2011 7:44:17 AM CDT > To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx> > Cc: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx> > > 1788 members, > > I vote yes on motion 26. > > Although I share the worries of many that the current proposals are complicated, I do feel that we need decorations in 1788 just as flags were needed in 754. So I vote a reluctant yes on motion 26. However, I hope that in the future, we can discuss more the exact decorations set and simplify the language describing these concepts so that the 1788 implementers (of hardware and low level software libraries) can understand them and implement them correctly. > > -- > Hossam A. H. Fahmy Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Re: P1788: Motion 26 PLEASE VOTE > Date: August 16, 2011 9:01:05 AM CDT > To: Chenyi Hu <chu@xxxxxxx> > Cc: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx> > > Dear Chenyi Hu > > On 15 Aug 2011, at 14:35, Chenyi Hu wrote: >> I vote no on this motion. >> >> However, I would vote yes if the description of the motion assures that proposed decorations will assure reliability repeatedly (i.e. on the same and different machines the intervals contain the solution although the intervals may not be the same exactly.) > > It does assure that. After all, theorem 5.2 on the second page of 5.8 includes the original FTIA: > >> Then p_d(f, xx) holds. (10) >> This is in addition to the enclosure ff \supseteq Range(f | xx) given by Moore’s Theorem 5.1. > > > You may not get the same xx or the same d on different machines (or on different runs on the same machine if there's some asynchronous behaviour). > > But the requirement you state above is always satisfied. If I understand you correctly. > > John Begin forwarded message: > From: Mark Stadtherr <markst@xxxxxx> > Subject: Re: P1788: Motion 26 PLEASE VOTE > Date: August 16, 2011 9:45:04 AM CDT > To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx> > Reply-To: <markst@xxxxxx> > > I will vote no on Motion 26 for reasons stated > earlier by Dominique. > > Mark Begin forwarded message: > From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Subject: Re: P1788: Motion 26 PLEASE VOTE > Date: August 16, 2011 9:50:15 AM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Cc: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx> > Reply-To: Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > > John Pryce wrote: >> On 15 Aug 2011, at 14:35, Chenyi Hu wrote: >>> I vote no on this motion. >>> >>> However, I would vote yes if the description of the motion assures that >>> proposed decorations will assure reliability repeatedly (i.e. on the same >>> and different machines the intervals contain the solution although the >>> intervals may not be the same exactly.) >> >> It does assure that. > > Assuming no intersection or union operations are present. > Otherwise all bets are off. > > I'm not sure if this is what Chenyi was alluding to or not, but it is a valid concern. > > Nate Begin forwarded message: > From: Chenyi Hu <chu@xxxxxxx> > Subject: Re: P1788: Motion 26 PLEASE VOTE > Date: August 16, 2011 2:20:50 PM CDT > To: John Pryce <j.d.pryce@xxxxxxxxxxxx>, Nate Hayes <nh@xxxxxxxxxxxxxxxxx> > Cc: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx> > > Thanks Nate! Yes, set operation was my main concern. > > - Chenyi Begin forwarded message: > From: Michel Hack <hack@xxxxxxxxxxxxxx> > Subject: M0026.01 Decorations NO > Date: August 16, 2011 2:40:35 PM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > I vote a reluctant NO on Motion 26, I agree with Hossam Fahmy's feelings > (who voted a reluctant "yes"), as I do feel that we need a working decoration > system. But we are already committed to that basic necessity because we > passed Motion 8, and it is the details that need to be worked out. > > So I expect the motion to be resubmitted (should it fail in this round) > in a way that addresses the missing issues. > > The main detail missed by Motion 26 is the handling of unions and > intersections, which per Motion 26 produce bare intervals, leaving it > up to the programmer to deal with the decorations. Some have said that > trying to use a bare interval in further computation would trigger a > type check error and would thus be detected at compile time -- but many > languages have automatic type coercions. Besides, I'm not convinced > that the domain() operation solves the issue: It accepts both bare and > decorated components of its input vector, and (except for "ill") simply > discards existing decorations. > > Now, I fully agree that there are conflicting arguments as to what the > decoration propagation rule should be for unions and intersections, so > that there is no one sensible rule. In my opinion that should be dealt > with like Max() vs MaxNum() in early 754R drafts: There should be > distinct flavours of the Hull and Intersection operations that the > programmer can select -- and I hope that only a few flavours will be > sufficient to deal with all legitimate uses. > > I also found the nature of the reference document for Motion 26 confusing: > it looks like proposed text, yet we are voting on it as a position paper, > i.e. we are to extract the intent and vote on that, instead of on the > actual text. This can lead to serious misinterpretations. So I will try > in the following to note issues I would have raised if we were voting on > the text. (Btw, there are two versions, both marked DRAFT 03.2, one dated > July 18 -- the one pointed to on grouper.ieee.org/groups/1788/private/Motions > -- and the other dated August 5, with differences besides new Appendix D.) > > Typo in Theorem 5.1: "a arithmetic _expression_" > > In 5.8.1: ...(but not integer constants) -- concerning conversion to > intervals. How about "but not small integer constants"? > > In the table describing the decoration values, it would help to > write "defined, bounded and continuous" for "bnd". The precise > definitions given later are ok. > > In Theorem 5.2, the subscript "d" is not bound. Is universal closure > implied, i.e. is there and f_d() for each decoration value d for which > the corresponding p_d(f,x) holds? > > Michel. > ---Sent: 2011-08-16 20:21:59 UTC Begin forwarded message: > From: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Subject: Re: P1788: Motions 26 & 27 PLEASE VOTE > Date: August 16, 2011 4:21:05 PM CDT > To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx> > > P1788 > > On 5 Aug 2011, at 21:42, Corliss, George wrote: >> It is up to you to vote in a consistent way (for either one of the motions or none). >> >> If you vote "No," you are strongly encouraged to say what changes to that motion it would take for you to vote, "Yes." >> >> Personal opinion: >> Please do NOT say, "This is too complicated/controversial; I won't vote." If both motions fail for lack of a quorum, I suspect the proponents of each may re-submit their motions, and we will vote on the same thing again. > > Yes, I'm sure we will. However, I have MUCH sympathy with Ian McIntosh's "A plague o' both your houses" view: > > On 11 Aug 2011, at 16:59, Ian McIntosh wrote: >> I will vote NO to any decorations motion unless the authors and main proponents of motions 25, 26 and 27 agree on one motion. > > and, were I not one of the proponents, I would be feeling the same way by now. > > When Nate & Juergen withdrew motion 27, I was minded to withdraw motion 26 too, but decided to wait and see how discussion would pan out. I suspect it will fall owing to lack of a quorum (though I haven't counted). Anyhow, valuable points have been made in the final stages. > > We need decorations. But I would now much prefer not to submit any new decoration motion till the Juergen-Nate group and the Arnold-John group have agreed on a common stance. This has proved harder than I expected, mainly because there are issues that one side considers secondary but the other considers central, and vice versa. (No, I will NOT go into details now.) > > For now I suggest > - Will someone propose a motion on what *interval constructors* the standard should > specify? (Bare intervals for the moment!) > If we decide this, I think it will make it clearer whether a Not-an-Interval object > is required. > Q for discussion: Should constructors exist at Level 1 or are they purely a > notion for Levels 2 onward? > > - The Level 1 text EXCLUDING decorations should be split into pieces to be voted on > as actual standard text. Anyone volunteer? If not, I will do it. > > - That involves getting the "Definitions" section into satisfactory form. I hope I > can call on some *editorial assistance* to do the revising. At present it is bitty > and probably inconsistent. > How extensive should it be, anyway? Dan, can you advise? > > - I will put my editorial efforts, for now, into revising the Level 2 text. > I still haven't properly incorporated Explicit/Implicit interval types, > so that is a top priority IMO. > > Best wishes > > John Pryce Begin forwarded message: > From: Vincent Lefevre <vincent@xxxxxxxxxx> > Subject: Motion 26: NO > Date: August 16, 2011 8:43:11 PM CDT > To: <stds-1788@xxxxxxxx> > > Though I like the theory, I currently vote NO. > Here are some comments. > > In Theorem 5.2, I would prefer the notation (ff,d) = f(xx) because one > gets 2 data: ff and d. Writing ff_d = f(xx) is a bit misleading w.r.t. > usual notation with indices. > > 5.8.4 and 5.8.5 are very complicated and difficult to understand, and > without better explanations, I'm not convinced that they are correct. > Moreover 5.8.5 seems to be wrong on the following example: > * xx = [-2,-1] > * yy = Empty > * f(x,y) = sqrt(x) + y > One gets: > * The decoration of xx from domain(xx) is bnd. > * The decoration of yy from domain(yy) is emp. > * For zz = sqrt((xx,bnd)), p_emp(sqrt,xx) holds, so that one chooses > e = emp. Thus d = min{emp,bnd} = emp. > * For zz + yy, if one applies (Eval3) directly as said in 5.8.5: > one chooses e = con. Then d = min{con,emp,emp} = emp. But since > the box (xx,yy) is empty, according to (8), the decoration of > f(xx,yy) must be > emp, leading to a contradiction. So, it seems > that (Eval1) was necessary here. > > 5.8.6 (Examples) should have examples with empty intervals as input. > It may be better to give examples earlier, in order to illustrate the > contents of 5.8.4 and 5.8.5 and make them easier to understand. >
> The two orders (containment order and propagation order) look quite > artificial: the former because of the reversal of the containment > signs and the latter because the order seems more or less arbitrary. > The motion should explain the reason of these choices, more precisely > the choice of the set D and the propagation order. Actually this is > related to the following questions: > > What about practical use (something important for a standard)? > Is there any algorithm that would be based on this motion, > showing that each of the properties can be useful? > > Is it possible to define piecewise functions in this theory? > > -- > 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 / Arénaire project (LIP, ENS-Lyon) Begin forwarded message: > From: Arnold Ne umaier <Arnold.Neumaier@xxxxxxxxxxxx> > Subject: Re: P1788: Motion 26 PLEASE VOTE > Date: August 17, 2011 6:04:10 AM CDT > To: Chenyi Hu <chu@xxxxxxx>, 1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 08/16/2011 09:20 PM, Chenyi Hu wrote: >> Thanks Nate! Yes, set operation was my main concern. >> >> - Chenyi >> >>>>> "Nate Hayes"<nh@xxxxxxxxxxxxxxxxx> 8/16/2011 9:50 AM>>> >> John Pryce wrote: >>> On 15 Aug 2011, at 14:35, Chenyi Hu wrote: >>>> I vote no on this motion. >>>> >>>> However, I would vote yes if the description of the motion assures that >>>> proposed decorations will assure reliability repeatedly (i.e. on the same >>>> and different machines the intervals contain the solution although the >>>> intervals may not be the same exactly.) >>> >>> It does assure that. >> >> Assuming no intersection or union operations are present. >> Otherwise all bets are off. > > According to Motion 26, union and intersection yield an undecorated result. This can be further processed with undecorated interval arithmetic, as has been the case in the past 50 years. Thus things are as safe as they always have been. > > > Arnold Neumaier Begin forwarded message: > From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx> > Subject: Motion 26 Decorations: NO > Date: August 17, 2011 7:25:34 AM CDT > To: "stds-1788@xxxxxxxx" <stds-1788@xxxxxxxx> > > I vote NO. (Sorry for the late vote.) > > I have had a hard time deciding my vote on this motion. I like the > concept and I really appreciate the amount of work that was put into > this motion. Unfortunately, I feel this feature is a bit too fresh with > respect to its complexity, and we (at least I) don't have enough > experience about it to push it into a standard. In one year from now, I > would have probably voted yes (assuming no issue was uncovered in the > meantime), but right now I can't get myself to do it. > > On a more precise point, I'm not fond of intersection and union not > returning decorated intervals. While I can see how several competing > semantics are possible (hence causing the user to inadvertently expect a > nonstandard one), letting the user code the decoration by hand feels > like a bad idea, if only because it is as error-prone as the previous > situation. Perhaps that just means there should be several intersections > and unions (e.g. clamp, refine, aggregate, combine, and so on) that > would only differ in their handling of decorations. > > Best regards, > > Guillaume Begin forwarded message: > From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 17, 2011 8:37:05 AM CDT > To: <stds-1788@xxxxxxxx> > > On 08/17/2011 03:43 AM, Vincent Lefevre wrote: [in: Motion 26: NO] >> >> 5.8.4 and 5.8.5 are very complicated and difficult to understand, and >> without better explanations, I'm not convinced that they are correct. >> Moreover 5.8.5 seems to be wrong on the following example: >> * xx = [-2,-1] >> * yy = Empty >> * f(x,y) = sqrt(x) + y >> One gets: >> * The decoration of xx from domain(xx) is bnd. >> * The decoration of yy from domain(yy) is emp. >> * For zz = sqrt((xx,bnd)), p_emp(sqrt,xx) holds, so that one chooses >> e = emp. Thus d = min{emp,bnd} = emp. >> * For zz + yy, if one applies (Eval3) directly as said in 5.8.5: >> one chooses e = con. Then d = min{con,emp,emp} = emp. But since >> the box (xx,yy) is empty, according to (8), the decoration of >> f(xx,yy) must be> emp, leading to a contradiction. So, it seems >> that (Eval1) was necessary here. > > Note that (as already discussed last year) before any function evaluation with decorations, domain must be called to set the correct initial decorations, which is designed to take care of situations with some empty input. Thus the specification is OK. > > >> Is it possible to define piecewise functions in this theory? > > Yes, see example 2 on page 24 of 20110805Decs+FTDIAproof.pdf > > > On 08/17/2011 01:53 PM, Vincent Lefevre wrote: > > > > Now, see my mail about my vote. There seems to be another > > contradiction. And the motion doesn't make it clear that there > > are no other ones. > > > > The proof of the FTDIA guarantees that there are no errors > (unless the proof is faulty). So please inspect the proof. > > > Arnold Neumaier egin forwarded message: > From: Vincent Lefevre <vincent@xxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 17, 2011 11:24:17 AM CDT > To: <stds-1788@xxxxxxxx> > > On 2011-08-17 15:37:05 +0200, Arnold Neumaier wrote: >> On 08/17/2011 03:43 AM, Vincent Lefevre wrote: [in: Motion 26: NO] >>> 5.8.4 and 5.8.5 are very complicated and difficult to understand, and >>> without better explanations, I'm not convinced that they are correct. >>> Moreover 5.8.5 seems to be wrong on the following example: >>> * xx = [-2,-1] >>> * yy = Empty >>> * f(x,y) = sqrt(x) + y >>> One gets: >>> * The decoration of xx from domain(xx) is bnd. >>> * The decoration of yy from domain(yy) is emp. >>> * For zz = sqrt((xx,bnd)), p_emp(sqrt,xx) holds, so that one chooses >>> e = emp. Thus d = min{emp,bnd} = emp. >>> * For zz + yy, if one applies (Eval3) directly as said in 5.8.5: >>> one chooses e = con. Then d = min{con,emp,emp} = emp. But since >>> the box (xx,yy) is empty, according to (8), the decoration of >>> f(xx,yy) must be > emp, leading to a contradiction. So, it seems >>> that (Eval1) was necessary here. >> >> Note that (as already discussed last year) before any function evaluation >> with decorations, domain must be called to set the correct initial >> decorations, which is designed to take care of situations with some empty >> input. Thus the specification is OK. > > This is exactly what I've done above: > * The decoration of xx from domain(xx) is bnd. > * The decoration of yy from domain(yy) is emp. > > If you consider the steps described in 5.8.5, how can ein be generated? > > -- > Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/> Begin forwarded message: > From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx> > Subject: Re: Reasons (not) to vote Motion 27: NO > Date: August 17, 2011 12:13:48 PM CDT > To: Vincent Lefevre <vincent@xxxxxxxxxx>, 1788 <stds-1788@xxxxxxxxxxxxxxxxx> > > On 08/17/2011 06:24 PM, Vincent Lefevre wrote: >> On 2011-08-17 15:37:05 +0200, Arnold Neumaier wrote: >>> On 08/17/2011 03:43 AM, Vincent Lefevre wrote: [in: Motion 26: NO] >>>> 5.8.4 and 5.8.5 are very complicated and difficult to understand, and >>>> without better explanations, I'm not convinced that they are correct. >>>> Moreover 5.8.5 seems to be wrong on the following example: >>>> * xx = [-2,-1] >>>> * yy = Empty >>>> * f(x,y) = sqrt(x) + y >>>> One gets: >>>> * The decoration of xx from domain(xx) is bnd. >>>> * The decoration of yy from domain(yy) is emp. >>>> * For zz = sqrt((xx,bnd)), p_emp(sqrt,xx) holds, so that one chooses >>>> e = emp. Thus d = min{emp,bnd} = emp. >>>> * For zz + yy, if one applies (Eval3) directly as said in 5.8.5: >>>> one chooses e = con. Then d = min{con,emp,emp} = emp. But since >>>> the box (xx,yy) is empty, according to (8), the decoration of >>>> f(xx,yy) must be> emp, leading to a contradiction. So, it seems >>>> that (Eval1) was necessary here. >>> >>> Note that (as already discussed last year) before any function evaluation >>> with decorations, domain must be called to set the correct initial >>> decorations, which is designed to take care of situations with some empty >>> input. Thus the specification is OK. >> >> This is exactly what I've done above: >> * The decoration of xx from domain(xx) is bnd. >> * The decoration of yy from domain(yy) is emp. > >> If you consider the steps described in 5.8.5, how can ein be generated? >> > > > Since you compute a function of two variables, you need to apply domain > to the vector consisting of both variables, not to each variable separately!

Follow-Ups:
- Re: OFFICIAL result, Motion 26 FAILS
  - From: Joel C. Salomon

References:
- OFFICIAL result, Motion 26 FAILS
  - From: Corliss, George

Prev by Date: Re: OFFICIAL result, Motion 26 FAILS
Next by Date: Re: Circular functions are not as intractable as you may think...
Previous by thread: OFFICIAL result, Motion 26 FAILS
Next by thread: Re: OFFICIAL result, Motion 26 FAILS
Index(es):
- Date
- Thread

From:	"Corliss, George" <george.corliss@xxxxxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	08/18/2011 09:44 PM
Subject:	OFFICIAL result, Motion 26 FAILS