Re: Promotion of bare decorations & comparisons
On 2013-01-05 19:11:51 +0000, John Pryce wrote:
> I partly agree with all that has been said about comparisons between
> bare decorations and intervals leading to apparent anomalies. Yes,
> they are dangerous, but IMO mainly because a more fundamental
> question hasn't been addressed:
>
> On what basis should non-arithmetic operations (NAOs) on decorated
> intervals be allowed to exist?
>
> 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.
Until now, decorations have been introduced with view (A). I originally
thought that this was better and more practical. Now I'm wondering...
First, (B) may be regarded as safer, while languages would be free to
implicitly convert decorated intervals to bare intervals when possible,
if they choose to. Note also that (B) may be more practical: bare
intervals and decorated intervals would not be the same type in most
languages (this seems a bit obvious), and the conversion of a decorated
interval to a bare interval would not be trivial (I mean, it would not
be a no-op for the generated code); for instance, if interval types are
provided by pointer types, doing a cast (in C) would not be sufficient,
because the data representations are not the same. Said otherwise, if
we choose (A), non-OO languages may have to provide different function
names for the same operation, depending on the types of the arguments.
> For *numeric* NAOs, I don't have a problem with view (A). I would be
> happy if mid, rad, inf, sup, ... just drop the decoration part.
But this can be a problem if a NAO is applied on NaI and doesn't
return NaN.
> Probably ditto for the 1-argument boolean NAOs isEmpty() and
> isEntire().
I agree for these ones.
> But for the *2-argument boolean* NAOs (comparisons), view (A) isn't
> good enough.
>
> The problem starts with isEqual(). Surely, isEqual(xx_dx, yy_dy)
> should be true iff the interval parts are equal *and* the decoration
> parts are equal.
Hmm... This is not obvious. Should isEqual(NaI, NaI) be true?
[...]
> Would I go that far? I'm not sure, but I am *not* happy with the
> idea that containment of decorated intervals is just containment of
> their interval parts -- view(A) -- which is an unstated assumption
> of the exchanges between Nate and Michel about compressed intervals,
> over the last few days. Rather than that, I would prefer that
> boolean NAOs *do not exist* for decorated intervals, see view (B).
This is my current position.
--
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 / AriC project (LIP, ENS-Lyon)