Decorated intervals ARE intervals...
Folks,
I have kept out of the current discussion mostly because
others are making far better arguments than I could.
But a minor side issue mentioned almost in passing by
Dominique, Nate, & others has been nagging at me.
It is the issue of bare intervals & bare decorations.
I have stated this before & the current discussion only
strengthens my opinion that decorated intervals should
BE intervals. Full stop. Certainly at level 1 but as
far down as we can push it as well.
I realize that at some level we will need interval
constructor functions that create intervals from
floating-point numbers & attach decorations to them.
I realize that we will need selector functions that
tease out bare intervals & decorations from a decorated
interval. I realize we will need cleansing functions
that take away the accumulated sins of an interval.
But the use of each of these lower level functions
gives a program the ability to lie about a result.
As does any further manipulation of bare intervals &
decorations & then trying to use them in any meaningful
way with fully decorated intervals.
Someone opined that the current simplified proposal makes
an FTDIA unnecessary. I would state it differently:
that a sufficiently simple & robust definition of our
decorations should make an FTDIA no harder to prove than
the FTIA. That usefully defined decorations may add
information to the interpretation of an interval but
never at the cost of making that result less certain.
To quote Dominique in a recent post on a related subject:
Thus the program must never lie. It must never
believe the programmer implicit extra-assertions
and check from known data and decorations
I think this is best accomplished by deprecating the use
of bare intervals & decorations (at the very least) or
eliminating them altogether from the universe of discourse
which concerns itself with assured computing.
IMHO, it is not so radical a position when all is said &
done.
Dan