?he 'ARITH2''Page %'
.fo 'Max Clowes'- % -'1st June, 1977'
.ce2
MORE THINKING ABOUT ARITHMETIC
.br
=============================
.sp
While
FOUR, FIFTY SIX,
etc. may capture the numbers-as-sounds aspect of Arithmetic it
does not address the visual character of much of our figuring.
Layout as in
 	36 + 54 = 90
.br
or
 	36
     +  54
 	--
 	90
 	--

.br
is an essential part of what has to be learned. And the items laid
out - the Arabic numerals 3, 6, 5, 4 - themselves have a structure,
a shape that is quite unlike the corresponding sound.
.sp
We could use the
TURTLE
to model the drawing skill that creates those shapes:
 	: FUNCTION THREE(X, Y);
 	:	3 -> PAINT;
 	:	JUMPTO(X, Y); FACE(RIGHT);
 	:	DRAW(6); FACE(UP);
 	:	DRAW(5); FACE(LEFT);
 	:	DRAW(3); DRAW(-3); FACE(UP);
 	:	DRAW(5); FACE(LEFT);
 	:	DRAW(6)
 	: END;
.br
When invoked, this function draws a figure three at position X,Y.
.sp
I've replaced the usual 
TURTLE
command
TURN(ANGLE);
by
FACE(RIGHT); FACE(UP);
etc. I have it in mind to declare
UP, DOWN, RIGHT, LEFT
as global variables:
 	: VARS UP DOWN LEFT RIGHT;
.br
whose values are constants, viz:
 	: VARS UP, DOWN;
 	: 90 -> UP; -90 -> DOWN;
.br
FACE
merely assigns the value of its actual parameter to the
Turtle's
HEADING:
 	: FUNCTION FACE(DIRECTION);
 	:	DIRECTION -> HEADING;
 	: END;
.br
Experiment with
FACE
and
DRAW 
to work out some more pictures of numerals. Making the colour
of the
PAINT
echo
the identity of the pattern drawn in that colour, e.g. 
 	: 3 -> PAINT;
.br
adds an aesthetic touch(!) and will prove useful later when we try
to think about how to recognise patterns you've drawn.
.sp
Don't forget to call
 	: TURTLE();
.br
before
you offer these functions to
POP11.
And you'll need to decide what
X
and
Y
ought to be when you call 
THREE, FOUR
etc.
 	: THREE(2,2); DISPLAY();
.br
The values I've used are compatible with the size of
PICTURE
that
TURTLE
provides but of course I won't always want to draw a 3 in this
location on the page. What would we do to draw
33 for example?
.sp
Deciding how much 
PICTURE
you will need to encompass the pattern of figuring demanded by
an addition task is not easy, and while the particular mechanics used
in our
TURTLE
approach may not conform exactly to the strategies that children
adopt, the ragged columns and wavering rows of the learner's copy
book bear testament to the reality of the problem.
.sp
How could we draw 
COLUMNS
of figures using
TURTLE?
Given
 	: [SIX FOUR]
.br
for example how would we
draw:
 	6
 	4 ?
.br
Supposing each numeral picture is 10 units high and 10 units
across then the picture for 
[SIX FOUR] 
would need to be 2 x 10 units high and 10 units across.
How about:
 	: NEWPICTURE(10, LENGTH(LIST)*10));
.br
.sp
So we could write a function to turn a list of number names, for example:
 	: [SIX FOUR SEVEN ONE]
.br
into, say, a
COLUMN
of numeral pictures:
.tp8
 	: FUNCTION COLUMN(LIST);
 	:	NEWPICTURE(10, LENGTH(LIST)*10);
 	:	UNTIL	LIST = []
 	:	THEN	HD(LIST);
 	:			TL(LIST) -> LIST;
 	:	CLOSE;
 	:	DISPLAY();
 	: END;
.br
Does that work? What does
HD(LIST);
achieve there, did anything appear in the picture? Try it independently
of the function, e.g.
 	: HD([THREE FOUR]); DISPLAY();
.br
The problem revolves around the fact that the functions
THREE FOUR SIX
etc. that you have defined are not being 'activated'. What is
happening to them?
Try
 	: APPLY(VALOF(HD([THREE FOUR])))
 	: DISPLAY();
