As an extension to a previous entry on doing LU decomposition in Nspire and R, the TI-84 is covered here. There is no built-in function like in the Nspire for this, but there are many programs available online, with most of them employing a simple Doolittle algorithm without pivoting.
The non-pivoting program described here for the TI-84 series is with a twist. No separate L and U matrix variables are used and the calculations are done in place with the original input matrix A. The end result of both L and U are also stored in this input matrix. This is made possible by the property of the L and U matrices in this decomposition are triangular. Therefore, at the little price of some mental interpretation of the program output, this program will take up less memory and run a little faster than most simple LU decomposition programs online for the same class of calculator. From a simple benchmark with a 5 x 5 matrix, this program took 2 seconds while another standard program took 2.7 seconds.
The input matrix A.
Results are stored in the same matrix.
L, U, and verification.
As shown in a previous installment on running the Nelder-Mead optimization of the Rosenbrock function in TI-84, its hardware is not up to the challenge for problems of this kind. It is however an interesting case to learn from this program that took a considerable amount of time (in minutes), when most TI-84 programs complete in seconds, to grasp the technique in writing optimized code.
The problem used in the setting is the Rosenbrock function:
Two techniques were used to try to optimize the code. The first one is to in-line the function (in this case the Rosenbrock function). In the original version this function is stored in a string value to be evaluated whenever necessary by using the TI-84 expr() function. The idea from common in-lining is borrowed to see if it works in TI-84. As shown in line 44 below, the Rosenbrock function replaced the original expr() function call.
Another technique is to remove unnecessary comments. For most modern languages this is never considered a problem but for simple calculators it is speculated valuable processing time may be spent on processing comments that contribute nothing to the algorithm.
Both programs returned the same results. To compare the gain in speed, the same set of initial parameters and tolerance were used in both the original and code-optimized program. Surprisingly, the inline method does not yield any gain while removing all those “:” that were used for indentation does improve the speed. The average of the original program is 183 seconds while the program with cleaned code is only 174 seconds, which is around 95% of the run time of the original program.