[Date Index]
[Thread Index]
[Author Index]
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**
| |