I don't have one of these calcs, so I'm not familiar with the pixel commands.

TI floats can hold 14 base-10 digits of accuracy, which is 10^{14}. In this much space, we can hold 11 base-16 digits of accuracy. So you will need 3960 floats. This can fit into two 990-element complex lists. You can store a group of 22 pixels into a complex number like (returned in Ans):

` ``0 For(A,0,20,2 Ans16 Ans+Pxl-Test(Y,X+A)+iPxl-Test(Y,X+A+1 End`

To recall from a complex number in Ans:

` ``For(A,20,0,-2 16 ֿ¹int(Ans Pxl-On(Y,X+A,16fpart(real(Ans Pxl-On(Y,X+A+1,16fpart(imag(Ans End`

Conveniently, 264 and 165 are divisible by 11, so you could work this algo in either direction!

]]>I'm not too sure the difference in size between a large matrix with small elements and a small matrix with large elements is significant at all to be a viable option.

]]>If you were to use lists, you would need 43 different lists, so thats not an effective solution.

Using matricies could possibly work, if you archived them after creating them

Perhaps you could also use strings. Take the color and store it as a hex value from 0 to F. There are 15 colors, and off which is perfect for hexadecimal. Then, since you have 10 strings, store the first 4356 color values into Str1, and archive it. The next 4356, Str2; etc. This would only work if you had enough free memory for a string that was 4536 characters long however. Since the only limit in the length of a string is the amount of free memory. Since you would know the exact order the points were saved in, to recall them, you would just need to reverse the algorithm. Or to recall a specific one. Figure out which string it would be in, unarchive it, calculate which position you need, extract the value, rearchive the string, and convert the value from hexadecimal to decimal

]]>