Re: [Reliable Computing] abs[x] for intervals? (reason for a standard)
> From: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>, "R. Baker Kearfott"
> <rbk@xxxxxxxxxxxxx>
> CC: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>,
> "reliable_computing@xxxxxxxxxxxxxxxxxxxxxx"
> <reliable_computing@xxxxxxxxxxxxxxxxxxxxxx>, stds-1788
> <stds-1788@xxxxxxxxxxxxxxxxx>
> Date: Tue, 14 Apr 2009 08:10:39 -0500
> Subject: Re: [Reliable Computing] abs[x] for intervals? (reason for a
> standard)
>
>
> > Alan Eliasen wrote:
> > >
> > > * Which definition do you find most appropriate for converting
> > > real-valued algorithms to use intervals?
>
> On 4/14/09 7:33 AM, "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx> wrot=
> e:
> As for the question of how an algorithm designed for the
> Reals maps onto the intervals in this case, I will leave
> that for those better qualified to answer.
>
>
> To my mind, that is a very real danger of efforts to promote wider use of i=
> ntervals, whether this standardization effort or other efforts. If we are =
> successful in convincing others that intervals are a good idea, a VERY natu=
> ral first response is, "Great, how do I convert my real-valued algorithms t=
> o use intervals?"
>
> After 30 years of searching for a responsible answer, I have not found one.=
> The best advice is, "Don't. Start over." That's usually a show-stopper.
>
> . . .
>
> If we are successful and achieve an interval standard, it is very likely we=
> will put intervals into the hands of well-intentioned people, who will bel=
> ieve our message, change double to interval as Alan asked, find their resul=
> ts do NOT enclose the true answer to their problem, and conclude interval a=
> dvocates have lied.
>
> I hate to be elitist, but I think intervals are only usable by experts. Ex=
> perts can develop tools which allow T.C. Mits (The Celebrated Man In The St=
> reet - S. I. Hiakowa, linguist and former US Senator) to exercise interval =
> algorithms without even knowing he has done so. Expecting T.C. Mits to wri=
> te algorithms yielding guaranteed bounds is unrealistic. A standard is ess=
> ential for experts, too, but we must beware the Law of Unintended Consequen=
> ces.
>
> That is another reason why I argue for SIMPLICITY and as much care as we ca=
> n muster for warnings on miss-use. We cannot assume the programmer knows w=
> hat (s)he is doing.
>
> Dr. George F. Corliss
Folks,
As a newcomer to intervals I can identify with much of this.
When I first came to this group I thought of intervals as a
funny sort of floating-point. It is not. I thought my years
of floating-point experience would apply. It does not.
It is for this reason that I believe that part of our task is
a pedagogical one. It will be necessary to teach the world
what intervals really are & how to use them.
But first they must be made as simple as possible.
It may be that some methods are easy to teach if only we can
get them out there. It may be that we will have to provide
features in the standard that facilitate teaching. It may be
that we will have to provide technically complex features to
the standard to facilitate a user interface that 'appears'
simpler than it is under the covers. And it may be that some
aspects of intervals will forever be beyond what we can expect
of the world of potential programmers.
For this last we may have to provide canned solutions that
are also part of the standard.
But George raises the very real concern that we may do an
excellent job of standardizing the technical details of
intervals & STILL fail in the goal of having it become a
standard that is used & trusted.
It is also possible that intervals is the wrong standard at
the wrong time. If we cannot agree on what constitutes a
simple, workable, teachable, believable standard than we will
be the first to know it.
If we succeed the world will be a better safer place.
If we fail we may learn something that contributes to the
next effort.
We can but try. Let's try.
Dan