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

Re: Decorations and Motion 22

Dan Zuras wrote:

From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
To: "John Pryce" <j.d.pryce@xxxxxxxxxxxx>,
 "Arnold Neumaier" <Arnold.Neumaier@xxxxxxxxxxxx>
Cc: "1788" <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: Decorations and Motion 22
Date: Sun, 31 Oct 2010 13:49:14 -0500

John Pryce wrote:

> What is the result of (bare decoration) op (bare interval)? E.g.
>      ok + [1,2]

By section 2.3, the result has to be a bare decoration: ok.

Nate Hayes


Nate,

You are not addressing the crux of John's question
here.  You only answer in the case of add which is
everywhere defined.

And your answer seems to imply that a bare decoration
qualifies as a new type of idempotent interval along
the lines of empty & NaI.


I have always said a bare decoration and NaI are the same thing.

Otherwise, to recap (again) my postion on all this:

My position is as per Motion 8 that at Level 2:
-- bare intervals are elements of overline-IR; this includes the empty set -- bare decorations are "not an interval" (NaI), and hence are a disjoint set from bare intervals -- decorated intervals are comprised of a bare interval and a bare decoration
Operations on bare intervals and bare decorations are closed in the same way Arnold Neumaier has already pointed out several times. Bare intervals may be promoted to decorated intervals to participate in operations with other decorated intervals, but bare decorations may never be promoted to a decorated interval.
Arnold recently noted: we don't yet see eye-to-eye on some of the finer details regarding propagations of decorations and (perhaps) some of the promotion rules. In retrospect, the "least informative" rule from Motion 8, in my view, was a mistake and I'm sympathetic to some of John's suggestions that the bare interval [1,2] should be "promotable" to decorated interval ([1,2],ok).
In regards to propagation of decorations, the problem I have with the Motion 8 "least informative" rule -- as recently clarified by Arnold tonight in this forum -- is it leads to a decoration system that is (demonstratably) mostly useless, since exception information is not "sticky" and hence becomes lost or discarded in most computations. This is partly the motivation I had to write Motion 18, which uses the "infumum" rule instead to propagate decorations and allows one to do proofs by structural induction regarding the presence or absence of some exceptional property in a computation (much like NaN is somewhat of proof by induction something went wrong in an IEEE 754 floating-point computation).
I still believe Motion 18 (and Motion 22 + Amendment) are the correct semantics for propagation of decorations in IEEE 1788.
Arnold and myself are working out our differences on these details, with some success, I think (at least, the discussion is very productive).
On a personal note: I didn't mean to be coy in my short response to John. If anything, it is just weariness. I have spent dozens of hours the past few days in offline discussions on these topics, and I'm simply not interested in duplicating my efforts here on the main relector at the moment. I'd much rather just finish the position paper and then use that as a point of discussion. 









> Then I suppose "ok" promotes to "an arbitrary ok decorated interval"
> (xx,ok). Whence
>       ok + [1,2] = "possibly everywhere defined"
> because that's the worst that can happen with (xx,ok) + > ([1,2],2); and 
>             [1,2] / ok = "nowhere defined"
>     because xx might be [0,0].


John also asks what is to be done when such an
interval passes through an operator that is NOT
everywhere defined such as divide.

He could just
as easily have asked what is the value of sqrt(ok).

I ask: What is the value of sqrt(<bareDecoration>)?
I would say it probably should be whatever was the input decoration, for the following reasons:
-- a bare decoration can never be promoted to a decorated interval, hence there is no interval portion to deduce if the operation is undefined or not; and
-- it is a unary operator, so by Motion 18 there are no other decorations to take the "infimum" of. 

Hence, the result should simply be the input decoration, unmodified.

Nate Hayes