I was having an issue with list transfer. Suppose I've got a list of 1-$n$ elements in some particular order, without repetition, and then suppose I've got a friend that I'd like to send this list to. The problem is that neither one of us is able to transfer this list via cable link to the other, and we don't want to have to write out the entire list (assume $n$ is large enough that it wouldn't be feasible to do so efficiently). How can I compact this list into some smaller representation of itself? I've looked at some compression algorithms, and most of them only seem to deal with data that has repetitive elements. I'm also doing this for cryptographic purposes, so I'm trying to stay away from pseudo-random number generation, since many of them are fairly insecure in the TI-83 family. Any ideas would be greatly appreciated.

Will the list elements have arbitrarily many digits? Also, I don't know why transferring a list would have problems. I cannot think of a solution to your problem, but have you tried storing the list as a string or in a program and sending it? You can do Rcl L1 for example ([2nd][Sto>]) in a program to recall the contents of the list. Then you just run the program and the list will be in Ans. Or if you store it as a string, expr( will return the list in Ans.

47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2

The numbers 0-256, to be precise, in some particular order. I myself have no problem transferring data between calculators, but the goal is to devise a method to facilitate a transfer for those who don't, such as by pencil and paper. Sorry if I neglected that bit.

Well, in that case, ln(10^14)/ln(256)~=5.8

You'll be able to store at least 5 elements in one. Let me think:

With the list in L₁ and the compressed in L₃:

```
:.2dim(L₁
:If fPart(Ans
:1+Ans
:5int(Ans→dim(L₁
:For(A,1,.2Ans
:sum(seq(L₁(B+1)256^B,B,0,4→L₁(A
:End
:A→dim(L₁
```

This isn't very optimized, but you get the point. Also, it'd be a little easier if the numbers were 0-255, then I could've optimized some more. I also need to test this. You could probably think of the decompression code, but I'll post it anyways when I'm done with homework.

EDIT: Optimized. Couldn't get the 2^8 optimization to work, though.

I'm incredibly sorry. The numbers *are* 0-255. There are 256 elements.

EDIT: Thank you for all your help on the issue. I've tested it and it works really well. The only problem is that the data loses its precision. On this line:

`:sum(seq(L₁(B+1)256^B,B,0,4→L₁(A`

Couldn't the code go without the elements being multiplied by 256^1,2,3, or 4? I feel like that's where the compression starts to get lossy.

```
Ln(1 -> rand
For(Z,2,dim(Ln
Ln(Z)rand
end
```

That'll just give you one number that's the product of rand and the product before itself. The other calc just needs the final answer and a program to reverse it.

I know you said you'd like stay away from rng, but that's the only easy thing I can do off the bat. I'll try to find the thread wherein someone said what the formula for rand is.

fPart(1-min(ΔList(fPart(Ans{40014²,40692}/(2^31-{85,249 is the rand formula.

I forgot that, since it uses fpart and min, it's pretty difficult to just undo it with a calculator since it's truncating part of answer. I can't think of any good methods of compressing down a list and still retaining its values. I could think of a few ways to run it through a sequence of commands to get it down to one single number, but the time required to undo this reliably would take a while. So you're probably better off just copying it by hand :/

Actually, I've been looking for the rand algorithm for a while, but never found it. Is this the same one that the TI-84 uses?Even if it's not, thank you very much, anyway.

So basically to find the seed, you'd just have to reverse it somehow, right?

I checked. Its graph is linear, where TI's is much more unpredictable.

Perform int(Ans

before doing it. rand takes the int of the seed. (Or the iPart, not sure.) It is the correct formula.

I've been using 1 as a test seed for both, and there appears to be something wrong then. On the built-in function, I get 0.7455607728 as the first value, but I get 0.0087714497 from the above algorithm. I typed in everything, and also included the int( function just to double check. If I'm not mistaken, Ans is being used as the seed variable, correct?

That's funny. Take a look at this:

I just copy pasted that into SourceCoder, fixed some syntax errors that sourcecoder can't handle, and ran it. I just showed it with seeds 1 and 2. This is with an OS 2.55 MP ROM. What OS do you have?

OS 2.55 MP ROM, too.

I deleted everything and retyped the algorithm and everything is fine now. Must've been a typo.

0 and 196164532 don't have the same outputs as the rand command, though, yet all other numbers (to my knowledge) are working the same way. Just thought that was worth sharing.

If all elements of your list are x<100, you can store numbers like that and extract them with a modulus command and taking the int of a divide divide. Actually, you can use a mod base 1 greater than your highest number. I don't know what the calculator's precision limit is, but someone else might. You will be able to fit (that number / your base) elements into 1 element.

Precision limits for the TI-calc is generally not too big a deal, as it's almost certainly small enough that rounding your answer will work fine. I am aware that square roots can sometimes not return the true square root of a number due to rounding error. A simple round(n,0) fixes that problem.

Either that, or find the number within an epsilon.

The calculators store the first 14 digits of the number, internally, whether the digits are before or after the decimal place (removing leading zeroes). There is another byte called the mantissa that tells where the decimal point is. So for example, the following numbers are stored the same way, excluding the mantissa:

1.3741783044519

137417.83044519

.000000000000000013741783044519

47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2

I'm afraid I don't entirely understand the method, although I'm very interested in it. I'll only be using 256 elements, numbered 0-255, in some pre-established order.

Oh, so is this for an encryption of some sort? Where each number 0 to 255 is in the list in some order? Well, there are 256! possible ordering which is a 507 digit number. On the calculators, this could be compressed to a 37-element list, then, but I am sure there is a much better way XD

Hmm, well, you can fit 46 bits in a 14-digit number and each value that you have is an 8-bit number. You can store five elements in each list element, then, bringing the list size down to 52 elements. Basically:

```
For(A,0,51
0
For(B,5A+1,min(256,5A+5
256Ans+L1(B
End
Ans→L2(A+1
End
```

The new list is in L2. It isn't elegant, but it is a direct way of compressing the data. Then to decompress it:

```
0→dim(L1
For(A,1,51
L2(A
For(B,1,5-4(A=51
Ans/256→L1(1+dim(L1
iPart(Ans
End
End
256fPart(L1→L1
```

(Hopefully I did that right)

47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2

It works really well now. At first I'd lose precision in L_{2} and the algorithm couldn't be reversed, so I tweaked it so that 4 elements were compressed into one, rather than 5. I receive a list of 64 elements now, instead of 52, but that's fine with me.

Thanks!

I was also wondering if that style of compression had a name, and if there's anywhere I could learn more about data compression.

Okay, I am glad you figured out how to tweak it. I am not sure if this style of compression has a name, though. Basically, TI uses 9 bytes for every number, no matter how big or small it is. The way TI stores it each base 10 digit uses one nibble (half a byte) and the first two bytes give some information about the number. All I did was pack in a a few more numbers to make it less wasteful.

47%? Take a look and try to imagine how cool 100% will be. This has won zContest 2011 and made news on TICalc. This compromise between Assembly and BASIC parses like BASIC and is fast like assembly. Grammer 2