MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Interval arithmetic bug

  • To: mathgroup at smc.vnet.net
  • Subject: [mg90783] Re: [mg90761] Interval arithmetic bug
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Thu, 24 Jul 2008 04:52:11 -0400 (EDT)
  • References: <200807230958.FAA28179@smc.vnet.net>

On 23 Jul 2008, at 11:58, green tea wrote:

> In[1]:= Limit[Sin[x], x -> Infinity]
>
> Out[1]= Interval[{-1, 1}]
>
>
>
>
> In[2]:= Limit[Sin[x + Pi/4], x -> Infinity]
>
> Out[2]= Interval[{-Sqrt[2], Sqrt[2]}]
>
>
>
>
> In[3]:= TrigExpand[Sin[x + Pi/4]]
>
> Out[3]= Cos[x]/Sqrt[2] + Sin[x]/Sqrt[2]
>
>
>
>
> In[4]:= (Limit[#1, x -> Infinity] & ) /@ {Cos[x]/Sqrt[2],
>  Sin[x]/Sqrt[2]}
>
> Out[4]= {Interval[{-(1/Sqrt[2]), 1/Sqrt[2]}],
>   Interval[{-(1/Sqrt[2]), 1/Sqrt[2]}]}
>
>
>
>
> In[5]:= Plus @@ %
>
> Out[5]= Interval[{-Sqrt[2], Sqrt[2]}]
>
>
>
>
> In[6]:= $Version
>
> Out[6]= "6.0 for Microsoft Windows (32-bit) (May 21, 2008)"
>
>
>
>
> oh my god..
>


What do you mean by a "interval arithemtic bug"?. Interval arithmetic  
behaves exactly as it should, and it is perfectly correct that:

Interval[{-(1/Sqrt[2]), 1/Sqrt[2]}] +
    Interval[{-(1/Sqrt[2]), 1/Sqrt[2]}]
Interval[{-Sqrt[2], Sqrt[2]}]

It is also quite correct that:

Sin[# + Pi/4] &@Interval[{-Infinity, Infinity}]
Interval[{-1, 1}]

and also this:

Cos[#]/Sqrt[2] + Sin[#]/Sqrt[2] &@Interval[{-Infinity, Infinity}]
  Interval[{-Sqrt[2], Sqrt[2]}]

The reason is that interval arithmetic is *supposed to* only return  
"upper bounds", that is unions of intervals that contain the "correct  
answer". They will in general be larger than the optimal interval and  
will be different for different expressions even when they are  
mathematically equivalent. All of these are well known and "normal"  
properties of interval arithmetic and there is nothing buggy about  
the. The reason for this is that the purpose of interval arithmetic is  
estimation of errors and proofs of convergence. What one normally uses  
interval arithmetic to do is showing that the error in some  
computation is less than some specified number. For this reason it is  
enough to obtain any interval that of length smaller than the one that  
is required, and the fact that this interval may be much larger than  
the minimal one, is less important then the computational efficiency  
of the procedure.

In fact the only issue involved here it is not an "interval arithmetic  
bug" but of imprecise documentation of Limit. Te problem is that  
interval arithmetic only tries to find an "upper bound" for the range  
of the function whose limit is being computed but the documentation  
for Limit says

Limit returns Interval  objects to represent ranges of possible  
values, for example at essential singularities.

The word "represent" suggests that the interval object returned by  
Limit[f[x],x->a] consists of all the limit points of the function f  
for all sequences x_n->a, but actually what is returned is an interval  
object that contains all such points but which also contains points  
that are not themselves limits of the given function. I think this  
ought to be made more clear, that's all.

Andrzej Kozlowski



  • Prev by Date: Re: Can't integrate sqrt(a+b*cos(t)+c*cos(2t))
  • Next by Date: Re: Can't integrate sqrt(a+b*cos(t)+c*cos(2t))
  • Previous by thread: Interval arithmetic bug
  • Next by thread: Re: Interval arithmetic bug