Is there a list of space-saving techniques for representing constants?

Question

Since numbers in ZX BASIC are always floating point and take up 5 bytes, it's often possible to save space when representing integers by using several tokens, which take up 1 byte each.

I know of COS PI for -1, NOT PI for 0, SGN PI for 1, INT EXP SGN PI for 2, and INT PI for 3.

I can also think of a few like INT EXP PI would be 23. Is there a complete list of combinations of tokens which are shorter than regular integer representations, up to (say) integer 63?

Related: Why does this BASIC program declare variables for the numbers 0 to 4?

Answer 1

Solution:

I know, this is a bit unfair, but there's a generic solution to that:

• VAL "n"

Using VAL with an integer(*1) will always be three bytes shorter than that integer used directly. No matter if needed in an expression, as parameter or as a GO TO/ GO SUB target :)

That's right, GOTO VAL "10" is 3 bytes shorter than GOTO 10 :)

How it Works:

As described here

• a numeric constant uses 6 bytes plus its ASCII representation.
• VAL "" takes 3 bytes plus the ASCII string to be converted.

So there's always a net saving of 3 bytes.

The Fine Print

Of course doing an ASCII conversion every time a constant kills performance - essentially negating the otherwise great benefit of Sinclair BASIC regarding constants. Thus, in next to all real world cases, it is recommended to store it in a variable instead of doing that conversion every time. This not only speeds up execution, gaining back a bit of the lost speed, but saves another 2-3 bytes per usage (*2) after the second usage(*3).

---

*1 - Well, the same is of course true for float as well.

*2 - 2 bytes minimum with a single digit integer used and a two character variable. 3 bytes with a 1 character variable. and an additional byte for each additional digit of the number in question - all per usage.

*3 - Assigning a variable has an overhead of 5 bytes, so it need to be used at least twice to save over all.

Answer 2

There are quite a few options available if you need to reduce the size of your BASIC programme. Some of the options are more extreme and may require binary modification of your program (or the use of external tools/programs). Therefore, I'll try to document both options available to you as a vanilla BASIC programmer, and options that will require binary editing.

1. Numbers are stored in ZX BASIC with two representations, simultaneously. The "user" representation is literally a string that you typed. The "internal" representation is always 6 bytes long and it contains special code 14 followed by 5-byte internal format (it is true for both floating point and integer numbers). Thus, usually, an N-digit number will occupy N+6 bytes of memory. This is the upper bound for people who work in vanilla BASIC.

For example, RANDOMIZE USR 49152 occupies 2+5+6 = 13 bytes of memory.

2. The internal representation is used for all computations and is computed when the string is inputted. A common hack involves typing in the program using 1-digit numbers for all numerical constants (e.g. "0") and then replacing internal representations for these constants by the required values. This is awkward to do directly on ZX Spectrum, but with an external hex editor it can be done routinely enough. This means that ANY number (including floating point) can be stored using no more than 7 bytes of memory, this is the upper bound for people who are pushing their BASIC to its absolute limit.

If you see a protected program doing RANDOMIZE USR 0, it is not very likely to jump to address 0; in fact, it is likely to have been modified to jump to an address you can figure out by looking at the internal representation.

3. Both Raffzahn and I covered the use of VAL before, but I'll include it here too, for the sake of completeness. Briefly, any number written as VAL "number" does not store an internal representation. So VAL "0" is only 4 bytes long, and, more generally, when using VAL, N-digit number would only occupy N+3 bytes of memory.

Many loaders begin with a command like CLEAR VAL "24999". It occupies 1+5+3 = 9 bytes of memory. A seemingly shorter command CLEAR 24999 would have occupied 2+5+6 = 13 bytes of memory instead.

4. Note that if we allow binary editing, CLEAR 0, with an internal representation of 0 modified to represent 24999, would only occupy 8 bytes. Therefore, VAL is particularly competitive for shorter numbers, no longer than 3 digits. In fact, I should have said "characters", not "digits". It is because many numbers can be written a bit more compactly using the scientific notation, or using mathematical operations within a VAL expression string. For example, don't write "25000", write "25E3", don't write VAL "32768", write VAL "2^15" or, even better, VAL "8^5", etc.

5. For integer numbers that fit into a byte, you also have an option of using function CODE that returns ZX ASCII code of the character provided. Similarly to VAL "0", CODE "0" occupies 4 bytes. However, CODE "." can generate two- and some three-digit numbers, which would require a longer VAL command. Thus, CODE is useful to represent numbers from 10 to 255 using 4 bytes of memory. Most specific codes can be entered directly from BASIC, but the full range 0..255 would require binary editing of your program.

A popular trick to remove any output from the loading command is to POKE 23739,111. This command occupies 1+5+6+3+6 = 21 bytes. Most actual loaders would POKE VAL "23739",CODE "o", which occupies only 1+5+3+4 = 13 bytes instead, the saving of over 30%.

6. Last, but not least, there are also tricks with various funny expressions, some of which you mentioned in your original question. Below, I'm setting up a table of tricks that I know and I would be happy to add any futher tricks if someone is happy to share more. Please note that many BASIC commands that expect integer inputs would automatically round the numbers that are not integer, so these approximate inputs can be useful even if they do not produce exact integer values:

   Number     Best exact expression     Shortest approximate expression

      -1         COS PI (2 bytes)
       0         NOT PI (2 bytes)
       1         SGN PI (2 bytes)
       2         VAL "2" (4 bytes)             SQR PI (2 bytes)
       3         INT PI (2 bytes)              PI (1 byte)
       4         VAL "4" (4 bytes)             EXP ATN PI (3 bytes)
       5         VAL "5" (4 bytes)             SQR EXP PI (3 bytes)
       6         VAL "6" (4 bytes)             PI+PI or EXP SQR PI (3 bytes)
       7         VAL "7" (4 bytes)
       8         VAL "8" (4 bytes)
       9         LEN STR$ PI (3 bytes)
      10         VAL "10" (5 bytes)            PI*PI (3 bytes)
   16384         VAL "4^7" (6 bytes)
   16807         VAL "7^5" (6 bytes)
   19683         VAL "3^9" (6 bytes)
   20000         VAL "2E4" (6 bytes)
   30000         VAL "3E4" (6 bytes)
   32768         VAL "8^5" (6 bytes)
   40000         VAL "4E4" (6 bytes)
   46656         VAL "6^6" (6 bytes)
   50000         VAL "5E4" (6 bytes)
   59049         VAL "9^5" (6 bytes)
   60000         VAL "6E4" (6 bytes)

Answer 3

I remember seeing PI/PI instead of 1 in the programs back then a lot. Clearly they did not know a better trick.