# How to score TI-BASIC

How do we score code written in TI-BASIC, when it comes to multi-character words? For example:

:If X>2:Then:Stop


Seemingly, the above should count as 17 characters. However, TI-BASIC treats the Then as a single character when it comes to selecting and deleting characters, unlike most programming languages where the four letters can be written, changed, or deleted separately. So should the above line count as just 9 characters?

• That just sounds like a quirk of the TI-BASIC editor, rather than the language really allowing you to use 1 character for writing then. So unless you can actually validly use 1 character, I would not count it as such. May 8 '14 at 19:02
• I believe the same is true for BASIC on the ZX Spectrum. May 8 '14 at 23:07

# TI-Basic is tokenized

Each one-byte token (Then, If, End, Ans, etc.) is stored internally as one byte. Thus, it should only count as one byte. Similarly, lowercase letters a-z count as two bytes each, since this is how they are stored on the calculator. (Source).

Each command, variable, and operation on the TI-83 series calculators is represented by a "token." This means that internally, the calculator does not store a command such as "cos(" as the letters c, o, s, and (. It stores a single number that it will later translate as "cos(" when necessary. In this case, the value is 196, but you most likely don't need to know that. What you do need to know is that not all tokens are the same size. If there were 256 tokens or less, then you could fit all their values into 1 byte and be happy. Unfortunately, the TI-83 has more than 256 commands and variables. Therefore TI employed some trickery and made some tokens take up 1 byte (usually the most common ones, though they seem to have had a different idea of "common") and some take up 2 bytes. What this means to you, as the programmer, is that the size of the program is determined by the number of commands, not the number of letters in it: a short line can take up more memory than a longer one if it uses a lot of commands. Furthermore, some commands will take up the memory of two commands rather than one, so a line with a few of these commands may take up as much memory as a line with more commands of the ordinary type. Lowercase letters are the epitome of memory wasters: at a single character, they each take up 2 bytes of memory. A program that uses a lot of lowercase letters can fill up all of RAM very quickly! This may be avoided by using uppercase letters instead, which only take up 1 byte each. You can also save memory by replacing words such as "If", " or ", " and " with the appropriate commands, when displaying text. Such a command will only take up 1 byte, whereas the text may be much larger memory-wise.

• Seems reasonable to me, although I'd add the caveat that this only applies if the challenge is scored by bytes. If the challenge is scored by characters, I think you should actually count the characters (as kitcar2000's answer suggested). Feb 7 '15 at 11:25
• In my opinion, even if the challenge is scored by characters, we should count tokens, and score each one- or two-byte token as one character. On the calculator, programs are not entered one displayed character at a time, but rather one token at a time. If the challenge is scored by characters, Unicode encoding, with access to 10000+ characters compared to the calculator's hundreds, would still have an advantage over this and most other tokenized languages. Jun 8 '15 at 20:45
• Note that this depends on the calculator. Many TI calculators let you actually type those commands character by character and use them as such. Dec 25 '18 at 15:00
• This is very similar to jelly, 05AB1E, etc. that use SBCS and even though their programs are displayed with unicode, the actual program uses all the bits... ...and no one says that they are cheating.
– Wezl
May 1 '20 at 17:58

In short, I think that it depends on the form of .

If you are counting in letters/characters you should count the individual characters, while if you are counting in bytes you should count it as one (assuming that, like the ZX Spectrum, it uses single bytes for the functions). As the tag wiki explains, you should measure bytes if not otherwise specified.

I do not know whether this applies to TI-BASIC as well, but I know that in BASIC for the ZX Spectrum there are no line breaks either in the actual program and includes spaces in function names eg. 10 GO TO 10 is 1, 0, GO TO, 1 and 0. I think that these should still be treated as characters and not bytes.

An example would be:

10 LET x=0:IF x<10 THEN LET x=10
20 PRINT x


This contains 22 bytes but 43 characters.

I was thinking about a similar concept for counting the code length of languages like C, Pascal, ... and so on by assuming every reserved word would be tokenised as if we had a C, Pascal, ... editor with a tokeniser like in classic BASIC systems.

"Normal" languages can not beat APL, J and all the other "golfy" languages' code length often enough when not counting each language entity (reserved word) as only 1 point.

Maybe even a step further, we could count every identifier (var-, function, procedure, ... name) as one point and discard whitespaces outside strings and comments and docstrings (see Python) not being used as diusguised program text storage.

This would kill the advantage to use short names and give readable code a chance even if well commented.