.br
and read the section on
VALOF
in
SYSVARS.
.sp
Unhappily 
COLUMN
has further defects as you may have realised, concerned with 
positioning the numeral pictures.
.sp
What would
COLUMNS
of numbers look like? What sort of input list would it work on?
.sp
When you add up a column of numbers you silently articulate the
names
"FOUR", "SIX",
etc. of the numerals you've recognised. You convert it from a picture
to a jingle so to speak so that you can apply your knowledge of
TRIPLES
which are of course jingles.
The basic task here - a recognition task - is 'given a 
PICTURE
in which a numeral has been drawn (by
TURTLE)
write a function which will produce the appropriate number name'.
Programs to recognise shapes have to be very sophisticated because
there are so many variations of the picture of a numeral.
It can be printed or handwritten, large or small, mixed in with other
letters and diagrams, even upside down! We can avoid some of the harder
problems of shape recognition by utilising the colour code we built
into the
PAINT.
What we need to do is to inspect every point in
PICTURE
until we find one that's not blank - its colour tells us what
numeral we've bumped into. While we could get the
TURTLE
to traverse the entire
PICTURE
point by point its much more efficient to test the picture
points directly:-
 	: IF	PICTURE(X,Y) /= SPACE	THEN	......
.br
which tests to see if the location X,Y in the
PICTURE 
is a space. What we need to do is to arrange that all the possible
combinations of values for X and Y are used : and that
requires that we know how big
PICTURE 
is. Let's assume its 10 x 10.
.tp16
 	: FUNCTION FINDPAINT() => COLOUR;
 	:	VARS X; 1 -> X;
 	:	VARS Y; 1 -> Y;
 	:	REPEAT 10 TIMES
 	:		REPEAT 10 TIMES
 	:			IF	PICTURE(X,Y) /= SPACE
 	:			THEN	PICTURE(X,Y) -> COLOUR;
 	:			EXIT;
 	:			Y + 1 -> Y;
 	:		CLOSE;
 	:		X + 1 -> X;
 	:	CLOSE;
 	:	FALSE -> COLOUR;	;;; No painted points
 	: END;
.br
Try this out on a 
PICTURE
in which you've drawn something
 	: FINDPAINT() =>
.br
and on an empty picture too.
.br
Now we 'know' the identity of the numeral if there is one but we need
to
NAME
it:

.tp12
 	: FUNCTION NAME => NUMNAME;
 	:	VARS IDENTITY;
 	:	IF	(FINDPAINT()->IDENTITY, IDENTITY = FALSE)
 	:	THEN	'PICTURE IS EMPTY' =>
 	:	EXIT;
 	:	;;; Use value of IDENTITY to select a number name
 	:	IF	IDENTITY = 3
 	:	THEN	[THREE] -> NUMNAME
 	:	ELSEIF	IDENTITY = 4
 	:	THEN	[FOUR] -> NUMNAME
 	:	ELSEIF 	IDENTITY = 5
 	:	...
 	:	CLOSE;
 	: END;
.br
How well would this work on a
PICTURE
created by
COLUMN([THREE FOUR]);
presuming that we'd got all the bugs out of
COLUMN?
.sp
The most obvious problem here is that of knowing how big the
PICTURE
is. We can find out the dimensions of 
PICTURE
(or indeed of any 'array') using
FNPROPS.
Try
.tp4
 	: NEWPICTURE(10,10);
 	: FNPROPS(PICTURE) =>
 	: NEWPICTURE(5,6);
 	: FNPROPS(PICTURE) =>
