when did lim(sin(x),x->inf) become interval [-1,1]?
Richard Fateman
intervals) for result of limit computations available?
The usual epsilon-delta definition of limit does not
work with this usage. And I suspect that more often
than not, this "result" cannot be used in most
normal contexts of intervals. (There are a few
possible interpretations, but one is, I think,
that a variable v with value [-1,1] is a particular
point between -1 and 1, but we don't know which
one. )
in Mathematica 5.0
consider z= Sin[x]-Sin[x*(1-Exp[-x])]
Limit[z,x->Infinity] which should be 0.
it comes out an interval [-2,2]. Strictly speaking, the
answer IS inside this interval, but that is a poor answer,
it seems to me.
If you take the derivative of z with respect to x and
ask for its limit, Mathematica seems to take forever.
RJF
Joe Riel
> in Mathematica 5.0
> consider z= Sin[x]-Sin[x*(1-Exp[-x])]
> Limit[z,x->Infinity] which should be 0.
> it comes out an interval [-2,2]. Strictly speaking, the
> answer IS inside this interval, but that is a poor answer,
> it seems to me.
Maple (9 and 10) do likewise;
limit(sin(x)-sin(x*(1-exp(-x))),x=infinity);
-2 .. 2
Joe
Alec Mihailovs
news:87bqzdu...@k-online.com...
>
> Maple (9 and 10) do likewise;
>
> limit(sin(x)-sin(x*(1-exp(-x))),x=infinity);
>
> -2 .. 2
Maple still can get the correct answer,
z:=sin(x)-sin(x*(1-exp(-x))):
simplify(z) &/ (sin(x_)&+sin(y_)=trigsubs(sin(x)+sin(y))[]);
2 sin(x/2 + 1/2 x (-1 + exp(-x))) cos(- x/2 + 1/2 x (-1 + exp(-x)))
limit(%,x=infinity);
0
I used here the procedure &/ defined in
http://beta.mapleprimes.com/blog/alec/pattern-based-transforms
Alec
Alec Mihailovs
news:jlppf.1623$EE4...@news02.roc.ny...
>
> z:=sin(x)-sin(x*(1-exp(-x))):
>
> simplify(z) &/ (sin(x_)&+sin(y_)=trigsubs(sin(x)+sin(y))[]);
>
> 2 sin(x/2 + 1/2 x (-1 + exp(-x))) cos(- x/2 + 1/2 x (-1 + exp(-x)))
>
> limit(%,x=infinity);
> 0
>
> I used here the procedure &/ defined in
> http://beta.mapleprimes.com/blog/alec/pattern-based-transforms
The followng also works,
z &/ (sin(x_)&+((-1)&*sin(y_))=trigsubs(sin(x)-sin(y))[]);
2 cos(- x/2 - 1/2 x (1 - exp(-x))) sin(x/2 - 1/2 x (1 - exp(-x)))
limit(%,x=infinity);
0
Alec
Robert Israel
Richard Fateman <fat...@cs.berkeley.edu> wrote:
>Is there any defense of this notion (i.e. use of
>intervals) for result of limit computations available?
To some extent it's an admission of failure: the CAS is saying
it couldn't find a limit, but it knows if there is one it's in
this interval. In the case of limit(sin(x),x=infinity), [-1,1]
is actually the set of limit points of the function as x -> infty,
but that can't be relied on. According to Maple's help page
?limit,return:
If limit returns a numeric range it means that the value of the limiting
expression is known to lie in that range for arguments restricted to some
neighborhood of the limit point. It does not necessarily imply that the
limiting expression is known to achieve every value infinitely often in
this range.
BTW, the first sentence is not true, e.g. limit(1/x + sin(x), x=infinity)
also returns -1..1.
Robert Israel isr...@math.ubc.ca
Department of Mathematics http://www.math.ubc.ca/~israel
University of British Columbia Vancouver, BC, Canada
Christopher Creutzig
> Is there any defense of this notion (i.e. use of
> intervals) for result of limit computations available?
There are cases where having these values as the “limits” of
subexpressions make computing the overall limit at least easier. Think
of limit(sin(x)/x, x=infinity). What is more, the result does give more
information to the user than a simple “sorry Dave, I can't do that.”
> The usual epsilon-delta definition of limit does not
> work with this usage. And I suspect that more often
It does tell you that all the accumulation points (if that is the
correct English term) are within the interval. I do agree that a CAS
should only return an interval for a limit comoutation when explicitly
asked for one, but using them internally is often a good idea. (It
should be hardly surprising that MuPAD does exactly what I advocate here.)
> than not, this "result" cannot be used in most
> normal contexts of intervals. (There are a few
> possible interpretations, but one is, I think,
> that a variable v with value [-1,1] is a particular
> point between -1 and 1, but we don't know which
> one. )
That is, as you say yourself, but one interpretation of intervals. In
interval analysis, intervals are quite often treated as objects in their
own right. Intervals are also often used in a CAS context for definite
integration or the results of “discont” calls, both of which have again
different meanings.
regards,
Christopher Creutzig
Jean-Marc Gulliet
Qdnpf.31095$BZ5....@newssvr13.news.prodigy.com...
| Is there any defense of this notion (i.e. use of
| intervals) for result of limit computations available?
|
| The usual epsilon-delta definition of limit does not
| work with this usage. And I suspect that more often
| than not, this "result" cannot be used in most
| normal contexts of intervals. (There are a few
| possible interpretations, but one is, I think,
| that a variable v with value [-1,1] is a particular
| point between -1 and 1, but we don't know which
| one. )
|
| in Mathematica 5.0
| consider z= Sin[x]-Sin[x*(1-Exp[-x])]
| Limit[z,x->Infinity] which should be 0.
| it comes out an interval [-2,2]. Strictly speaking, the
| answer IS inside this interval, but that is a poor answer,
| it seems to me.
Well, you help the built-in function *Limit* to find a definite value by
transforming trigonometric expressions into exponentials:
In[1]:= expr = Sin[x] - Sin[x*(1 - Exp[-x])];
In[2]:= Limit[TrigToExp[expr], x -> Infinity]
Out[2]= 0
|
| If you take the derivative of z with respect to x and
| ask for its limit, Mathematica seems to take forever.
If "forever" means a dozen of seconds, yes :-)
Again, the limit of the first derivative returns an interval whereas
converting trig to exp first allows the limit to be computed:
In[3]:= Limit[D[expr, x], x -> Infinity]
Out[3]= Interval[{-2, 2}]
In[4]:= Limit[TrigToExp[D[expr, x]], x -> Infinity]
Out[4]= 0
In[5]:= $Version
Out[5]= 5.2 for Microsoft Windows (June 20, 2005)
/J.M.
Daniel Lichtblau
The various responses cover what I would say but I want to emphasize
two points.
(1) An interval result for e.g. Sin[x] as x->infinity is useful for
situations in which further processing might be done. For example,
definite integration might use the fact that an integrand factor is
bounded in order to deduce convergence.
(2) For your example above, getting an interval from -2 to 2 is okay
but clearly less desirable than a result of zero. Bug? Feature? A bit
of each, I'd say. Again, the interval is better than no result at all
at least for the sort of purpose I indicate above.
I will also note that the Mathematica timing of the derivative limit is
going to improve. Here is what I get in the development kernel.
In[9]:= Timing[Limit[D[z,x], x->Infinity]]
Out[9]= {0.680043 Second, Interval[{-2, 2}]}
Version 5.2 appears to take about a minute, and from the sounds emitted
on my machine I'd guess it is trying to catch its breath.
Daniel Lichtblau
Wolfram Research
Rouben Rostamian
OK, here is another Maple experiment:
> restart;
> z1 := sin(x)-sin(x)*cos(x*exp(-x)):
> z2 := factor(z1):
> limit(z1, x=+infinity);
-2 .. 2
> limit(z2, x=+infinity);
0
It appears that in the case of z1, Maple applies the rule
lim(A+B) = lim(A)+lim(B) and obtains the weird result.
In case of z2, it applies the rule lim(A*B) = lim(A)*lim(B)
and obtains the expected result.
I don't know to what extent a CAS can be trained to do the
right thing with such a problem.
--
Rouben Rostamian
Richard Fateman
Thanks.
On your suggestion, as well as following up on DanL's comment
(later), I let it run to completion and it took 179 seconds.
[Mathematica 5.0 on a 933Mhz Pentium].
but the answer came out [-inf,inf]. We
agree that a more useful answer would be 0.
As I said, and no one seems to have disputed, this notion of
limit violates the definition of limit. Or is there any way
that epsilon-delta can be said to work??
The fact that the "limitand" (by analogy with integrand?)
could be simplified to make it simpler to compute the limit, is not in
dispute. It seems to me that it should be part of the limit
command. Perhaps if we were less accepting of answers like
[-Inf,Inf] and encouraged the Limit program to keep trying, we
would get better answers. Arguably we could return, really
fast, from any (real-valued) limit computation, with [-Inf,Inf], and not
be "wrong" exactly.
RJF
Joel Storch
z=Sin[x]-Sin[x (1-Exp[-x])]
Limit[TrigToExp[z],x-> Infinity] yields 0.
Maths For Fun And Insight
> Is there any defense of this notion (i.e. use of
> intervals) for result of limit computations available?
>
> The usual epsilon-delta definition of limit does not
> work with this usage. And I suspect that more often
> than not, this "result" cannot be used in most
> normal contexts of intervals. (There are a few
> possible interpretations, but one is, I think,
> that a variable v with value [-1,1] is a particular
> point between -1 and 1, but we don't know which
> one. )
>
> in Mathematica 5.0
> consider z= Sin[x]-Sin[x*(1-Exp[-x])]
> Limit[z,x->Infinity] which should be 0.
> it comes out an interval [-2,2]. Strictly speaking, the
> answer IS inside this interval, but that is a poor answer,
> it seems to me.
Is Maxima's answer any better?
(%i9) limit(sin(x) - sin(x*(1-exp(-x))),x,inf);
(%o9) ind
> If you take the derivative of z with respect to x and
> ask for its limit, Mathematica seems to take forever.
Maxima doesn't take any time - but again gives only the "indefinite but
bounded" answer:
(%i10) diff(sin(x) - sin(x*(1-exp(-x))),x);
(%o10) cos(x)-(x*%e^-x-%e^-x+1)*cos(x*(1-%e^-x))
(%i11) limit(%, x, inf);
(%o11) ind
I'm not criticising Maxima (I love it) - just wondering why you're
expecting a higher standard of Mathematica.
> RJF
Alec Mihailovs
news:1135282910.8...@f14g2000cwb.googlegroups.com...
>
> I'm not criticising Maxima (I love it) - just wondering why you're
> expecting a higher standard of Mathematica.
Just because one has to pay a few thousands dollars to use it - isn't that
good enough to expect a proper answer for such a simple problem?
Alec
Richard Fateman
as to a particular date on which this happened.
My intention was to see if anyone else cared about
the use of the same notation for intervals as for
"bounded variation". I guess not.
As for what Maxima does, I think it answers the
question in the epsilon-delta sense.
I suppose one could hope for some kind of limsup & liminf
notation as an alternative. e.g. a program could be written
that tried limit, and then if that gave an inadequate answer,
say ind, would ask another question.
Since Maxima's limit program is open source and has
been available for examination for over 23 years, I would
expect programs written 10 or 20 years later to be at
least as good.
Arguably, here Maxima gives the write answer, and Mathematica's
is misleading.
RJF
Robert H. Lewis
> <Qdnpf.31095$BZ5....@newssvr13.news.prodigy.com>,
> Richard Fateman <fat...@cs.berkeley.edu> wrote:
> >Is there any defense of this notion (i.e. use of
> >intervals) for result of limit computations
Certainly not for education in a calculus course.
>.... In the case of
> limit(sin(x),x=infinity), [-1,1]
> is actually the set of limit points of the function
> as x -> infty,
> but that can't be relied on. According to Maple's
> help page
> ?limit,return:
>
> If limit returns a numeric range it means that the
> e value of the limiting
> expression is known to lie in that range for
> r arguments restricted to some
> neighborhood of the limit point. It does not
> t necessarily imply that the
> limiting expression is known to achieve every value
> e infinitely often in
> this range.
>
> BTW, the first sentence is not true, e.g. limit(1/x +
> sin(x), x=infinity)
> also returns -1..1.
>
> Robert Israel
As a professor at a major university who often teaches calculus, I find the facts in this thread unfortunate and disturbing.
That a major CAS says that lim(sin(x),x->inf) = the interval [-1,1] is inexcusable. This is just plain wrong. The limit does not exist. Students will get confused. I can hear it now, "but the computer says...."
Robert Israel's point is well taken. Also, apparently he is saying that the syntax in Maple is
limit(sin(x),x=infinity)
If so, this is very bad syntax. x never "equals" infinity. That's a point we stress in the definition of limit to beginners.
Robert H. Lewis
Mathematics
Fordham University
Alec Mihailovs
news:10136628.1135440837...@nitrogen.mathforum.org...
>
> As a professor at a major university who often teaches calculus, I find
> the facts in this thread unfortunate and disturbing.
>
> That a major CAS says that lim(sin(x),x->inf) = the interval [-1,1] is
> inexcusable. This is just plain wrong. The limit does not exist.
> Students will get confused. I can hear it now, "but the computer
> says...."
Mathematics in CAS and mathematics taught in a calculus course is quite
different. When I use Maple in a calculus course, the first thing that I say
to students is that they shouldn't think that similar notations in it mean
the same things. Limit in Maple is not limit in calculus. Int is quite
different from integral in calculus. In Maple an integral of a continuous
function can be discontinuous. Even derivatives mean something different -
they have property
diff(f(x,y),x,y)-diff(f(x,y),y,x);
0
>
> Robert Israel's point is well taken. Also, apparently he is saying that
> the syntax in Maple is
>
> limit(sin(x),x=infinity)
>
> If so, this is very bad syntax. x never "equals" infinity. That's a
> point we stress in the definition of limit to beginners.
That actually is not that bad - it is just a notation used in the input. An
arrow can't be used, because Maple uses it for a different purpose - for
definition of functions. In the output the limit looks almost normal - with
an arrow (well, it doesn't look normal for right and left limits, but it is
a different story).
Some attemt of making mathematics in Maple closer to mathematics in Calculus
has been done in Student:-Calculus1 package.
In particular, as Thomas Madden pointed out,
Student:-Calculus1:-LimitTutor(sin(x),x=infinity);
gives the answer undefined.
Alec Mihailovs
http://math.tntech.edu/alec/
Richard Fateman
>
> Mathematics in CAS and mathematics taught in a calculus course is quite
> different.
I think there are a few good reasons for this, and a few bad reasons.
Good reasons:
1. The calculus student is not mathematically sophisticated. Therefore
some answers that a CAS produces that are mathematically correct
from a more advanced standpoint, look to the calculus student as
wrong. Things like log( negative value) require complex analysis,
unknown to calc students.
2. The mathematics in a CAS is "algorithmic" and the techniques used
can be quite different from the calculus student [The phrase
"constructive mathematics" is quite different in meaning, and from
the algorithm perspective mostly irrelevant].
Bad reasons:
3. The CAS is mathematically incorrect. That is, there exists a correct
answer but it is not computed. Or there is no answer, but the CAS
returns one, anyway. I call these bugs; others defend them on the
grounds that "the program is behaving as it was programmed to behave."
This converts the reason into the next one:
4. The CAS is not designed correctly. That is, there is a "feature"
that is, mathematically speaking, erroneous. This can be "corrected"
only by violating the mathematical sense or logic that
might be part of the user's education or understanding of math.
5. (Often the cause of the previous two) The programmer/designer of
the CAS did not use "the best" mathematics in the program, perhaps by
laziness, ignorance, or a quest for efficiency instead of correctness.
Occasionally it is a deliberate battle for conciseness at the expense of rigor
(e.g. misusing notions or notations like "=" for infinity, as RHL
mentions).
So I would generally caution students that computers may be good
at manipulation of expressions, but were designed and written
by fallible humans within a context that might not exactly match
theirs.
RJF
Alec Mihailovs
news:AFgrf.47313$6e1...@newssvr14.news.prodigy.com...
>
> Bad reasons:
>
> 4. The CAS is not designed correctly. That is, there is a "feature"
> that is, mathematically speaking, erroneous. This can be "corrected"
> only by violating the mathematical sense or logic that
> might be part of the user's education or understanding of math.
That is the major problem in Maple, I think. Unfortunately, absurd seems to
be increasing with every new release. For example,
int(Dirac(x), x=0..infinity);
was 1 in Maple 9.5 and now it became 1/2 in Maple 10 (same as in
Mathematica, by the way).
Alec
Richard Fateman
I am now trying Mathematica 5.1.
Notationally speaking, Limit [..., x->Infinity] may look better than ....
x= infinity,
but it is an abuse of the notation -> in Mathematica, which is used for
replacement rules.
and in FullForm looks like .... Rule[x,DirectedInfinity[1]]..
Anyway, I tried s = Sin[Exp[-x]+s]-Sin[x] and
computed Limit[s,x->Infinity]. You might notice that this expression
tends to 0, at least
as x goes off in the direction of positive real infinity. Mathematica
doesn't notice.
Reading in the NLimit package, this particular expression causes problems
related to computing 1/0; If I add the terms, in which case the "limit"
varies
between -2 and 2, it does not trigger any error messages for NLimit. Just
gives bogus answers.
By varying a parameter to NLimit, "terms" I got -1487.44 {terms=11}, and
other numbers like 0.026.
Disappointing.
RJF
"Alec Mihailovs" <al...@mihailovs.com> wrote in message
news:lNhrf.302$qg....@news02.roc.ny...
Albert Reiner
> Anyway, I tried s = Sin[Exp[-x]+s]-Sin[x] and
Shouldn't this be Sin[Exp[-x]+x]-Sin[x] ?
Albert.