more Re: [std-interval] list of functions for intervals
R. Baker Kearfott
rbk at louisiana.edu
Mon Jun 5 13:05:43 PDT 2006
Guillaume,
What if, in your example below, R contains two disjoint segments
of points r such that cos(r) \in R? Would you return the interval
hull? In fact, R could possibly contain an arbitrary number of
such segments. Thus, acos_rel does give additional utility for
constraint propagation, but can't give the exact cset in all cases.
Also, I note that Lee's "twin" idea, if I understand it correctly,
doesn't handle the case with more than two disjoint intervals in the
cset. At some point, I'm guessing that we need to accept what
Lee calls "white lies" in some cases, and design a standard that is
a good balance between simplicity and utility in a wide variety
of applications. (We should also try to not prohibit vendors from
doing more, if they see a market.)
Best regards,
Baker
>Date: Mon, 05 Jun 2006 10:26:11 -0500
>To: For discussions concerning the C++ standardization of intervals
> <std-interval at compgeom.poly.edu>
>From: "R. Baker Kearfott" <rbk at louisiana.edu>
>Subject: Re: [std-interval] list of functions for intervals
>
>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
>---------------------------------------------------------------
>
>
>_______________________________________________
>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
---------------------------------------------------------------
More information about the Std-interval
mailing list