Mathematical Hacks and Tricks on the TI Calculator

[thornahawk]

Being the infrequent poster that I am, I do my utmost that any post I make is coherent and (seemingly) sensible. Now, I want to talk about little hacks you can do on a TI calculator for mathematical computations. (Sorry, no programs allowed in this thread. )

I'll start with the problem of computing infinite improper integrals. Sometimes, you might need to evaluate things like the integral of e^(-t²) from hither to yon (alright, for the archaic-naive, -∞ to ∞) or that of e^(-x)*ln(x) from 0 to ∞. Too bad there's no [∞] key on the calculator. Some wise guy might think of replacing the ∞ with 10^99 or some other beejezusly big number. It won't always work, though. :P

The nifty way of solving these problems is to first recognize that that the fnInt( function in the TI calculator isn't too fazed by improper integrals with finite limits.

fnInt(ln(X),X,0,1) ≈ -.999998347 (should have been -1, but I'd say pretty close )

Of course, singularities being a bane for most integrators, fnInt( will be a bit slower than usual.

Now the trick is in finding integral substitutions that will transform the infinite integral problem to a singular integral with finite limits. For the case of

fnInt(func(X),X,-∞,∞)

the appropriate transformation is

fnInt(func(tan(X))/cos(X)²,X,-π/2,π/2)

for instance,

fnInt(e^(-tan(x)²)/cos(X)²,X,-π/2,π/2) ≈ 1.772453851 (which is a pretty darn good approximation to √(π) )

while

fnInt(func(X),X,A,∞)

should be converted to

2fnInt(func(A+(1+X)/(1-X))/(1-X)²,X,-1,1)

like

2fnInt(e^(-(1+X)/(1-X))ln((1+X)/(1-X))/(1-X)²,X,-1,1) ≈ -.5772140119 (-γ to about 5 places)

Of course, for more accuracy, one would fiddle with the tolerance argument of fnInt( as well. :)

Any other tricks up your sleeve?

thornahawk

P.S. PM me if you want references.

[Jeremiah Walgren]

It's not really a hack or a trick, but I've found that evaluating limits on the graph screen has proved useful several times. It's very easy to see where things suddenly spin off to infinity doing that...

Of course, there are certain equations that render the method useless.

[thornahawk]

Ah, limits... I've written a program for approximating limits of sequences; I'll post it at the TI-BASIC forum if there's interest.

Back on topic: trick #2.

Sometimes, the default ε setting of nDeriv( (i.e., the stepsize used in the derivative approximation) just doesn't cut it. Sometimes, you just need to squeeze out more digits than usual. In any case, folks who have been fiddling with this function long enough should have already noticed that a smaller ε isn't necessarily better, cancellation of digits being the perfidious culprit. Too large an ε isn't that good either. Just how do you strike the happy medium?

J.C. Nash, in his book Compact Numerical Methods for Computers has the following prescription:

nDeriv(f(X),X,~any expression~,(abs(X)+10^-6)*10^-6)

Given that the default prescription of the TI calculator uses a fixed value for ε, it's relatively easy to find numbers X such that ε is negligible comparable to X; i.e. X+ε-X gives 0. Nash's suggestion ensures this doesn't happen. He gives deeper reasons too, but I won't delve into those for the time being.

thornahawk

[Weregoose]

[font="courier new"]abs(sin‾¹(sin(θ°

[elfprince13]

to convert degrees and radians, just set it in the mode you want the answer in and then use the units from the angle menu

[threefingeredguy]

[quote name='"thornahawk"']fnInt(ln(X),X,0,1) ? -.999998347 (should have been -1, but I'd say pretty close  )

Of course, singularities being a bane for most integrators, fnInt( will be a bit slower than usual.[/quote]
I was doing a math competition test and the question was something like find the sum of ln(2005)/ln(2005-x) from 1 to 2005. I didn't know how to integrate ln at the time (I do now ) and I didn't want to mess with Riemann sums, or any sums for that matter, so I decided to use fnInt. Bad idea. Not only did it lock up (my fault since I started the sum at 0 instead of 1, giving it an impossible value to compute) wasting time before I realized what I was doing wrong, it was .5 off. I got the answer wrong. Grrrr. Isn't it just adding up the values from each ?x? So inaccurate.

[IAmACalculator]

Hmm. Couldn't you have just used sum(seq(ln(2005)/ln(2005-X),X,1,2005?

Edit: Error:Memory

[alexrudd]

Heh, I tried using a For( loop on a similar test, and ran out of time.

[thornahawk]

It has apparently been more than a year since I last posted in this topic, so here's something particularly nifty:

People may be familiar with using rref( to solve systems of linear equations; in particular, if you have an N×N matrix [A] and an N×1 matrix (vector) [C], the last column (i.e., the (N+1)th column) of rref(augment([A],[C])) is the solution x to the equation [A]*x==[C].

Sometimes, one might want to solve complex systems of linear equations, where each element of [A] and/or [C] may be complex numbers. In the TI-85, TI-86, TI-89, and similar calculators, complex numbers are valid in matrices. This is not the case for the TI-83 and ilk, so one has to resort to mathematical trickery.

The easiest case is when only [C] is complex; i.e., [C] can be represented as [F]+i*[G], where [F] and [G] are the real and imaginary parts, respectively, of the matrix [C]. In this case, you use rref( in the following manner:

rref(augment([A],augment([F],[G])))

The last two columns (i.e., the (N+1)th and (N+2)th columns) give the real and imaginary parts of the solution x.

On the other hand, if [A] is complex as well, i.e. [A] is actually something like [A]+i*[B], and you need to solve the linear system

([A]+i*[B])*(x+i*y)==[F]+i*[G]

the solution becomes obvious when one expands out the matrix products and separates the real and imaginary parts:

[A]*x−[B]*y==[F];
[B]*x+[A]*y==[G]

Thus, one uses rref( like so:

rref(augment(augment(augment([A],-[B]),[F])^T,augment(augment([B],[A]),[G])^T)^T)

and after extracting the last column, the first N rows give the real part x, while the last N rows give the imaginary part y of the solution.

thornahawk

[Igrek]

Now that you revive this topic:
ln(2005)/ln(2005-x) for x equal to 2005 doesn't exist, does it?

EDIT: Neither it does for x=2004.

[simplethinker]

It doesn't exist if X=2005 or 2004. Logarithms are undefined at 0, but do exist (as complex numbers) for numbers less than 0. The function doesn't exist at X=2004 because ln(2005-2004)=ln(1)=0, so you have ln(2005)/0.