Re: [Reliable Computing] abs[x] for intervals? (reason for a standard)
> Date: Tue, 14 Apr 2009 06:51:12 -0500
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxxx>
> To: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> CC: reliable_computing@xxxxxxxxxxxxxxxxxxxxxx,
> stds-1788
> <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: [Reliable Computing] abs[x] for intervals? (reason for a standard)
>
> Alan,
>
> . . .
> This is why I am sending a copy of your message to the IEEE
> P1788 working group on the standardization of interval arithmetic.
>
> Best regards,
>
> Ralph Baker Kearfott
>
> Alan Eliasen wrote:
> > I've received some questions about my implementation of the absolute
> > value function for intervals of real numbers in my programming language
> > Frink ( http://futureboy.us/frinkdocs/ ). My behavior follows the
> > definition for abs[x] defined in Ramon Moore's book _Methods and
> > Applications of Interval Analysis_ (see p. 10, eq. 2.5). The definition
> > is:
> >
> > abs[x] = max[ abs[infimum[x]], abs[supremum[x]] ]
> >
> > Which obviously gives a single scalar value, and not an interval.
> >
> > When passing intervals to an algorithm that was originally written
> > with other numerical types in mind, (yes, I have the usual cautions
> > about this,) some users have expressed surprise at the result returned
> > by the abs[x] function. They would expect, for instance, that the
> > absolute value of the interval [-3, 2] would return [0,3], which is a
> > reasonable expectation, and would allow many more algorithms to work
> > without modification. In addition, being able to retain a
> > "main/middle/best guess" value for intervals that already have a "main"
> > value would be a benefit, rather than returning a scalar value.
> >
> > So, my questions are:
> >
> > * What was the original rationale for this definition?
> >
> > * Is this definition still considered best practice? Have other
> > texts proposed a different definition?
> >
> > * If not, what is the currently-accepted best definition? What are
> > its strengths and weaknesses?
> >
> > * If you have an implementation of interval arithmetic, what
> > definition do you use?
> >
> > * Which definition do you find most appropriate for converting
> > real-valued algorithms to use intervals?
> >
> > My proposed definition is broken into 3 cases showing the code paths
> > that will be taken for efficiency:
> >
> > For intervals straddling 0:
> > abs[x] = [0, max[infimum[x], supremum[x]]
> >
> > For intervals with supremum < 0:
> > abs[x] = [-supremum[x], -infimum[x]]
> >
> > For intervals with infimum > 0:
> > abs[x] = x (i.e. no change necessary)
> >
>
>
> --
>
> ---------------------------------------------------------------
> R. Baker Kearfott, rbk@xxxxxxxxxxxxx (337) 482-5346 (fax)
Folks,
This seems like a topic we might take up in more detail in
the ER subgroup, however, since it was posted here...
To use Alan Eliasen's notation (mod the typos) the Vienna
proposal has:
Magnitude(xx) = max(-infimum(xx), supremum(xx))
Mignitude(xx) = max(0, -supremum(xx), infimum(xx))
AbsoluteHull(xx) = [Mignitude(xx), Magnitude(xx)]
if I have been careful about my case analysis. This form
would be branch free but for those we get for free out of
the max function. How these behave for [empty], NaIs, or
non-standard intervals I will leave up for grabs for now.
As Baker has implied, I think Alan's questions can largely
be reduced to a clarification of which functions take
intervals & return Reals & which return intervals. Both
are available & the user is free to choose among them.
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.
Enjoy,
Dan