Re: Re: Limit of Infinitely Nested Expression (4.0

*To*: mathgroup at smc.vnet.net*Subject*: [mg71698] Re: [mg71680] Re: Limit of Infinitely Nested Expression (4.0*From*: danl at wolfram.com*Date*: Mon, 27 Nov 2006 04:04:01 -0500 (EST)*References*: <ek97sj$irp$1@smc.vnet.net>

> I contacted Wolfram tech support about this bug. They replied that 4.0 > was in error, and that 5.2 is working as it should. (!) I don't buy > their argument. I think they should fix it, to make it possible to > compute the exact limit in this case. Nevertheless, here is their > reply: > > I believe that Mathematica is behaving correctly in > this example. > > Nest and NestList allow you to apply functions a fixed number of times. > In > this sense, the behavior of Ver. 5.X is correct while the behavior of > the > package "Limit" for Ver. 4 is inappropriate. > > Often you may want to apply functions until the result no longer > changes. > You can do this using FixedPoint. > > In[2]:= > FixedPoint[N[Sqrt[5 + #1] &, 40], N[5, 40]] > > Out[2]= > 2.791287847477920003294023596864004244492 > > Note that, the following won't terminate. > > In[3]:= > FixedPoint[Sqrt[5 + #1] &, 5] > > Out[3]= > $Aborted > > because "SameTest" is done symbolically. You may do > > In[4]:= > FixedPoint[Sqrt[5 + #1] &, 5.0000000000000000] > > Out[4]= > 2.791287 > > though it will take a lot more time if you add more "0"'s to the right > of > > 5.0000000000000000 > > This is again because of symbolic "SameTest." > > If you do want to symbolically compute the fixed point of the function, > then, as you pointed out, you have to manually solve the equation: > > In[5]:= > Solve[x == Sqrt[5 + x]] > > Out[5]= > 1 + Sqrt[21] > {{x -> ------------}} > 2 I have done work on Limit over the past few years so I can comment from that perspective. While I might have worded the response a bit differently, I side with Tech Support on this. Let me give a few reasons. Limit is designed to work on functions defined on a continuum, and known in a closed form. The function in question satisfies neither requirement. While it might be possible to find a closed form function that agrees with it at integers, it is not something that will be done automatically (indeed, such a function might or might not be what was "intended"). I'll note that when I tried I was not able to get such a function for this example using RSolve. It is true that the Calculus`Limit code had some tricks built in for handling examples such as this. Neat. (Or, if you are of the right age and from the English-speaking world, groovy). What it did not have was consistency or maintainability. The decision to scrap it was not exactly a difficult call; it was riddled with bugs and simply not fixable. Bottom line is that the Limit function was not designed or intended to handle functions defined on only a sequence of points, or to handle functions not given in explicit closed form. The Calculus`Limit function had limited (if you will) capabilities in this respect. It is correct to say that this particular aspect of the package function was not taken on by the built-in Limit. For examples such as this one gets results exactly as indicated in the TS response: use Solve to find an exact representation of the fixed point for the iteration. Daniel Lichtblau Wolfram Research