Re: Promotion of bare decorations & comparisons
John Pryce wrote:
>
> Forget for now the interval-valued NAOs -- intersection & convexHull
> -- because much e-ink HAS been expended on them.
>
> I mean the boolean NAOs (mostly comparisons) and the numeric NAOs
> (midpoint, etc): the ones that can't possibly *propagate* a decoration.
> Here are 2 views we could take:
>
> (A) A decorated interval is "really a bare interval" with
> some graffiti on it, and these NAOs should just be a
> shorthand for "ignore the decoration and apply the NAO
> to the bare interval part".
>
> (B) A decorated interval is very different from a bare one,
> and its boolean/numeric NAOs should be custom-designed,
> or possibly should not exist at all.
View (A) is essential if we want to honour the spirit of "decorations
should be mostly transparent to users who don't care about them".
We must however provide definitions and guidance that make sense for
those we DO care about decorations, and who want to "believe" in them.
This means stating clearly under what circumstances the properties that
decorations are supposed to certify cease to be valid.
For interval-value NAOs (non-arithmetic operations) I think we did provide
clarity: the basic operations return bare intervals, and we provide (shall
or should, that is a remaining question) decorated versions that are valid
IN A LIMITED CONTEXT -- and it is unfortunately up to the programmer to
verify that the needed assumptions are satisfied.
For the other NAOs the programmer has to be aware of the fact that the
decorations were ignored, and the best we can offer is a guard function
(one per arity):
guard(xx1, ... xxn, thresh)
which returns TRUE iff no argument decoration falls below the threshold.
The threshold could be given as a bare decoration, or as the decoration
of an n+1st decorated interval argument. (In this context, bare intervals
would be deemed to pass the threshold, bare decorations would be compared
to the threshold. Alternatively, bare intervals could be deemed to be
subjected to newDec(). But a language's type rules may in fact dictate
whether type promotions are even allowed or supported.)
I would NOT complicate the boolean comparisons with compound interval and
decoration comparisons.
In the context of compressed intervals, I think we need to make it clear
that a compressed interval that is a decoration is essentially different
from a bare decoration, and any comparison involving compressed decorations
should return UNORDERED (and we may need "signalling" forms, as in 754, if
UNORDERED cannot be distinguished from FALSE).
Michel.
P.S. One approach to non-arithmetic interval-returning operations would
be a decoration qualifier (an extra bit) that indicates occurrence
of such an operation on the computation path. But now we have to
discuss how that affects decoration promotion and containment orders,
which may cease to be total... Ouch.
---Sent: 2013-01-07 14:39:26 UTC