Arc'd list elements

[Iambian]

This is more of a posting to attach a download file for someone I meant to give to a day or two ago than it is announcing a new feature, but while I'm at it, I might as well pose the question.

The small routine, only about a hundred bytes, is designed to extract list elements out of an archived list. Since it's so small, I could insert this routine into Celtic III with no real net impact to memory. In fact, it might be beneficial in the event I have to work around further with lists and such.

Keep in mind that the program in the download will be expanded upon in Celtic III if I choose to add it in. At least in Celtic III, there will be *real* error checking, and the ability to read in other stuff. And perhaps an upgrade to allow status reading and stuffs from lists. Oh, the options are *so* there. You'll still need to read the ReadME file, though.

So, what do you think?

[luby]

I can see a good use for this in rpg games where there are numerous big lists. Having it archived would save lots of space.

[tifreak8x]

bwhahaha, thank ya much! Now I can keep that event list archived for pokemonz...

[vuurrobin]

sounds like a usefull routine for celtic 3

[Iambian]

I was also wondering about something regarding lists. I do not recall a way to extract a "formula" (y-equ string) out of a list in a way that a person would be able to use lists to store strings.

Would a Celtic III util be useful for this, or should I wait for someone to figure out how to do this in pure BASIC before I make a move?

Or if the method is known, I'd love to be enlightened on this, since all I've ever heard of is "it's impossible". If it is, then it goes to show how out of the loop I am wrt the BASIC scene.

[DarkerLine]

I've never seen a way to do it, at least not for an arbitrary string 'formula'. If you know something about the formula, you can find out what it is by evaluating it carefully, I suppose, but that's all you can do barring some exploit in the OS that hasn't been found yet.

[angel14995]

Do you mean like in a list the value of the 1st element is 7 and that changes and the value of the second element is a formula that relies on the first Element? Like this? L1={7,7L1(7)} and you are trying to extract the 7L1(7)?

[DarkerLine]

You can store a formula to a list, for example: "{1,X,X^2→L1 (the quotation mark distinguishes this from storing a list normally). This way, the formula is evaluated every time you access the list, so that if X changes, the value of L1 changes as well.

The reason this is interesting is that you can store any string to the list - "HELLO→L1 doesn't cause an error and saves the string "HELLO". Unfortunately, you can't extract the formula using Basic, so this would ordinarily be useless.

[vuurrobin]

you can put a string in a list.

"HELLO->L1

but you can't get it out of the list. this also gives an error when you try to use L1


I'm not sure if this will be that usefull. we can already use strings, hacked strings, equation variables, (protected) programs and appvars. AFAIK, storing a string in a list makes that list useless most times, so I don't see any advantages in it.

[edit] beaten

[simplethinker]

I think it would be useful. Lists are useful because they can have user-defined names, so if you can store and extract a formula/string to a list then you can have user-defined strings too. I don't think that the hacked strings can do that, so it would be a nice advantage.

[Iambian]

I'm unsure as to how useful the feature will be. It'll only be about another hundred or so bytes to implement it, including a change to the central file lookup routine, but I'm getting a load of "no" responses. Perhaps I should've made a poll regarding this?
---
Hmm. I just had an idea with regards to this. I'm just posting it here so I don't forget about it, but I can pass a variable name through Op1 when my parser hook's finished, so I wonder if I could perform a lookup on the list and then paste the variable name of the y-equ var you'll never be able to look up in the system equation list into Op1 to be used as output. Maybe that would work, but I can imagine this would have a very slight possibility of crashing the system, since I'm making it do something it wasn't originally intended to do. Then again, it *is* a variable just like anything else. Who knows without trying?

[Iambian]

*bump*

One last question about the archived list element thingie. Should I start the list element count at 1 or 0? That is, if you're using the det( function to access archived list elements... (btw, "24" is the function number I've assigned to this)
If it starts at 1, then det(24,"L1",1) will retrieve the first element from that list.
If it starts at 0, then det(24,"L1",1) will retrieve the second element from the list because det(24,"L1",0) would've retrieved the first element.

With the way the function would work, you could do something like this:

[DarkerLine]

considering every built-in list command starts at 1, I think it would be best to keep that.

[vuurrobin]

I would go with 1, since the ti-os also go's with L1(1) for the first element. would be the least confusing .

edit: multipost with darkerline

[Igrek]

[Iambian]

I'd like to say something about "necroposting", but I've seen worse. Anyway...
The thing you quoted was made in the context of it being done from BASIC. Of course I had a way of doing it from ASM, but I never really implemented it. If you looked closely at the source near the input handling, you'd see a way I'd deal with list input, be it user-defined or system-defined.

If you haven't noticed, the equation part of the list isn't too tightly attached to the list. That is, the equation part is deleted if just about anything other than reading it occurs with the list.

Though one can make a routine that'll perform the function, I've fully realized that it would serve no real purpose. Sorry for the letdown, but creating such a program would be good for experience. And for someone that might, for some strange reason, "obfuscate" their program by using this little known function of the OS.
----
On a previous topic, I've selected the "start at 1" idea and found that I could use an input of zero to obtain the dimensions of that list, since you cannot use dim() on an archived... anything.

[Igrek]

[JoeYoung]

I hate to necropost, but will you ever have the ability to write to archived lists? or is it already included and i need to read the readme more?

[Iambian]

Just to put it out and I'm unsure if I've said anything of this sort, but you *cannot* edit *anything* archived. You can unarchive it, edit it, then archive it again, but never any direct editing.

Now... I know BrandonW will be a naysayer on this one but understand that to include routines to actually perform the edit wouldn't only take up a load of space in having to recreate routines to handle an entire portion of the TI-OS's file system, but doing such would wear down on the FlashROM and such edits like what you're talking about, wouldn't be easily or reliably done. It is better to unarchive, edit, then rearchive the list if you really want it to stay out of RAM.

The purpose of archiving is to keep things that will not change. If you don't have enough RAM to deal with it, why don't you stick stuff that won't change into archive so you'll have more space?

-----
EDIT: *grumbles about topic outdatedness*

[FloppusMaximus]

To elaborate a little bit, there are actually two technical obstacles here:

- You cannot write a one into the Flash; you can only write zeroes. If you're very lucky (say, you're trying to overwrite a floating-point 1 with a 0, or a 10 with a 1) then you can in theory make that modification in-place. Otherwise, the only way to "change" the archived list is to move it to a different place in Flash -- in essence, to unarchive and re-archive it. The space consumed this way gets reclaimed only when you garbage-collect (so if your program is constantly changing stuff in Flash, you can expect to have to garbage-collect frequently.) Garbage-collecting, incidentally, is what wears down the Flash chip (though it's not something to be worried about most of the time.)

- The calculator OS has been specifically designed to make it impossible for any user program to write directly into Flash. There are ways to break this protection (BrandonW, in particular, has done a lot of work on this), but doing so is rather complicated, and there's no guarantee that it will continue to work with future versions of the OS. In the absence of such an exploit, the only ways for user programs to read and write Flash are by archiving, unarchiving, and deleting variables.