I agree that the best way to convert
a program to IA is usually to start over.
GC> . . .
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.
It's certainly possible that transliterating
a program from double to double_interval will lead to results that do not
enclose the true answer, but I believe we can define an IA standard where
it is impossible for the IA answer to not enclose the floating-point answer,
provided we make that a requirement (and to me it is one), and provided
the program and compilers conform to standards, and both programs are compiled
for reproducibility (eg, following source code precision exactly, restraining
_expression_ reordering, etc.
I expect some and maybe most transliterated
programs would produce (infinity, infinity) or very large ranges as results.
That doesn't violate enclosure. It is a warning that the non-IA
computed results might be meaningless.
If the non-IA program says the answer
is 42 and the IA program says it is (2000, 100000) then somebody made a
mistake - either the original program was incorrect or nonconforming, or
the translation was incorrect, or the compiler is wrong, or the IA implementation
is wrong, or our standard was defective.
I consider producing enclosures for
straightforward translations to be one of our essential requirements. Otherwise
aren't we lieing, either a lie of commission or a lie of omission?
Some will want to add another qualifier
- that the original program never computes an infinity (either an overflow
or a true infinity) or a NaN, or in IA never computes an infinity, NaN,
empty set or NaI.
GC> I hate to be elitist, but I think intervals
are only usable by experts.
Any good programmer should be able to
use them to produce answers enclosing the non-IA answers. Only experts
can use intervals well, producing tight bounds. I don't know if it's
possible to alleviate that.
- Ian McIntosh
Toronto IBM Lab 8200 Warden D2-445
Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
14/04/2009 12:29 PM
Please respond to
Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
To
Ian McIntosh/Toronto/IBM@IBMCA
cc
Subject
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.