I posted a query about abs[x] to the primary interval analysis
mailing list last night, and have received several replies, some
directly useful, some not. I'm forwarding my postings to the Frink list
to show where things are going, but I don't want to flood this list with
every posting from there.

Unfortunately, I can't find a publicly-available archive of that
mailing list that I can point you to; I'll forward the more relevant
postings (probably off-list; I don't know if I'm allowed to repost them
to this list) if someone is interested. Otherwise, you can subscribe to
the list here: http://interval.louisiana.edu/mailing_list_form.html
(The link on that page also shows how to request archives from the mail
server.)

This is of sufficient interest to those in the field that it's been
forwarded to the new IEEE Expert Group that's working on defining a
standard for interval arithmetic. (I also work with an expert group
that is trying to define an interval standard for the C++ Standard
Library, which appears to be stalled.) So if anyone has strong
feelings, please let me know, or post them to the interval list noted above.

My original posting to that list below.

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)
>


--
Alan Eliasen | "Furious activity is no substitute
eliasen@... | for understanding."
http://futureboy.us/ | --H.H. Williams