This is a question someone asked me at work, but it also applies to OpenBOR, so I'm posting here for anyone curious.
In OpenBOR, all numbers are 32bit. This means the maximum range for a number is
An application can natively use numbers up to its own design or that of the hardware, whichever is lower. There's simply no way for the machine to natively go beyond that. However, nothing stops you from working much larger numbers in software. Think of it like doing math on your fingers. You only have 10 physical digits to count with, but you can write notes down or do a carry in your mind to work with larger numbers. Computers can do the same thing.
To illustrate an example, lets look at the humble Nintendo Entertainment System. The NES is an an 8 bit computer, so all variables are comprised of eight 0 or 1 gates you can encode your value with, giving you 256 combinations. In the case of numbers, that means
This is done by breaking the number down and storing its individual digits in an array, then printing the digits one at a time back to the user when they're ready. In the example below, we use an array to store the individual digits that make up 9,100,152.
Logically, one NES array has a maximum of 256 elements. That means our table above could potentially handle a number 256 digits long! I probably couldn't pronounce that. The only catch is you're using more memory and CPU time, since obviously this can't be done in one cycle. Again, same idea as your hands. It takes longer to do math over 10 because you need to memorize a carry or write it down and then use your hands for the next half.
More importantly, it's up to you the coder to figure out all the logic. You have to work the carry math that places each digit in the proper index, and any sort of sum, multiplication, subtraction, etc. is on you as well. Also, the method I just described relies on human readable base 10 values. The real thing would use base 2 encoding and probably swap indexes around to fully optimize CPU time and memory. There's a reason old school coders were another breed.
The only difference in OpenBOR (or any other application) is you happen to have more bits. In the case of OpenBOR, the technique above would give you a number with potentially over 4 billion digits. There are a lot of preexisting libraries to pull this off, but nothing I know that translates directly to OpenBOR script. When I get a chance, I'll see if I can write a simple example library to show it in action.
DC
PS: One last bit of trivia. Some processors have the ability to perform the above task in hardware. The Genesis is a great example. Its Motorola 68000 is a 16 bit processor, but it can natively handle a 32 bit numeric. It does this by automatically breaking the numbers down into 16 bit chunks before passing them to its internal Arithmetic Logic Unit. It's not as good as a true 32 bit CPU of course, but is much faster than doing the same work in software.
In OpenBOR, all numbers are 32bit. This means the maximum range for a number is
-2,147,483,648 to 2,147,483,647 (signed), or 0 to 4,294,967,295 (unsigned). The question was is there any way to get larger numbers than that? The answer is no, but also yes.An application can natively use numbers up to its own design or that of the hardware, whichever is lower. There's simply no way for the machine to natively go beyond that. However, nothing stops you from working much larger numbers in software. Think of it like doing math on your fingers. You only have 10 physical digits to count with, but you can write notes down or do a carry in your mind to work with larger numbers. Computers can do the same thing.
To illustrate an example, lets look at the humble Nintendo Entertainment System. The NES is an an 8 bit computer, so all variables are comprised of eight 0 or 1 gates you can encode your value with, giving you 256 combinations. In the case of numbers, that means
-128 to 127 or 0 to 255. However, have you ever seen a NES game with a score that couldn't exceed 255? Of course you haven't, most go well into the millions.This is done by breaking the number down and storing its individual digits in an array, then printing the digits one at a time back to the user when they're ready. In the example below, we use an array to store the individual digits that make up 9,100,152.
| Array Index | Number digit |
| 0 | 9 |
| 1 | 1 |
| 2 | 0 |
| 3 | 0 |
| 4 | 1 |
| 5 | 5 |
| 6 | 2 |
Logically, one NES array has a maximum of 256 elements. That means our table above could potentially handle a number 256 digits long! I probably couldn't pronounce that. The only catch is you're using more memory and CPU time, since obviously this can't be done in one cycle. Again, same idea as your hands. It takes longer to do math over 10 because you need to memorize a carry or write it down and then use your hands for the next half.
More importantly, it's up to you the coder to figure out all the logic. You have to work the carry math that places each digit in the proper index, and any sort of sum, multiplication, subtraction, etc. is on you as well. Also, the method I just described relies on human readable base 10 values. The real thing would use base 2 encoding and probably swap indexes around to fully optimize CPU time and memory. There's a reason old school coders were another breed.
The only difference in OpenBOR (or any other application) is you happen to have more bits. In the case of OpenBOR, the technique above would give you a number with potentially over 4 billion digits. There are a lot of preexisting libraries to pull this off, but nothing I know that translates directly to OpenBOR script. When I get a chance, I'll see if I can write a simple example library to show it in action.
DC
PS: One last bit of trivia. Some processors have the ability to perform the above task in hardware. The Genesis is a great example. Its Motorola 68000 is a 16 bit processor, but it can natively handle a 32 bit numeric. It does this by automatically breaking the numbers down into 16 bit chunks before passing them to its internal Arithmetic Logic Unit. It's not as good as a true 32 bit CPU of course, but is much faster than doing the same work in software.
Last edited: