Ok, after going through and determining which list exists, etc. use a For( loop to add the names and location of the list names something like this:

11->dim(LT2
1->B:1->C
For(A,1,11
LT2(B)+ALT(A->LT2(B
B+1->B
Text(C,5,"File # ",A
C+6->C
End

Something along those lines. Do you understand the general principle?

I wasn't talking about anything related to what Dan was talking about. I was takling about an efficient way to concatenate all of the information for infinite strings into a single file.

Yeah, thanks tifreak.

Sorry Kerm, I didn't even respond to you. Thanks for the input.

Okay I have my compression and decompression routine, I'm still working on it and it's pretty similar to ones out there, if it's too similar to yours just tell me. 287 bytes, mostly because of long list names I'll probably change it, and it takes 4.9 seconds to run for compression. Decompression is 113 bytes and 2.2 seconds. If anyone sees an optimization it would be appreciated.

Decompression
1->G
{0->LB
dim(LFILE1)-1->F
For(C,1,F,2
LFILE1(C+1->E
For(B,G,LFILE1(C)+G-1
E->LB(B
End
B->G
End
DelVar LFILE1LB->LFILE1:DelVar LB

compression
1->C
dim(LFILE1->D
{0->LFILEA
For(A,1,D-1
C+1->dim(LFILEA
LFILE1(A->LFILEA(C+1
1+LFILEA(C->LFILEA(C
C+2(LFILE1(A)=/LFILE1(A+1->C
End
dim(LFILEA)-1->C
If LFILE1(D)=LFILE1(D-1
Then
1+->FILEA(C->LFILEA(C
Else
C+2->C
C+1->dim(LFILEA
1->LFILEA(C
LFILE1(D->LFILEA(C+1
End
If dim(LFILEA)<=dim(LFILE1
Then
DelVar LFILE1LFILEA->LFILE1:DelVar LFILEA
End

Next is figuring out where I'll put the functions, in the menus or just as a keypress. As well as figuring out editing without deleting what is there, putting it in the list and bumping everything after it up one.

You don't need to delete LFILE1 before storing to it. It's automatically overwritten.
Also, instead of "If dim(LFILEA)<=dim(LFILE1", you could say "If D>=dim(LFILEA" since dim(LFILE1) is in D.

I just glanced through it, but it seems to be a repeating number style (RLE?) of compression. This gives extremely poor results, especially for a text editor (seriously now, how often do you type the same letter in a row?)

Most of the list "compression" routines on ticalc suck. I suggest you take a look at mine ( http://www.ticalc.org/archives/files/fileinfo/371/37195.html ), as it is garaunteed to compress (if the list is compressable). I could probably rewrite it to make it more effective and faster, but I'm lazy

Heh, welcome to the club. I definitely agree with Kllrnohj that you have a very inefficient compression algorithm there. You should probably try bytepacking; there are several posts on how to do that on this forum.

I appreciate all the help.

I took calc84maniac's stuff and optimized it some more. Down to 271.

It is an RLE, which gives pretty good results for other things. Not sure how well it will work, not well according to you, but I will have quite a few 0's in a row so we'll see how well it does. It will probably be inefficient though I would like to see how well it does.

I'll take a look at yours, Kllrnohj, and see how it does. I'll also check out bytepacking, by this forum you mean the BASIC forum right? See what that gets me.

One of the topics was this one ():
http://www.cemetech.net/forum/viewtopic.php?t=301

Basically if you want to store 33, 25, 46, and 28, you store this in a list element:

33254628

The trick is figuring out how to pack as many pieces of data into the list element as possible by finding all the possible values and designing out extraneous possibilities from the format.

Okay I may try to decipher that...

Not sure what the very last part meant but I think I get it. I'll make another attempt. I am going to look on United TI too, see if there's anything there.

Kerm, byte packing is how my list compress works (hence why I was asking that question )

RLE almost always gives horrible results. You have to have a list that has tons of repetitions (and each repetition must be at least 3 long). I have never seen it give good results, and it doesn't help that any non-repeating sequence ends up taking up 2x the space....

RLE wouldn't give poor results for snake games

I'll look into both. UTI didn't have anything except for RLE and pic compression (which I've already done and is better than most I've seen) so that wasn't any help.

I g2g, I'll work on this tonight. I'll give credit where credit is due if I decide to use anyone's.

Sure it would. RLE is only ever decent if you have the exact same thing a many, many times....A snake game would need to keep track of where the player has moved, which certainly isn't the same thing over and over. And thats avoiding the question of why you'd use compression in the middle of a game anyway

RLE == Worst list "compression", ever. (more like list bloater ....)

Not if you used two lists, often when the player is moving in one direction it will be repeating. Though there is no reason to, it's the only thing I could think of that would give decent results. I made a new one, uses bytepacking, does quite well. Only time it wouldn't make it at least 1/3 smaller would be if there were only two elements. I'll post it when I'm done optimizing, currently a combined 331 bytes and is just as fast. Next step if to figure out how to get it to do it for all the file lists that are there.

[Edit] Problem with decompression routine, won't be out as soon as I expected.

The list compression has been put off indefinitely because of a baffling problem. I'm going to continue on the rest along with two other projects and come back.

I have a Matrix and List compressor that can do a pretty good job of compression. I'll post it up later 'cause I have one more feature I need to find as many one-byte toens as I can find that can put put into a string, and add something that could let other people add their own compression/decompression methods/programs to it.

I think mine's working now, gonna run a few more tests.

Excellent. Would you care to post code at some point so we can see what you've got?

why dont you just use my text to list code

I am, well I'm using my own but you know, I'm just creating a routine to compress them while they aren't being used.

Okay here it is,

Compression, 189 bytes
2->dim(LB:1->C:Ans->D:2->F:(10>LFILE1(1->LB(2:LFILE1(C->LB(1
For(B,1,dim(LFILE1)-1
C+1->C
100LB(D)+LFILE1(C->LB(D
If not(fPart(C/6
Then
D+2->D:F+2->F
2+dim(LB->dim(LB
(10>LFILE1(C->LB(F
LFILE1(C->LB(D
End
End
LB->LFILE1:DelVar LB

Decompression, 202 bytes
DelVar DDelVar C–1->B
For(A,1,dim(LFILE1)-1,2
B+2->B
Repeat not(iPart(Ans
D+2->D
LFILE1(B)/10^D
End
D-2->D
If LFILE1(B+1
D-1->D
D/2+(A=dim(LFILE1)-1->F
For(E,1,F
C+1->C
iPart(LFILE1(B)/10^D->LB(C
LFILE1(B)-(Ans*10^D->LFILE1(B
D-2->D
End
End
LB->LFILE1:DelVar LB

It's 9 bytes more but much better and slightly faster. It's not completly optimized but it's a working version. I won't be back until Monday so nothing new until then.