But who will be able to manage all this? A jury cannot know all language definitions and I bet not even everyone coding codegolf answers knows his language well enough.

I see no general way to solve this, but in your case (tokenised BASIC) we may be able to see the length of the stored tokenised source like in BASICs of the 80s. Some interpreters/editors save the tokenised program as default.

Can you see the tokenised length of your code in some directory listing?

The last hurdle is the one defining the rules for the individual puzzle: We need some lobbyism there or nearly every golfing will end being won by an unreadable piece of code of a special golflanguage.

And I do not think this really is funny, interesting or desired.

• Have you seen the posts about atomic-code-golf? May 14 '14 at 14:28
• I expected something like this to be discussed already but wanted my answer to stick here. Thinking about counting atomic entities is very similar to what a tokenized storage of e.g. BASIC does. This shows that we already had such code metric in the past in a natural way each time we saved the TRS-80 BASIC program and looked up it's length in the directory. REM-killers were common too those days... and I'm a fossil and feel nostalgoholic from time to time. I hope my answer here didn't hurt...
– user19214
May 14 '14 at 14:40
• Oh, I just wanted to point you to it if you hadn't seen it already since it's related. May 14 '14 at 14:49

## I prefer Unicode.

Code length is usually counted in characters (Unicode code points), though some contests use bytes.

My preference is to transcode the TI-83 program into Unicode, then count Unicode code points. For example, this golfed program by mellamokb has 41 characters:

:Prompt A,B,C
:(C-B)/(B-A→M
:Disp M,B-A*M


The store arrow → becomes U+2192 RIGHTWARDS ARROW, and the triangle ▶ in operators like ▶Frac and P▶Rx( becomes U+25B6 BLACK RIGHT-POINTING TRIANGLE. For Greek letters, pi π is U+03C0 GREEK SMALL LETTER PI and theta θ is U+03B8 GREEK SMALL LETTER THETA. For exponents, square ² is U+00B2 SUPERSCRIPT TWO and inverse ⁻¹ is U+207B SUPERSCRIPT MINUS, U+00B9 SUPERSCRIPT ONE. Negation ⁻ is U+207B SUPERSCRIPT MINUS. The root operator ˣ√ is U+02E3 MODIFIER LETTER SMALL X, U+221A SQUARE ROOT. The function ₁₀^( is U+2081 SUBSCRIPT ONE, U+2080 SUBSCRIPT ZERO, U+005E CIRCUMFLEX ACCENT, U+0028 LEFT PARENTHESIS.

If I must count bytes, I may pick any encoding, such as UTF-8 or UTF-16, that includes enough characters for my program. So I pick UTF-8 if it takes the fewest bytes. Some, but not all, TI-BASIC programs fit in ISO-8859-7, an 8-bit Greek encoding. Pi π is 2 bytes in UTF-8 but only 1 byte in ISO-8859-7. ISO-8859-7 lacks characters like the store arrow →, but if my program has no store arrows, I might count ISO-8859-7 bytes.

## What is a TI-83 character?

In the calculator manual for a TI-83 Plus, page 15-8 says:

Note: An instruction or function name, such as sin( or cos(, counts as as one character.

This definition is clear. Each instruction, like If or While, is one character in the calculator. Each function, like tan⁻¹(, and each operator, like nPr, is one character in the calculator.

The length( function in the catalog can answer all questions about character count. length(" nPr ") returns 1, so nPr is one character.

I cannot answer questions about byte count. The calculator seems to have more than 256 characters, so I reject the idea that each character fits in a byte of 8 bits. Anyone who says that sin( is 4 characters and 1 byte is wrong about the characters, and might be wrong about the bytes. The calculator might use a multibyte encoding, or it might use a larger byte size, like 12 bits.

I prefer to count Unicode characters, not calculator characters. For bytes, I prefer to encode the Unicode characters in UTF-8 or perhaps ISO-8859-7.

• This seems to be outdated. The default (as per the code golf tag wiki) is bytes, not characters. (For all languages.) Feb 7 '15 at 11:20
• Every token on the calculator has a length of one. This answer is incorrect. Feb 8 '15 at 19:06
• To clarify above, not all tokens are one byte, but every token when measured with length( has a length of one. Jun 17 '15 at 19:51

I agree with kernigh's arguments that code golf should be scored with unicode code points. In the TI-BASIC editor, words are treated like one character (using left and right keys to navigate) and it is impossible to delete characters in a word. The only argument for counting them as multi-character is how they is displayed.

In memory each word is saved as one unicode character. This can be seen by uploading a program from a calcuator to a compter and opening the .8xp file.