Re: Comparisons and decorations, part 2
Dan Zuras Intervals wrote:
From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
(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.
A compiler must be very intelligaent to know that without directives
from the user, since it must understand some mathematical theory.
We cannot expect the compiler to do theorem proving....
Probably the casual user should always work (invisibly) with
decorated intervals and have compiler support for more trivial
cases where decorations can be dropped because they are never queried.
But expert users must be able to strip the decorations explicitly,
without having to prove to the compiler that it is allowed.
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.
Yes.
(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],
Why? According to Motion 8, it must return a valid interval that is
an enclosure of bare[0,2], Only a naive, wrong evaluation produces
the non-interval bare[NaN,2].
Similarly, bare[1,1]/bare[0,0] must return a valid interval,
and the only natural choice is Empty.
I'm sure
there are many examples that would need careful
analysis rather than blind bare evaluation.
The problem I posed is on the conceptual Level 2 rather than
on the level of a particular algorithm. The operations are
_defined_ conceptually, and must be _implementend_ in a way
conforming to the conceptual specifications.
This is a good reason to leave the decision to run
bare up to the compiler 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.
Nevertheles, we must consider the options in order to know
what can reasonably be required.