I was thinking about parser hooks and such. and working on some base converters (base 10 to base 2 and 3), anyways I was going to use a factorial (the 15!) except higher, and it gave me an overflow error. I am going to try to make a basic program that does then attempt to change it to assembly I need to know how to do this with calculating each digit, as I will not be able to with the full numbers. For the parser hook, it would check if there is a factorial, if so it caclulates it, it will be like cabamap from detached solutions (I think). sorry if that didn't make sense, I will answer any questions you have

First things first, can you please post the code so that we can try and see what is causing the error?

Sorry, its not a program error. I have not made this program yet. But the overflow error occurs when you do something like
Code:
you can find the "!" under math -> -> -> 4 or 5.

The maximum the TI-83+ series can handle is 1*10^100-1. Check out the table of factorials:

1! = 1
2! = 2
3! = 6
4! = 24
...etc...
67! = 36471110918188685288249859096605464427167635314049524593701628500267962436943872000000000000000
68! = 2480035542436830599600990418569171581047399201355367672371710738018221445712183296000000000000000
69! = 171122452428141311372468338881272839092270544893520369393648040923257279754140647424000000000000000

That last one, 69!, is 1.711*10^98, and the next one up, or 70!, is over 10^100. Therefore, in theory the TI-83+ can calculate up to 69! (which it does! and gets 1.711224524*10^9, but overflows on 70! With the number of factorials it can calculate, I can only assume some clever TI programmer just added a table of the 70 values it can represent (since, of course, 0! = 1).

The real question is why do you need/want 70! or higher?

mainly the reason is because I have seen it done before, plus I hate the stupid answers it gives like "1.2334352E19" I would rather see it written out completly and not rounded off. Thats about it though. the factorial things were just an example. Right now in my math class we are doing exponents and one of them was 7^15, when I plugged that into my calc I had to use another program to see it written out, but still rounded

does that make sense?

Well, the TI uses a fixed-length floating-point representation, so the larger the number being represented, the less precision that can be shown. A number like 2954 can be shown +/-0, but something liek 2850924589024509234 can be shown only to +/-(log10(N)-10), for N>=10^10. A non-rounded result would only be possible with a computation system capable of arbitrary precision, which is significantly harder to program, since numeric variables have variable length.

I was orignally thinking of using a string, and doing only addition and subtraction at first (in ti-basic until I get it working) then later adding capabilities to do multiplacation (easy) and division (harder). I would be using probably 3 strings (1 for first number, 1 for second, and one for answer). Then I would display it on the homescreen all the way acros (maybe as it is computing it ) This actually seems doable, and I will post a video later of it in action. Any other questions or comments, and sorry if I repeated something above or didn't make sense

I actually have written my own arbitrary-precision calculator in MIPS assembly; addition and subtraction are of course trivial, multiplication is fairly easy with a Booth multiplier, and division can be implementated the inefficient way using a subtraction - increment loop.

It'd probably be a lot easier to modify Cabamap to do whatever your goal is (Decimals? I can't think of much else it doesn't do.) To increase precision of the TI parser you'd need to rewrite the entire parser to work with a new data type, I believe.