Subject: Variable question

From: Owen <[email-masked]>
Date: Mon, 7 Feb 2011 10:55:54 -0500

What would take more space?

S$="SKELETON1.200.150"

-or-

N=SKELETON
W=1
MHP=200
G=150

I'm trying to determine whether to use a string to carry some statistics (which would be SEGmented out of the string when needed) or whether to carry multiple variables through the program for each instance.  Basically, I'm looking at 9 possible strings (of about 20 characters each) or a total of 36 individual variables carried throughout the course of the program. Speed isn't absolutely crucial--- as it is a turn-based application.... So I'm not really all that concerned with how long it takes to move all the segments of "S$" into temporary variables for use...  Really, I'm just looking for space options... How can I do this without eating up all my memory with variables?  Anothe thought I had was to draw everything from records on diskette each time I needed the data... But that would mean a bunch of disk access and I am afraid that will add up quickly, as far as real-time delay goes.  I don't have my TI or the use of a laptop right now to test, so any help you could offer would be great. Thanks guys/gals.

Sent from my iPhone

---

From: "Tursi" <[email-masked]>
Date: Mon, 7 Feb 2011 09:50:39 -0800

Well, one way to look at it is to remember that a string takes the number of 
bytes in the string, plus one, to store, while a number takes 8 bytes. So in 
your example, the string takes 18 bytes, while the four numbers take 32 
bytes.

But you also have to take into account the increase in code size that 
converting the strings to usable numbers will take. Depending on how much 
extra code you need, and how much data you have, you could eat that size 
difference up and then some. It would be hard to estimate.

One thing that might help that at least, is to make the string use 
fixed-length fields. As you've laid it out there, you would need code that 
could count characters to work out how long each field is. If you made the 
numbers fixed length (choosing a reasonable maximum - I'm not sure your max 
values, but let's say 2 characters for W, and 4 each for MHP and G), then 
you can have shorter parse code, since you always know exactly where to SEG$ 
for the data you need. Moving the name, which is most likely to change in 
length, to the end, means you don't need to worry so much about its length 
(SEG lets you run off the end without an error in terms of length). So in 
that case, something like

S$="0102000150SKELETON"

would need 19 bytes. Note with fixed length fields you don't need 
separators - W is going to be SEG$(S$,1,2), MHP is SEG$(S$,3,4), and G is 
SEG$(S$,7,4) (converted again with VAL - the leading zeros ensure a correct 
number).

Of course, this is where you see the cost of conversion -- note each of 
those SEG$ calls has two numbers for a cost of 16 bytes each- that's 48 
bytes just for those (let alone the SEG$ and VAL calls). But if you used a 
subroutine to convert the string into the variables, you'd only need to 
specify those calls once, and so you'd make up the savings after 3 or 4 
strings. But if you did all the conversions inline when you needed them, 
every time you needed them, strings would probably cost more memory overall.

-----Original Message----- 
From: Owen
Sent: Monday, February 07, 2011 7:55 AM
To: [email-masked]
Subject: [TI994A] Variable question

S$="SKELETON1.200.150"

-or-

N=SKELETON
W=1
MHP=200
G=150

I'm trying to determine whether to use a string to carry some statistics 
(which would be SEGmented out of the string when needed) or whether to carry 
multiple variables through the program for each instance.  Basically, I'm 
looking at 9 possible strings (of about 20 characters each) or a total of 36 
individual variables carried throughout the course of the program. Speed 
isn't absolutely crucial--- as it is a turn-based application.... So I'm not 
really all that concerned with how long it takes to move all the segments of 
"S$" into temporary variables for use...  Really, I'm just looking for space 
options... How can I do this without eating up all my memory with variables? 
Anothe thought I had was to draw everything from records on diskette each 
time I needed the data... But that would mean a bunch of disk access and I 
am afraid that will add up quickly, as far as real-time delay goes.  I don't 
have my TI or the use of a laptop right now to test, so any help you could 
offer would be great. Thanks guys/gals.

Sent from my iPhone

------------------------------------

Yahoo! Groups Links

---

From: mark wills <[email-masked]>
Date: Mon, 7 Feb 2011 21:45:18 +0000 (GMT)

<snip>
Of course, this is where you see the cost of conversion -- note each of 
those SEG$ calls has two numbers for a cost of 16 bytes each- that's 48 
bytes just for those (let alone the SEG$ and VAL calls).
</snip>

Could you use VAL?

a$=SEGS(S$,VAL("3"),VAL("4"))

?

Mark

----- Original Message ----
> From: Tursi <[email-masked]>
> Sent: Mon, 7 February, 2011 17:50:39
> Subject: Re: [TI994A] Variable question
>

---

From: tursi <[email-masked]>
Date: Mon, 7 Feb 2011 14:04:17 -0800 (PST)

> a$=SEGS(S$,VAL("3"),VAL("4"))

This is kind of the point I was trying to make - you can go too far and do 
worse than the original code you are trying to optimize. I don't know how 
many bytes that example takes, but it's going to be painful to write, and 
if you only call it once (which is what you should be doing anyway - one 
subroutine to parse the data into usable variables), there's no need to go 
to that length. He needs numbers eventually anyway, so your expression 
really looks like X=VAL(SEG$(S$,VAL("3"),VAL("4")))...

At a guess, that might save a few bytes - figure a number is 8 bytes plus 
a token, so the VAL replacement would be a token for VAL, a token for the 
string, two bytes (in this case) for the string itself, which is half the 
size. But that's a guess - in the example given you'd only save 20 bytes 
in the subroutine. I wouldn't go there unless I was really scraping every 
last byte, myself. Readability of the code is important too! :)

---

From: Owen <[email-masked]>
Date: Mon, 7 Feb 2011 19:42:54 -0500

Thank you guys very much...  Answered my questions.

I'll carry the individual variables throughout the program... I was really planning on padding the "fields" in the string.... For instance, any field that was inconsistent in length would be padded.  

Forgive Yahoo's butchering of this code box:

[code]

CARPET.003.205
FIG   .008.206

[/code]

FIG is followed by "3" spaces.  But Tursi's idea of putting the names last is a good one.  It's all academic now though... I'll be carrying the variables throughout... It won't be that big of a deal--- even with the large amount of map data stored for use by an assembly subroutine....  I'll set up the variables and post them tomorrow or so... As soon as I can get it all worked out.  I have some pretty cool ideas on how to compress these stats... I believe many can be reduced into few.

Sent from my iPhone