Re: Comparisons and decorations, part 2
> Date: Tue, 28 Sep 2010 16:28:10 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: Comparisons and decorations, part 2
>
> Dan Zuras Intervals wrote:
> >> Date: Tue, 28 Sep 2010 14:26:23 +0200
> >> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> >> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>,
> >> 1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> >> Subject: Re: Comparisons and decorations, part 2
> >>
> >> Dan Zuras Intervals wrote:
> >>
> >>> Then let me suggest that there exist a
> >>> decoration for empty.
> >>>
> >>> Or, at least, some combination of the
> >>> existing decorations that implies empty.
> >>>
> >>> That way we do not NEED a representation
> >>> for empty within the interval part of a
> >>> 1788 interval.
> >>>
> >>> And we will have anything + empty = empty
> >>> fall out to be both fast & easy no matter
> >>> what we use for empty so long as the
> >>> decoration makes it so.
> >> Since bare[1,1]/bare[0,0] or sqrt(bare[-2,-1]) must be empty,
> >> this conflicts with the need of a fast mode for arithmetic
> >> operations for bare intervals.
> >
> > On the contrary, it is consistent with that.
> >
> > I was discussing fast & easy intervals for
> > which the interpretation of empty is to be
> > found in the decoration.
> >
> > That you might need some further restriction,
> > say your favorite [NaN,NaN], for bare intervals
> > is still consistent.
> >
> > And, should we feel that it is the appropriate
> > way to go within that context, I have no
> > objection.
>
> It seems that you suggest the following:
Close.
>
> (i) Constructors always create decorated intervals, never bare ones.
> Bare intervals are created by stripping decorated ones using the
> operator Bare.
I suggest, for the sake of assured computing, that we
ALWAYS deal with decorated intervals at a formal level.
Then we can leave it to compiler optimizers to know
when it is safe to strip them bare & run without the
decorations. As this should be most of the time (when
it is known that no one is looking at the decorations,
for example), it should be a relatively easy task.
>
> (ii) The empty interval Empty is represented by [NaN,NaN] when bare,
> and by ([NaN,NaN],IsEmpty) when created by a constructor.
> However, _every_ decorated interval of the form ([any,any'],IsEmpty)
> is interpreted as Empty.
There are two possibilities here.
Either we decide how the empty interval is to be
represented or we leave it up to the implementers
to decide what is best for them.
In the latter case, we could put in an informative
note suggesting the use of [NaN,NaN] & explaining
why.
>
> (iii) The stripping of a decorated interval may modify its bare part
> iff the semantics necessitates it. In particular,
> Bare(([any,any'],IsEmpty)) = [NaN,NaN].
That would work.
>
> (iv) Arithmetic operations on decorated intervals always preserve
> an IsEmpty decoration.
Of course.
>
> This indeed captures the necessary behavior of Empty, and improves
> the efficiency of propagating decorated intervals in general, while
> not harming fast expression evaluation for bare intervals.
>
> However, it still means that
> bare[a,b] interior bare[c,d]
> needs a branch to handle bareEmpty.
Well, as a bare evaluation of sqrt(bare[-5,4]) would
lead to bare[NaN,2] rather than bare[0,2], I'm sure
there are many examples that would need careful
analysis rather than blind bare evaluation.
This is a good reason to leave the decision to run
bare up to the complier optimizer. It might only
choose to optimize to bare when such things cannot
happen. Or, more to the point, can be PROVED not
to happen.
But these are just half baked ideas at best. I'm
sure they can be improved upon.
Dan