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