Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Ar we succeeding?



Nate and all

On 23 May 2011, at 15:06, Nate Hayes wrote:
> Hi Vladik,
> 
> Here is an example I've posted a couple times. The result of Fig. 4 was computed with definitions of decorations according to v3.01; and the result of Fig. 3 was computed with the repaired definitions in the new motion.
> 
> Nate
> 
> ----- Original Message ----- From: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> To: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>; "Ralph Baker Kearfott" <rbk5287@xxxxxxxxxxxxx>
> Cc: "John Pryce" <j.d.pryce@xxxxxxxxxxxx>
> Sent: Sunday, May 22, 2011 7:27 PM
> Subject: RE: Ar we succeeding?
> 
> At least to me, this is a completely new information. I am not sure what kind of failures you got and why, and I did not realize that what you propose is new definitions. I think before we start understanding nthe solution we need to understand the problem. Can you clarify the problem?

At last I'm getting round to respond to this example. In your file <intersection.pdf> giving the example, you have two real-variable functions f(x), g(x) of vector x=(x0,x1) and define
   S_f = {x | f(x) is defined},    S_g = {x | g(x) is defined}
and
   S = (S_f intersect S_g)  =  {x | both are defined}.

Now you use the interval function
   h(X) = f(X) intersect g(X) 
in your Branch & Bound algorithm to determine S.

But this is totally arbitrary. h(X) has no intrinsic meaning. For a small box X it will "almost always" be empty, and if you imagine a small X "gradually increasing", it becomes nonempty at some point dependent on the vagaries of f and g. Your algorithm succeeds using h, *only* because you have chosen a particular way to decorate the intersection operation.

Both your scheme and the Neumaier-Pryce scheme work if instead you define
   h(x) = f(x)+g(x)                   (1)
and use its interval extension in the B&B.

I used + in (1) because it is defined on all of R^2. Using - or * would do equally well.

Cheers

John