Omnimaga
Calculator Community => TI Calculators => TI-BASIC => Topic started by: Raylin on November 27, 2009, 07:17:41 pm
-
SO.
I have a list of exactly 384 elements.
Said list is ~3900 bytes.
Compressed into complex numbers is ~1950 bytes.
Is there any easily implementable way to make that smaller?
To get said 384 element list:
99binomcdf(127,0->L1
augment(L1,L1
augment(Ans,L1->L1
0
-
or
:99binomcdf(127,0
:augment(Ans,augment(Ans,Ans->L1
:0
Edit: Right number of augments now.
-
Oooh.
You can double augment?
Cool.
BTW, too many augments.
-
can someone explainthis in detail; so i can use id XD
it seems to be very use full and how do you go about compressing it??
-
It's just getting a list of 99s that is 384 elements long.
:99binomcdf(127,0
99 times a list of 1s 127+1 (128) long.
:augment(Ans,augment(Ans,Ans
Takes the list and appends itself on it's end twice. It is now 384 elements long.
-
I was playing around with some of the other variables.
A matrix (32*3) is exactly 875 bytes.
Now, is there a way to store complex numbers to said matrix?
-
I was playing around with some of the other variables.
A matrix (32*3) is exactly 875 bytes.
Now, is there a way to store complex numbers to said matrix?
I don't think it is possible. Also multiply an entire matrix by a number doesn't work too. This gives an error.
-
Found a pretty good compression trick.
(Remember, I'm trying to do this all in TI-BASIC. Don't want all my games to require external APPS.)
If you store your list as a string to one of the sequence variables, u, v, w, you can half the size of the entire thing.
Then, if you need to evaluate it, run 'u' and Ans(X where X is the list element.
The only issue with this is the lack of editability if that's a word.
-
I was playing around with some of the other variables.
A matrix (32*3) is exactly 875 bytes.
Now, is there a way to store complex numbers to said matrix?
I don't think it is possible. Also multiply an entire matrix by a number doesn't work too. This gives an error.
I remember multiplying by a number worked. I don't think adding by a number did though.
-
I have a list of exactly 384 elements.
Said list is ~3900 bytes.
Compressed into complex numbers is ~1950 bytes.
What kind of elements are you saving (integers, decimals)? The most efficient type of compression to use will rely on that.
In general, to get the most out of list compression it helps to understand how the calculator stores certain things:
1) Real numbers are always exactly 9† bytes, and store exactly 14† digits.
2) Complex numbers are nothing but two real numbers put together; they're 18† bytes and can store two 14-digit numbers.
3) Lists are just a bunch of real/complex numbers stored sequentially. A four-element real list will be 4*9=36† bytes; a two-element complex list (basically four numbers) will be 2*18=36† bytes.
3b) There is no such thing as a list with real and complex elements; if a list has one complex element, then every other element is treated as such and takes up 18 bytes, even if they have no imaginary part.
4) Matrices are basically lists. An NxM matrix is just an N*M element list of real numbers, so a 4x5 matrix is 4*5*9=180† bytes.
4b) The OS doesn't support complex values in matrices, only real numbers. The reason for this is probably that matrices can quickly grow to over 10KB without the user realizing it, so doubling the size to allow for complex numbers would kind of suck.
Considering (3) and (3b), how did you use complex numbers to halve the size of the list? By adding complex list elements, you'll halve the number of elements, but the remaining ones will double in size.
†This is for the data itself. For an actual variable (e.g. L1 or A), there are a few extra bytes containing the variable name and some other stuff.
To get said 384 element list:
99binomcdf(127,0->L1
augment(L1,L1
augment(Ans,L1->L1
0
If you want a 384 element list of all 99's, you could just use (assuming you want L1):
:384→dim(L1
:Fill(99,L1This also has the nice effect of not storing the result in Ans, so you don't need double the spare RAM :)(however, storing the dimensions of the list does modify Ans).
Matrices can be multiplied by a (real) number, but you can't add number to one.
-
To add a number to a matrix, you need to create another matrix of the same size, fill it with the number you want to add/subtract, and then you can add/subtract those matrixes. I use this in Shift, ans so i had a dedicated addition matrix :)
-
I remember multiplying by a number worked. I don't think adding by a number did though.
Oh, you are right.
To add a number to a matrix, you need to create another matrix of the same size, fill it with the number you want to add/subtract, and then you can add/subtract those matrixes. I use this in Shift, ans so i had a dedicated addition matrix :)
TI-BASIC turns quite fun with all these works around. Still a nice technique.
I haven't found in real games any usefulness of row+( and row*( commands... It would be curious to see one.
-
Dedicated... addition... matrix...
FFFFFFFFFFF... IDEA.
EDIT: Okay. What if the HP for each army unit was stored in a 8*4 matrix?
Then, the ATK minus DEF of each corresponding unit was stored to another 8*4 matrix?
So, now you have 4 matrices.
If it's the enemy's turn, subtract matrix (A).
If it's your turn, subtract matrix (B).
Bulky, but implementable?
-
If you store your list as a string to one of the sequence variables, u, v, w, you can half the size of the entire thing.
Then, if you need to evaluate it, run 'u' and Ans(X where X is the list element.
The only issue with this is the lack of editability if that's a word.
That's neat.
I don't use complex numbers for compression because I don't see anyway to make things smaller with them. :)
-
This is true, unfortunately.
In my other game, Shin Megami Tensei, I made a list considerably smaller with complex numbers.
Guess I'm just using what used to work.
-
If you store your list as a string to one of the sequence variables, u, v, w, you can half the size of the entire thing.
Then, if you need to evaluate it, run 'u' and Ans(X where X is the list element.
The only issue with this is the lack of editability if that's a word.
That's neat.
I don't use complex numbers for compression because I don't see anyway to make things smaller with them. :)
Use also the fraccional part of imaginary part?
You can save 4 integer numbers in every element.
Other thing to compress is if you use number smaller than 1000 you can save like this:
E3A+B
To decompress:
int(L1(1)/E3)->A
L1(1)-E3A->B
where the E is the small E. A and B to numbers to save and are smaller than 1000.
This could allow easily 8 numbers in one element...
-
Complex/real hardly makes any difference, you only save a VAT entry and you sacrifice speed.
-
Use also the fraccional part of imaginary part?
You can save 4 integer numbers in every element.
Other thing to compress is if you use number smaller than 1000 you can save like this:
E3A+B
To decompress:
int(L1(1)/E3)->A
L1(1)-E3A->B
where the E is the small E. A and B to numbers to save and are smaller than 1000.
This could allow easily 8 numbers in one element...
The only exceptions I would see with this is the values for HP, Max HP, SP, and Max SP.
Any way to get around that?
-
Other thing to compress is if you use number smaller than 1000 you can save like this:
E3A+B
To decompress:
int(L1(1)/E3)->A
L1(1)-E3A->B
where the E is the small E. A and B to numbers to save and are smaller than 1000.
This could allow easily 8 numbers in one element...
This is the method I use most often. Again, I use it with real numbers.
Complex/real hardly makes any difference, you only save a VAT entry and you sacrifice speed.
Mapar, I agree with you. It just sacrifices speed.
-
However, what about the exceptions?
Like 9999 HP?
I mean, you can only put 14 digits in a displayed line.
-
You could do:
1111222333444
(13 digits)
Just make sure you compress and decompress right. For fpart, I try to only use 13 digits because of floating point errors.
-
Hmm.
Intriguing.
I will definitely use that method in the game.