Re: Limit of Infinitely Nested Expression (4.0

*To*: mathgroup at smc.vnet.net*Subject*: [mg71752] Re: Limit of Infinitely Nested Expression (4.0*From*: "dimitris" <dimmechan at yahoo.com>*Date*: Tue, 28 Nov 2006 06:04:07 -0500 (EST)*References*: <ek97sj$irp$1@smc.vnet.net><ekeb0h$svu$1@smc.vnet.net>

Dear Daniel, Thanks a lot for yor response. Your explanation is clear. I got the point! I really appreciate your assistance Best Regards Dimitris P.S. Thanks also to everyone else that replied me. danl at wolfram.com wrote: > > 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