Error computing limits as x -> inf

[Chris Pem10]

Finding the limit of (2*x)/(x+1) as x -> infinity gives different results when computed in the CAS vs the HOME environments.

The CAS gives the correct answer: 2

The HOME environment gives (2*inf)/(inf + 1)

Both above results were computed on a physical calc.

The emulated calc gives the correct answer in the CAS, but returns the limit un-evaluated in the HOME environment.

[Joe Horn]

(10-09-2014 04:47 AM)Chris Pem10 Wrote:  Finding the limit of (2*x)/(x+1) as x -> infinity gives different results when computed in the CAS vs the HOME environments.

The CAS gives the correct answer: 2

The HOME environment gives (2*inf)/(inf + 1)

Both above results were computed on a physical calc.

The emulated calc gives the correct answer in the CAS, but returns the limit un-evaluated in the HOME environment.

Following the design philosophy that CAS is for exact symbolic math and Home is for floating-point approximations, it's more appropriate to use something like limit(2*X/(X+1),X,1ᴇ50) in Home to get the desired answer, using 1e50 as an "approximation for infinity".

[Chris Pem10]

I'd prefer that the calc not give me just enough rope to hang myself. If the HOME environment is not capable of performing limits at infinity, perhaps the calc should auto-magically substitute 1E50 for inf. And by substitution, I mean flash a warning that the substitution is happening and why.

It makes zero sense to have a working limit function in the CAS and a second version in HOME that fails. You cannot assume that the student will be smarter than the machine and capable of working around its quirks.

[Joe Horn]

(10-09-2014 01:28 PM)Chris Pem10 Wrote:  I'd prefer that the calc not give me just enough rope to hang myself. If the HOME environment is not capable of performing limits at infinity, perhaps the calc should auto-magically substitute 1E50 for inf. And by substitution, I mean flash a warning that the substitution is happening and why.

Approximating infinity is a tricky business. 1E50 only works sometimes, for some problems. Some problems require a smaller value, because 1E50 would overflow. Other problems require a larger value, because 1E50 isn't big enough to converge on the desired result. And sometimes NO value suffices. Thinking and understanding are required on the part of the user. No machine can do that for you.

(10-09-2014 01:28 PM)Chris Pem10 Wrote:  It makes zero sense to have a working limit function in the CAS and a second version in HOME that fails.

I respectfully disagree. Expecting Home (which is a non-symbolic, floating-point approximation number cruncher only) to "understand" infinity (purely symbolic) reveals a misunderstanding of what Home is and how it works. Wanna crunch finite numbers in a 12-digit-approximation floating-point environment? Use Home. Wanna perform symbolic math on things like exact pi and infinity and undefined variables? Use CAS. They are different tools for different purposes.

(10-09-2014 01:28 PM)Chris Pem10 Wrote:  You cannot assume that the student will be smarter than the machine and capable of working around its quirks.

Assume? I assume nothing. I rather require ALL my students to be smarter than their calculators, and when they're not, I teach them well until they become smarter than their calculators. I fondly hope that the same expectation can be extended to the august membership of MoHPC.

Quirks? Behaviors which are unexpected due to misunderstanding of Prime are not quirks.

A general principle of tool usage is: If you don't understand a tool, it won't do what you want it to do. CAS and Home are two different tools, with different purposes, and with their own rules which must be understood to be used correctly. Home and CAS cannot be expected to be the same as each other; otherwise, why have both? The fact that Phillips screwdrivers strip flathead screws is not a bug in the design of Phillips screwdrivers, but rather reveals that the user does not understand the reason for the existence of both types of screws, and how and when to use their respective tools. Ok, that's a screwy analogy, but I hope you get my drift.

[Chris Pem10]

Thank you for your long response. I do not agree with everything you've stated; but that's OK... we simply have different expectaions from the same machine.

[Chris Pem10]

Here is a different example with a limit at infinity. This time performed within the CAS environment. The correct answer is 9/7

   

I dont have xcas installed locally to see what the result is there.

[dbbotkin]

The problem isn't just the limit; the magnitude of the exponents blows past the calculation ability of 64bit registers. I tried scaling back the exponents to 19, 7 and 19, 6, and the CAS gives the expected 9/7 answer for Lim ∞.

"Infinity is a very long time, particularly near the end" (Woody Allen)

Other than to make a point, what is the rationale for the magnitude of the exponents? I mean, if it converges to 9/7 at E26, why expect things to change much "near the end"?

[parisse]

The explanation is not far, but not exactly that. The max series expansion order is reached because of a missing rewrite at some point, and it is not well handled.

[Chris Pem10]

(10-11-2014 02:35 AM)dbbotkin Wrote:  Other than to make a point, what is the rationale for the magnitude of the exponents? I mean, if it converges to 9/7 at E26, why expect things to change much "near the end"?

The problem was taken from an online Calc quiz at (The) Ohio State. I double checked my answer with a 50G and found the error.

As for their "rationale" for toying around with exponets approaching 70: perhaps some guys just like watching the world burn.

I'll leave with a few quotes:

"We didn't know if we could find the limit of a polynomial fraction with an exponent approaching 70... but it was our duty to try... That's the way I looked at it. Now you've got guys in space vehicles, smoking along at exponents greater than 70... speed is relative..." (Chuck Yeager)

"If you're not failing every now and then, it's a sign you're not doing anything very innovative" (Woody Allen)

