ikrams.com

I've written a small Colorforth application, a demonstration of selection sort. All it does right now is display a randomized array, sort its contents and display the result. With a little extra work it could be made to 'animate' the sort.

The code is laid out in two blocks, one containing the initialization and sorting words, while the display words are in the next block. To run the code, load both blocks and invoke the demo word. Doing so will continually display the current state of the array until you launch a different application. Then invoke init to randomize the array, followed by sort to perform selection sort.

Here's the first block:

Colorforthers will recognize the array/nums combination as the idiom for statically allocating space for an array and obtaining its address. This array consists of 3 cells, enough to fit 12 byte-sized values. Why limit the demo to sorting 12 numbers? — mainly because that's how many lines of large font text can fit on my screen.

I scarfed the 1@/1! macros from other blocks that came as part of the CF system. Their purpose is to insert machine code for accessing byte-addressed memory locations (as opposed to CF's more usual cell-addressing.) They are used here in order to define the pair of words n@/n! which permit indexed access to the array of numbers.

There follow a few words for initializing the array. init uses the system clock to seed the random number generator and randomize the array. rand is a pseudo-random generator I read about in the Wikipedia article on Park-Miller RNGs, which, incidentally, says that this very RNG was used in the ZX Spectrum.

If it was good enough for Sir Clive then it's good enough for me, is what I always say.

randnums is how the array actually gets randomized. Its for loop runs though the indices from 11 down to zero, obtaining a random number and depositing it into the current index (only the lowest byte of the random number will get stored by 1!)

sort carries out an ascending sort. For each location from the first up to the penultimate, it determines the index of the minimum value seen between the current index and the end of the array. This value gets moved into its sorted location by the exchange word.

The workhorse of this algorithm is compare. The word's stack comment shown in the code has this meaning: given an index (i), and an array item (min) located at another index (mini), compare will return whichever is the lesser between min and the content of i. It will also return that value's index, either mini or i.

i- holds a special place in my heart as it's my first CF macro. Here's why it's useful. CF's for/next loop counts down from some N to 1. But there were a couple of words in the present program, sort included, where I found myself writing for loops that count up from zero to some N-1, using the phrase "N i negate +" to obtain the loop control variable. The macro in question allows this kind of thing to be shortened to "N i-"

Since all this macro is required to do is substitute itself by the phrase "i - + 1 +" it ought to be definable using cyan words exclusively (as opposed to green words which are executed for their side-effects at macroexpansion time.) Not so, I found, because constants like 1 cannot be rendered in cyan. However, a little rummaging around the CF distribution turned up a solution in the form of the "lit," macro which forces literals to be compiled.

On to the second block:

The demo word programs a background task to continually refresh the screen with a real-time display of the current sequence of values in the array. Each number is shown in large font with 3 digits, and the entire sequence is laid out in a single column.

digit breaks up a non-negative value into a specified number of decimal digits represented as CF character codes (24 is the code of the zero character.)

So that wraps up my commentary on the code. I might get around to making the interface more interactive. The basic idea may be to offer the user keys to directly invoke the minimum and exchange words.