Re: Re: Got a trouble with the Limit[]
- To: mathgroup at smc.vnet.net
- Subject: [mg22933] Re: [mg22864] Re: [mg22760] Got a trouble with the Limit[]
- From: Andrzej Kozlowski <andrzej at bekkoame.ne.jp>
- Date: Thu, 6 Apr 2000 02:04:49 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
on 4/3/00 4:33 AM, Kai G. Gauer at gauer at sk.sympatico.ca wrote:
> Andrzej Kozlowski wrote:
>
>> on 00.3.24 5:28 PM, mason at mhl at tpts1.seed.net.tw wrote:
>>
>>> Dear all,
>>> I had a trouble presenting the limit of a multiple defined function.
>>> I set f[n_,x_]:=(1-(1+x)^-n)/x /; x>0&&x<1;
>>> f[n_,x_]:=0 /; x<=0 || x>=1;
>>> But I don't know how to show that
>>> Limit[f[n_,x_], n->Infinity] equals to 1/x, when 0<x<1
>>> Limit[f[n_,x_], n->Infinity] equals to 0, elsewhere.
>>> Regards
>>> Mason Lee
>>>
>>>
>>>
>>
>> Are you sure this is right? (Your function is discontinuous at x=1).
>> Anyway, what exactly do you mean by "I don't know how to show that..."? I
>> assume that you know how to show this without using a computer just by
>> referring to the elementary fact that a^(-x)->0 as x->Infinity if a>1 .
>> Mathematica cannot tell you this since there is not way to pass to it the
>> information that a>1 (Simplify with Assumptions in Mathematica 4 does not
>> work with
>> Limit[]). In addition there is a second problem, which is that
>> Mathematica's Limit[] does not accept as input functions defined by multiple
>> rules, even in cases like this:
>>
>> In[1]:= Clear[f]
>>
>> In[2]:= f[x_] /; x < 1 := x;
>>
>> In[3]:= f[x_] /; x >= 1 := x;
>>
>> In[4]:= Limit[f[x], x -> 1]
>>
>> Out[4]= Limit[f[x], x -> 1]
>>
>> One could easily teach Mathematica do deal with such trivial cases but in my
>> opinion there is no point in doing so. In any case Mathematica cannot
>> "really" find limits or "prove" much about them.
>
> Everybody know that, but that's not really much of an excuse on
> Mathematica's behalf! Remember the IEEE who brought us the standard
> 32-bit style of doing interval arithmetic the "best" way (their idea
> was to choose the intervals most uniformily to get "nice"
> approximations when searching for k points of a big "interval" of
> 2^2^(huh) (where huh is your favourite big number that would best
> satisfy you)). Unfortunately, this seems to be partially
> pseudo-excusable on Mathematica's behalf. After all, who really needs
> to print off the first ten billion digits of pi to your nearest t-shirt
> when you have the Ramanujan formula for getting the nth digit (much
> easier, since it's not as recursively dependent)?!?!?!?!! If you only
> need to plot or something, do a couple hundred sample points at most
> and hope for the best (if you can't hope for the best, chances are that
> you probably won't be able to prove your search results too much more
> rigourously either...look at the latest search of lim tan(x)/x^8 in the
> MAA periodicals). Most computer screens or printers (nor people who
> build them) just won't build a stronger resolution monitor, simply
> because we all ready have the best there is (limited to our eyes and
> the size of our audio cards). If you're looking at proofs, use
> L'hopital's rule a few hundred times (with approximations of limits
> subbed in when you don't know the exact value, and of course, you
> usually won't, unless you get very lucky in your differentiation). By
> the way, L'Hospital's Rule doesn't always work well, or even any better
> than when you started with: I know of at least one function (doesn't
> involve dirichlet type functions or anything like that, I even suspect
> it's quite continuous for most points, though I can't find out what it
> is) ..something to the effect of now matter how you split it up into
> numerator and denominator (where both are going to 0 or oo), there
> aren't too many obvious ways to split it in such a way that the nth
> application ofL'Hospital's derivative tells you exactly how much better
> you may or may not be getting. What I do remember about this function,
> however, is that after applin Hospital's rule twice (running the test
> to make sure it's still of proper form) is that you get the same
> function back as what you started with. To this day, I know of no way
> to choose the numerator and denominator to get rid of this sort of
> periodicity, to extend the interval (so that we may not notice this for
> two or more iterations) or whether when finding one such num-denom form
> means that we'll ALWAYS find other similar num-denom forms. Like I
> said, I don't explicitly have the nice, relatively simple to state fcn
> on me but I o know that it exists. However, that's basically all I know
> about it. If you know other things about this bad behaviour, please
> tell me!
>
>> Limits properly speaking
>> belong to analysis which deals with continuous phenomena while computers are
>> by nature discrete. Mathematica can only deal with a relatively small number
>> of cases which can be reduced to some basic facts that are a part of its
>> "knowledge data base" by applying certain algebraic ("discrete")
>> procedures.( One example of such an algebraic procedure is the "L'Hospital
>> rule"). However, genuine proofs in analysis take the form of "epsilon-delta"
>> arguments, only the simplest cases of which can at this time be tackled by
>> "theorem proving" systems and none at all by Mathematica. In any case one
>> should never try to use a computer to do something that is easy to do by
>> hand, particularly in mathematics.
>>
>> --
>> Andrzej Kozlowski
>> Toyama International University
>> Toyama, Japan
>> http://sigma.tuins.ac.jp/
>
I must admit I am not at all sure what you are trying to say. The point I
was making is that (in my opinion) Mathematica and other computer programs
are suitable for dealing with problems which are "mathematically trivial"
and at the same time "computationally non-trivial". By "mathematically
trivial" I mean all those cases where a definite algorithm exists which will
in time lead to a solution. The meaning of "computationally non-trivial" is,
I think, pretty obvious. Lots of problems in analysis belong to the
mathematically non-trivial category.(I consider everything that can be done
using the L'Hospital rule as mathematically trivial). Of course even in such
cases a computer program can be of some value but can't provide you with a
complete solution by itself. In fact (as I expect everyone knows) you have
to be quite careful how you use it. For example consider the folowing limit
problem:
In[1]:=
Limit[n*Sin[2Pi*E*n!]/(2Pi), n -> Infinity]
---complaints from Mathematica--
Out[1]=
Limit[n Sin[2 E Pi n!], n -> Infinity]
--------------------------------------
2 Pi
Mathematica can't do this although I can quite easily prove that the answer
is 1.
Even if you try to use a numerical approach to get an idea (not a proof) of
what this limit is you have to be careful. A straight forward approach will
lead you astray:
In[2]:=
g[n_] := N[n*Sin[2Pi*E*Factorial[n]]/(2Pi)]
In[3]:=
Table[g[n], {n, 100, 1000, 100}]
Out[3]=
{-5.93642, 0., 0., 0., 0., 0., 0., 0., 0., 0.}
Totally wrong! What you have to do is something like:
In[4]:=
g[n_] := SetPrecision[n*Sin[2Pi*E*Factorial[n]]/(2Pi), 10000]
Then:
In[6]:=
Table[N[g[n]], {n, 100, 1000, 100}]
Out[6]=
{0.999243, 0.999811, 0.999916, 0.999953, 0.99997, 0.999979,
0.999985, 0.999988, 0.999991, 0.999992}
Of course the orignal problem that started this thread was of a completely
different kind. That proplem was of the "computationally trivial" type,
which according to the above "principle", should not be done by means of a
computer at all. I admit that the fact that you can't imput assumptions
about parameters into Limit is a (minor) weakness, and I do not think that
the fact that it does not work with with functions defined by conditional
statements is of any practical importance. As I wrote at te beginning of
this message, I can't see what else there is here to argue about (?)
Andrzej Kozlowski
Toyama International University
JAPAN