Re: Promotion of bare decorations & comparisons
Nate
On 7 Jan 2013, at 15:51, Nathan T. Hayes wrote:
> John Pryce wrote:
>> "A decorated interval yy_dy shall always be such that yy \supseteq Rge(f|x) and
>> p_dy(f,x) holds -- informally, it must tell the truth about
>> some conceivable evaluation of a function over a box."
>>
>> I think it is definitely *not* the case for your system.
> ???
> Please demonstrate why you think this.
> If you can provide some specific examples, that would be helpful.
It seems I was wrong, thanks to mixing up lowercase decorations with uppercase ones. As I understand it, your uppercase "tracking" ones correspond to motion 42 lowercase ones and the lowercase "static" ones are equivalent to the "tightest decoration" function dec(). I.e. p_d(f,xx) holds for a static d in your system, iff d = dec(f,xx) in motion 42 (allowing for the systems' different sets of decorations).
Are the permitted combinations in your system as follows?
yy
+------------------
dy | empty nonempty
+------------------
EIN | y n
DAC,DEF,GAP,NDF| y y
You wrote (On 5 Jan 2013, at 21:06):
> -- Empty may have "good" (DAC) and "bad" (NDF)
> decorations/interpretations
Suppose I evaluate an arithmetic expression, and the result is, say, Empty_DAC. What useful conclusion can I typically draw from this?
You also wrote in that email
> -- If Empty is not an interval, compressed interval arithmetic
> avoids the false positives/negatives
Do you mean, here, that it's just in compressed arithmetic that Empty isn't an interval?
A remaining question from my last email: please explain how this system handles invalid constructor calls.
John Pryce