.br
So we don't need in
FINDPAINT
to assume a picture size of 10 x 10, we could find out the size
of the current picture and use that information to determine the
number of repetitions. What would
FINDPAINT
look like if modified in that way?
.sp
As well as these technical problems there are a number of hard
conceptual problems, How will
NAME
work when there's more than one numeral in the
PICTURE?
How will
FINDPAINT
ever find the second (and subsequent) numerals? We might (using
FNPROPS(PICTURE);
conclude that we've got a rectangular
PICTURE
with its long axis vertical. How could we get
FINDPAINT
to look up (or down) this rectangle? Again, the best
technical solutions are not immediately apparent but we can perhaps see
once more that we have exposed something of the structure
of the 'arithmetic reading' tests. Understanding the significance
of a columnar format for numerals rather than a row format; guiding
the recognition scan over the format; remembering the
order in which the number names produced by
NAME
are produced. All of that as a preliminary to activating
AUTADD!
No wonder people make mistakes adding up columns of figures, and that
children mistake additions for subtractions.
.sp
Answering Arithmetic Questions
.br
------------------------------
.sp
One of Thyne's recurrent preoccupations is with the problems
that the learner faces in deciding from the task presentation what
kind of thing is being requested as well as in picking out information
items like number names. A failure to attend to the whole of the
teacher's utterance will turn
 	"what is the product of six and eight?"
.br
into an addition task:
 	"six and eight?"
.br
We could regard the failure here as that of overlooking the
phrase "the product" but a more careful analysis would reveal
that to correctly understand an utterance you need to grasp the
structure of it. It is perhaps easier to see the importance of 
structure in the visual case where there are no words. The
juxtaposition of two numbers one vertically beneath the other
marks them off as participants in, say, an addition operation. Numbers
juxtaposed horizontally or diagonally are not so combined. Thus in
.tp4
 	35
     +  46
 	--
.br
we understand that 5 is to be added to 6 and not to 3 or to 4. Recognition
of structure is, like recognition of shape, a very complicated business
which we cannot explore here. Confining ourselves to the
'auditory' case we can however pursue a rudimentary solution.
.sp
There are a number of familiar ways of stating an addition task:
.in+4
six and eight make?
five add on three?
seven plus nine equals?
one added to six is?
.in-5
and so on.
.sp
There is a common pattern of a pair of number names set into
a framework. What we can do is to 'recognise' the framework as a
basis for deciding what kind of arithmetic task this is and to extract
the information items
SIX EIGHT
etc. to be handed over to an appropriate arithmetic function, e.g.
AUTADD.
The basis of our 'framework recogniser' will be a function called
MATCH
which compares the list of words we are trying to recognise with a
pattern that we supply. 
Thus suppose we had the list
.tp9
 	: [SEVEN PLUS NINE EQUALS?] -> QUESTION1;
.br
representing an input question. Then
 	: VARS A B;
 	: MATCH([?A PLUS ?B EQUALS =], QUESTION1) =>
 	** <TRUE> 
 	: A =>
 	** [SEVEN]
 	: B =>
 	** [NINE]
.br
That is if the pattern
 	: [..... PLUS ..... EQUALS]
.br
is found in the next list
QUESTION
then A and B are assigned the values of the items which happened
to appear in the blanks between the 'key words' of the pattern. If
agreement is found between problem and input list then
MATCH
leaves
TRUE
on the stack otherwise
FALSE.
Try out some other lists and patterns
 	: [TWENTY FIVE PLUS NINE HUNDRED AND ONE EQUALS] -> QUESTION2;
 	: [?A PLUS ?B EQUALS =] -> PATTN1
 	: MATCH(PATTN1, QUESTION2) =>
.br
Now test A and B
 	: A =>
 	: B =>
.br
Try this variation in the pattern:
 	: [??A PLUS ??B EQUALS =] -> PATTN2;
 	: MATCH(PATTN2, QUESTION2) =>
.br
and once again test the values that A and B now have. Its this more
complicated type of pattern that we'll use so as to cater
for compound number names like
TWENTY FIVE.
Basically we want to assemble into a single package the collection
of patterns that characterise the statement of an
ADDITION TASK,
and another package of patterns for
SUBTRACTION TASK
and so on.
.br
Thus
.tp9
 	: FUNCTION ADDNTASK(LIST) => A B;
 	:	IF	MATCH([??A AND ??B MAKE =], LIST)
 	:	OR	MATCH([??A ADDON ??B =], LIST)
 	:	OR	MATCH([??A PLUS ??B EQUALS =], LIST)
 	:	OR	MATCH([??A ADDED TO ??B IS =], LIST)
 	:	THEN	TRUE
 	:	ELSE	FALSE
 	:	CLOSE;
 	: END;
.br
Try out this function on
QUESTION1
and
QUESTION2
i.e.
ADDNTASK(QUESTION1) =>. 
Remember to check A and B.
.sp
A similar function
SUBNTASK
would have its appropriate patterns. We can put them together in
a function that could be said (rather grandiosely) to 'understand'
requests:
.tp8
 	: FUNCTION UNDERSTAND(REQUEST) => ANSWER;
 	:	IF	ADDNTASK(REQUEST)
 	:	THEN	AUTADD() -> ANSWER; RETURN
 	:	ELSEIF	SUBNTASK(REQUEST)
 	:	THEN	SUBTRACT() -> ANSWER; RETURN
 	:	CLOSE;
 	: FALSE; 'NOT UNDERSTOOD' =>
 	: END;
.br
Now try to
UNDERSTAND
(QUESTION1!).
Of course 
UNDERSTAND
can't understand anything else,
[CLOSE YOUR BOOKS NOW CHILDREN] 
will not be intelligible at all.
.sp
.ce
-----------------
.sp
This computational account of simple arithmetic (here and in
ARITH1)
is obviously incomplete not simply in respect of functions that don't
quite work or haven't been explicitly defined yet. But also in that
the various fragments haven't been welded together in a functional
whole that could attempt one of Thyne's addition tasks:
.tp4
 	9
       +6
       --
.br
Moreover important issues have been
carefully avoided. How to do recognition 'properly', how to
meaningfully understand. Issues of attention have received
scant treatment and motivation has not been mentioned at all. But
in the more limited endeavour of trying to get an overall picture
of how complex 'adding' is, most if not all of what Thyne wants
to say about numbers has been faithfully modelled. The question is,
"have we made it easier to understand Thyne?'. I believe
the answer must be a qualified 'yes' if only because we have made
a concrete operational model out of a more or less abstract
almost philosophical descriptive system. 'Sign', 'significance',
'jingle', 'numbers' .... these and a host of other words now have
a clearer more precise meaning.
