BigNumNum Cruncher

[sammyMaX]

BigNumNum Cruncher is a bignum program for the Nspire, written in C. It should be able to handle numbers as big as the Nspire's RAM allows it to be, with one digit per byte. (This may not mean output being up to (number of available bytes of RAM) digits long, since in the instance 2^1000000, it would need to store 2^999999 to get to 2^1000000) I have finished the addition and multiplication functions, and have the basic GUI going, but a lot of work has to be done (Powers in beta testing for now) I have no school on 9/29/11, so hopefully some major work can be done.

BigNumNum Cruncher originally started in Lua but since then, I have moved over to C, since Lua was far too slow for this program. Numbers are stored in my program as arrays of ints, with only 4 digits able to be used in each int because of overflow. (Perhaps there is a way to fully utilize the RAM and double capacity?)

Spoiler for Changelog:

Version 0.01 Lua with GUI done
Version 0.02 Lua with addition
Version 0.03 Lua with subtraction
Version 0.04 Lua with multiplication and powers
Version 0.05 Lua with bug fixes

Version 0.10 C with GUI and addition
Version 0.11 C with less bugs
Version 0.12 C with multiplication
Version 0.13 C with powers and results less than 37 digits
Version 0.14 C with major speed up in addition and subtraction algorithms
Version 0.15 C major release memory allocation bug fixed

[sammyMaX]

Update: I have decided to move over and start the program in C with Ndless 2.0. It will be much faster, and when Ndless 3.0 comes out, only a few minor changes will have to be made. Expect an alpha in three to four days.

[sammyMaX]

Here is the UI in C (so far not functional):
On a side note, I am having a lot of trouble implementing the GMP-style limbs and branches, (Ndless isn't letting me do divison or mods) so I will revert back to my old system of numbers.

[Spyro543]

Awesome looking! (Why would you even need to calculate numbers this big anyways? )

[t0xic_kitt3n]

Are you having trouble with 64-bit (or possibly 32-bit) integer division? Is there a compiler error when you do so?

[sammyMaX]

Spyro - Thanks! Most people won't need it, but it could be cool to show to your friends, and for those in math competitions (like Mathcounts) it could be a life saver.

Toxic kitten - yes, I am getting an error when doing mod (%) and division. I get compiler errors like "undefined reference to '__aeabi_idivmod'" or "undefined reference to '__aeabi_uidiv'". It would really help if you could explain this to me.

[t0xic_kitt3n]

You are getting errors from newlib then. Make sure you have the latest version of GCC.

[Lionel Debroux]

"undefined reference to '__aeabi_idivmod'" or "undefined reference to '__aeabi_uidiv'". It would really help if you could explain this to me.

Don't use the -nostdlib compiler option

[Spyro543]

Spyro - Thanks! Most people won't need it, but it could be cool to show to your friends

Most of my friends don't even know what a graphing calculator is.

[sammyMaX]

The -nostdlib option was the problem. (from me just modifying the makefile of the Hello sample and never catching on to that) Thanks guys!

Lol Spyro, in my school graphing calculators are required for 9th grade and above math. TI must make a lot of money off that...

[sammyMaX]

Some random tidbits about Lua vs. C (for Nspire programming)
1. C is much better for input, because it keys being pressed instead of the character a button corresponds to (which is sometimes a weird, non-standard character)
2. C is MUCH faster
3. Lua supports color and developing for it is much easier
4. For my program, where the input is a variable length, C is HORRIBLY hard to code. In Lua a string can be any length; getting C to create a string that can be a variable size (but stays the same length after declaration) requires malloc(), and when the string length changes each time you type... UGH!!!

[calc84maniac]

getting C to create a string that can be a variable size (but stays the same length after declaration) requires malloc(), and when the string length changes each time you type... UGH!!!

Try using realloc(), that will resize a buffer without modifying its contents (and may return a new pointer if the buffer couldn't be resized in-place). Of course, you may not want to reallocate for every character typed, so you could probably increase/decrease the size by, for example, 32 bytes at a time.

[sammyMaX]

True... I really don't know what I was thinking when I wrote that post because I had thought of realloc(), but for some reason it still seemed like a pain in the butt to write.

An update: I have 3-4 weeks to finish (at least get the most important power, factorial and multiplication functions done) before school starts. I plan on writing division and nth root approximation, but I haven't really learned that yet, so it may be far later in development when that gets implemented.

[t0xic_kitt3n]

I just make my string buffers long enough for whatever may occur. I never thought of using realloc

[sammyMaX]

Yeah, that works, but it isn't very elegant (seriously, using up like half a KB of RAM is not really a worry, it just doesn't seem pretty)