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