[std-interval] list of functions for intervals

[R. Baker Kearfott]

Guillaume, Lee,

I am just getting around to reading this thread.  Also, note that the opinions
I give here are my personal ones, subject to change after additional
discussion within this group and within the ISL group.

I quote from the "Example Specifications for Interval Verions (sic) of
<cmath> Functions:"

"A more aggressive interpretation of the compatibility requirement is that 
the result of an interval version of a <cmath> function is the hull of all 
of the results that would be generated by the non-interval version of the 
function if it were fed every combination of non-interval arguments implied 
by the argument intervals."

I agree with the above as a guide for specification of interval
functions.   More precisely, John Pryce's cset theory clarifies
this statement in limiting cases.  

Also, I suggest the the modification,
"contains the hull," rather
than "is the hull."  To demand that it be exactly the hull may be
too difficult in some cases.  In your parlance, "white lies" (meaning
that the returned result isn't the exact range to within roundout,
but merely contains it) are less destructive from a logical point
of view than "outright lies" (where there are values in the range
that are outside the returned result).  The coiners of the idea
"thou shalt not lie" in conjunction with interval arithmetic meant
that the returned result contain the mathematically correct result.
In limiting cases, what is the mathematically correct result is
specified, at least partially, by cset theory.  (There are also
other considerations, such as extending acos to acos_rel, as 
Guillaume suggests.)

If I understand "twin," you envision it to hold two results,
such as returning [-\infty,-1] .union. [1,\infty] as the result
of [1,2] / [-1,1].  I can see a use for that.  However, there is a
"twin arithmetic" in the interval literature that is something else,
so I would recommend using a word other than "twin" in this context. 
I also recommend, if we go this route, that the actual results returned
be set based on the cset theory.

Guillaume,  I understand the  acos_rel can be useful for constraint
propagation.  It seems that similar utility cannot be gained
within Lee's "twin" structure, since the set of all r such that
cos(r) is in X is countably infinite, for a particular x \in X,
-1 <= x <= 1.  Also, results with disjoint intervals as cset,
such as  \sqrt([1,4]) (which yields [-2,1] .union. [1,2] as cset) 
could indeed be handled with sqrt_rel.  All in all, my first impressions
are that this does seem to be somewhat simpler than the "twin" structure.

Sincerely,

Baker

At 03:52 PM 6/5/2006 +0200, Guillaume Melquiond wrote:
>Le dimanche 04 juin 2006 à 00:30 +0000, first.i.last at comcast.net a
>écrit :
>
>> The attached document is a summary aimed at raising issues and
>> identifying areas meriting additional discussion rather than a
>> comprehensive specification with endless detail but no rationale.
>> Therefore readers who are only concerned with concrete suggestions
>> should not read it.
>
>If I correctly understand your document, you have extended the atan2
>function as three interval functions. For Y=[-1,1] and X=[-2,-1], they
>will answer:
>
>        twin_atan2  => [-Pi,-Pi/2] | [Pi/2,Pi]
>        atan2_sharp => [Pi/2,3Pi/2]
>        atan2_blunt => [-Pi,Pi]
>
>In our current proposal, we have preferred to provide less functions yet
>be more generic; this idea was inspired by interval arithmetic libraries
>like gaol. First there is an atan2 function which is the natural
>interval extension, namely your atan2_blunt function. Second there is a
>relational function atan2_rel defined as:
>
>        atan2_rel(Y,X,R) contains { r in R ; cos(r) in X and sin(r) in
>        Y }
>
>Because of its two arguments, the atan2 example may not be the clearest
>one. So let's consider the acos function instead.two interval functions
>are defined:
>
>        acos(X) contains { acos(x) ; x in X } = { r in [0,Pi] ; cos(r) in X }
>        acos_rel(X,R) contains { r in R ; cos(r) in X }
>
>Note: if Pi was exactly representable by a floating-point number, only
>one function would be needed. The result of acos(X) would be defined as
>acos_rel(X,[0,Pi]).
>
>Why provide this function acos_rel? Because it is needed when doing
>global optimization and constraints programming. Indeed, after doing
>some forward and backward propagations, you usually come to the point
>where you have an equality "b = cos(a)" and constraints "a in A" and "b
>in B". Then you can compute improved constraints:
>
>        B' <- intersection(cos(A), B)
>        A' <- acos_rel(B, A)
>
>If acos_rel was not available, the second assignation could be written
>A' <- intersection(acos(B), A). But the set A' would then be wrong if
>the initial sets were A = B = [-1,1].
>
>Best regards,
>
>Guillaume
>
>_______________________________________________
>Std-interval mailing list
>Std-interval at compgeom.poly.edu
>http://compgeom.poly.edu/mailman/listinfo/std-interval
>
>

---------------------------------------------------------------
R. Baker Kearfott,    rbk at louisiana.edu   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------