[dbbotkin]

Maybe I'm missing something, but in the problem posed, it is 'x' that is being pushed to infinity and raising 'x' to large powers in both the numerator and denominator just turns the problem into (-9/-7) * 1 more quickly. Solvable by inspection, I think. Possibly, that was the point of the question?

There is still some confusion as to whether the Prime has a glitch in its algorithm or not.

It is also possible that someone decided that E59 (or some other large number) was close enough to infinity for the 50G calculator.

We should remember that modern computers are digital devices and have limitations on the magnitude and precision of their calculations. CAS helps when solving equations exactly and RPN is quicker for some purposes, but they are both just tools for the mind.

[Chris Pem10]

I'm completely guessing here... and I've stolen the following text below from this site:

http://www.millersville.edu/~bikenaga/ca...mprop.html

"The limit of a sum is the sum of the limits."
"The limit of a product is the product of the limits."
"The limit of a power is the power of the limit."
"The limit of a quotient is the quotient of the limits" --- provided that the denominator does not become 0 when you plug in.

So I imagine the HP 50 manages to decompose the poly fraction step by step until each individual term becomes a trivial limit, then reconstitutes them back into a solution.

Perhaps the Prime does the same and just makes an error.

Here's a high degree polynomial fraction that the Prime gets right. It is a simple poly fraction to tear down with limit rules too:

lim x-> inf of (7 x^499 + 1)/(-10 x^401) = -inf

The HP 50 got it right in 18 seconds and the Prime got it right before the enter button even had time to spring back up... fast !

[parisse]

The algorithm for giac and the Prime is the mrv, aka most rapidly varying variable.
It can handle pretty complicated limit, my regression tests are:

Code:


limit( exp(x)*(exp(1/x-exp(-x))-exp(1/x)), x=+infinity);
limit( exp(x)*(exp(1/x+exp(-x)+exp(-x**2))-exp(1/x-exp(-exp(x)))), x=+infinity);
limit( exp(exp(x-exp(-x))/(1-1/x))-exp(exp(x)), x=+infinity);
limit( exp(exp(exp(x)/(1-1/x)))-exp(exp(exp(x)/(1-1/x-ln(x)**(-ln(x))))), x=+infinity);
limit( exp(exp(exp(x+exp(-x))))/exp(exp(exp(x))), x=+infinity);
limit(exp(exp(exp(x)))/exp(exp(exp(x-exp(-x)))),x=+infinity);
limit(exp(exp(exp(x)))/exp(exp(exp(x-exp(-exp(exp(x)))))),x=+infinity);
limit(exp(exp(x))/exp(exp(x-exp(-exp(exp(x))))),x=+infinity);
limit(x*ln(x)*ln(x*exp(x)-x**2)**2/ln(ln(x**2+2*exp(exp(3*x**3*ln(x))))),x=+infinity);
limit((exp(x*exp(-x)/(exp(-x)+exp(-2*x**2/(x+1))))-exp(x))/x,x=+infinity);
limit((3**x+5**x)**(1/x),x=+infinity);
limit(x/ln(x**(ln(x)**(ln(2)/ln(x)))),x=+infinity);
limit(exp(exp(2*ln(x**5+x)*ln(ln(x))))/exp(exp(10*ln(x)*ln(ln(x)))),x=+infinity);
limit((exp(4*x*exp(-x)/(1/exp(x)+1/exp(2*x**2/(x+1))))-exp(x))/exp(x)**4,x=+infinity);
limit(exp(x*exp(-x)/(exp(-x)+exp(-2*x**2/(x+1))))/exp(x),x=+infinity);
limit( exp(exp(-x/(1+exp(-x))))*exp(-x/(1+exp(-x/(1+exp(-x)))))*exp(exp(-x+exp(-x/(1+exp(-x)))))/exp(-x/(1+exp(-x)))**2-exp(x)+x, x=+infinity);
limit( (ln(ln(x)+ln(ln(x)))-ln(ln(x)))*ln(x)/ln(ln(x)+ln(ln(ln(x)))), x=+infinity);
limit(exp(ln(ln(x+exp(ln(x)*ln(ln(x)))))/ln(ln(ln(exp(x)+x+ln(x))))),x=+infinity);
limit(exp(x)*(sin(1/x+exp(-x))-sin(1/x+exp(-x**2))),x=+infinity);
limit(exp(exp(x))*(exp(sin(1/x+exp(-exp(x))))-exp(sin(1/x))),x=+infinity);
limit( (exp(x*exp(-x)/(exp(-x)+exp(-2*x**2/(x+1))))-exp(x))/x,x=+infinity);
limit( ln(ln(x*exp(x*exp(x))+1))-exp(exp(ln(ln(x))+1/x)), x=+infinity);
limit(sqrt(x+sqrt(x))-sqrt(x),x=+infinity);
limit(sqrt(x+sqrt(x+sqrt(x)))-sqrt(x+sqrt(x)),x=+infinity);
limit(4/9*exp(exp(5/2*x**(-5/7)+21/8*x**(6/11)+2*x**(-8)+54/17*x**(49/45)))**8/ln(ln(-ln(4/3*x**(-5/14))))**(7/6),x=+infinity);
limit(ln(x)**2*exp(sqrt(ln(x))*ln(ln(x))**2*exp(sqrt(ln(ln(x)))*ln(ln(ln(x)))**3​))/sqrt(x),x=+infinity);