When everything goes, and you ditch the remainder
13 / 4 = 3
STRAIGHT to work this month. Try running Program I:
10 REM *** PROGRAM I ***
20 MODE 6
30 FOR loop%=0 TO 17
40 PRINT loop% DIV 3
50 NEXT loop%
And now you are probably wondering what's going on.
Well, do you remember doing divisions in your schooldays? You
did sums like this:
and probably read the answer out something like this: "4
goes into 13 three times remainder 1".
Or, if you were mathematically inclined, you might have said:
"The quotient is 3, the remainder 1".
Notice, you didn't use fractions or decimals then — you worked
in whole numbers.
Now in line 40 of Program I the DIV means division. It's a special
sort of division though, in which you work only in whole numbers
— we call it integer division. You ignore any remainders.
The answer is just "How many times it goes" - the
quotient.
So 13 DIV 4 would give the answer 3. Try this by entering:
PRINT 13 DIV 4
and you 11 see what happens.
In Program I, when loop% has values between one and two, three
"doesn't go" so the answer is zero for each sum — remember,
we ignore the remainders.
For loop% equal three to five, three "goes once",
with various remainders which we ignore, so the answer for these
three sums is one.
I think you can see by now why the next three DIVs gives the
answer two.
What would happen if we changed line 40 to:
40 PRINT loop% DIV 40
See if you can visualise it before you try running the amended
program. Program II uses MOD instead of DIV. Again this is a sort
of integer division, but this time we ignore the quotient - how
many times it "goes" -and just take the remainder as
the answer.
10 REM *** PROGRAM II ***
20 MODE 6
30 FOR loop%=0 TO 17
40 PRINT loop% MOD 3
50 NEXT loop%
Fascinating, isn't it? The answers cycle 0, 1, 2, 0, 1, 2, 0,
1, 2. It's quite simple to see why:
0 divided by 3 gives remainder 0
1 divided by 3 gives remainder 1
2 divided by 3 gives remainder 2
3 divided by 3 gives remainder 0
4 divided by 3 gives remainder 1
5 divided by 3 gives remainder 2
6 divided by 3 gives remainder 0
and so on.
Again, try to visualise what will happen if you change line
40 to:
40 PRINT loop% MOD 4
This time it cycles 0, 1, 2, 3.
Believe it or not, we often want to cycle through numbers this
way. You can use the technique with REPEAT ... UNTIL loops:
10 REM *** PROGRAM III ***
20 MODE 6
30 counter%=0
40 REPEAT
50 PRINT counter% MOD 3
60 counter%=counter%+1
70 UNTIL counter%=21
Notice that the numbers cycle through 0, 1 and 2. Suppose you
want them to cycle between 1, 2 and 3. This is easily done by
changing line 50 to:
50 PRINT counter% MOD 3 + 1
In other words, you add an offset of one to the old line 50,
so what would have been 0 becomes a 1, what would have been 1
becomes a 2 and what would have been 2 becomes a 3.
Of course the next time through the loop the old line 50 would
have "flipped" back to 0, so the new version flips back
to 1 and so on.
Can you alter line 50 to:
50 PRINT (counter% MOD 3) * 2
Can you see what's happening? Can you make it cycle 0, 3, 6?
10 REM *** PROGRAM IV ***
20 MODE 5
30 counter%=0
40 REPEAT
50 COLOUR counter% MOD 4
60 PRINT "Colour"; counter%
70 FOR delay%=0 TO 1000:NEXT delay%
80 counter%=counter%+l
90 UNTIL FALSE
Program IV is one of the most complex we have so far covered,
so let's look at it in detail.
When you're deciphering a program, the first thing you need
to know is what it's supposed to be doing.
Well, Program IV is meant to print out:
Colour 0
Colour 1
Colour 2
Colour 3
repeatedly, each line in the appropriate colour - that is, 'Colour
3' in logical colour three and so on.
Lines 40 to 90 form a REPEAT ... UNTIL loop designed to do this.
counter% increases each time through the loop (line 80). We
use it to choose the colour in line 50, by setting the colour
to counter% MOD 4 - if you cast your mind back, this will cycle
between 0, 1, 2 and 3.
Line 70 may confuse you — it's just a FOR . . . NEXT loop with
nothing in between. I'm able to put the FOR . . . NEXT in the
same line because I've used a colon between them. We covered that
last month.
Having a loop which does "nothing" may seem rather
crazy, but it's only there for delay purposes, as the name of
the loop variable suggests.
The micro does the loop 1001 times — doing nothing each time
admittedly, but taking up time doing it.
Try omitting the line and see what happens.
As it stands Program IV has a flaw. Since our background colour
is logical colour zero (black) when the foreground is logical
colour zero, the message doesn't show.
This being so, there's not much point in getting the micro to
print it out. We may as well just cycle through 1, 2 and 3.
Well, we can cycle through 0, 1 and 2 with MOD 3, so MOD 3 +
1 will cycle through 1, 2 and 3 since we are adding an offset
of one.
So let's change line 50 to:
50 COLOUR counter% MOD 3 + 1
and the logical colours 1, 2 and 3 will be displayed.
Try altering Program IV so that it outputs all the colours available
in Mode 2.
10 REM *** PROGRAM V ***
20 MODE 5
30 asterisk$""
40 FOF loop%=0 TO 18
50 asterisk$=asterisk$+"*"
60 COLOUR loop% MOD 3 + 1
70 PRINT asterisk$
80 NEXT loop%
Isn't Program V pretty? We've printed triangles of asterisks
before, but never multi-coloured ones.
If you remember, we rang the changes with our triangles - inverting
them, making pyramids and so on.
Why not try to recreate those triangles in technicolour? If
you're short of inspiration have a look at the beginners' article
in the January edition of The Micro User. The "revision"
will do you good - consolidating ideas we'll take for granted
from now on.
10 REM *** PROGRAM VI ***
20 FOR loop%=0 TO 5
30 PRINT RND(6)
40 NEXT loop%
If you look at Program VI you'll notice that we don't have a
line to select the mode we're in as we've done with other programs.
There's a reason!
Type it in, select mode 4 with:
MODE 4
and RUN the program. Then RUN it again immediately without clearing
the screen. I want you to compare the outputs of each run — that's
why I didn't change mode at the beginning of the program.
Unless you're particularly unlucky, the two sets of outputs
should differ. If they don't, run the program again until they
do.
Wait a minute, though. Hasn't something gone wrong somewhere?
After all, it's the same program — how can there be two different
outputs?
Well, the evidence should be there in front of you. The secret
is, of course, in line 30.
You see, RND is short for random. RND(6) picks a whole number
at random between 1 and 6. You can't decide which, the computer
does!
RND(12) would pick a whole number between 1 and 12 and so on.
Actually, this RND business can be quite complicated. As an
example RND(O) and RND(l) are special, and on top of that RND
isn't exactly random! For the moment, however, we'll ignore all
that.
You may be wondering why we need random numbers at all. They're
excellent for games — for instance you can generate a realistic
dice throw.
And, as one of my more cynical friends puts it, you can make
the micro seem more human if it acts randomly.
10 REM *** PROGRAM VII ***
20 MODE 2
30 asterisk$=""
40 FOR loop%=0 TO 5
50 asterisk$=asterisk$+"*"
60 COLOUR RND(7)
70 PRINT asterisk$
80 NEXT loop%
Try Program VII. Each time you run it it should give a different
pattern of colours unless you randomly pick the pattern you had
before - which is always possible.
Notice that line 60 picks colours in the range 1 to 7. This
time we've no need to worry about an offset to avoid colour 0,
the background colour.
I've stopped at 7 so as to avoid the flashing colours. Change
line 60 to:
60 COLOUR RND(15)
if you want to include these.
That's all for this month. Next month we'll be looking at procedures.
