and Mathematics

Murdoch University

Australia

ABSTRACT: Since graphing calculators are generally programmable, recent technological developments have the potential to provide many students with easy access to a programming facility. Some observations are made about the programming constraints of calculators, and conclusions for good practice drawn. Four different levels of use are described. A preliminary analysis suggests that there are at least six different kinds of uses of programmable calculators in mathematics. Some examples of these are given. and their value to the secondary curriculum briefly discussed.

Hand-held programmable calculators have been accessible for about
15 years now, although they have not been used much in schools.
In some countries, such as Australia, a major reason for the lack
of use has been the difficulty of designing and conducting public
examinations fairly. In the last five years or so, graphics calculators
have become available and affordable to schools, and are seen
to have a number of clear advantages over scientific calculators,
and even some advantages over computers. In fact, in the opening
session of the calculator miniconference at ICME-7, Bert Waits
suggested that we should acknowledge that graphics calculators
actually *are* computers. An interesting feature of graphics
calculators is that almost all are programmable, and have enough
memory for several programs to be stored for later retrieval.

It seems likely that the bulk of students in secondary schools
in industrialised countries will soon have routine access to a
graphics calculator, and thus a programmable calculator, as they
now do to a scientific calculator. The portability of the machines
further suggests that they might be available to students in places
that computers are not, such as in examinations and at home. It
is surprising then that there is so little literature available,
whether analytic, descriptive or research, pertaining to this
topic. For example, the NCTM's excellent recent yearbook (Fey
& Hirsch, 1992) contains almost no reference to the programmability
of calculators. A developmental project for preservice teachers,
based at Western Michigan University, is one of the few serious
attempts to exploit this tool. (Channell & Flanders 1992).
This paper provides an analysis of some of the features of programmable
calculators, to assist a consideration of the merits of using
them in secondary schools. Because of space limitations, the paper
does not address the practical and pedagogical implications, although
these would need serious consideration should the idea of using
programmable calculators appear to have educational merit.

Although programmable calculators have many similarities to each
other, there are also many differences. In this paper, my remarks
are based mainly on my experiences with a Texas Instruments TI-81
graphics calculator, a readily available and affordable machine
for many students in secondary schools. However, since there are
many similarities between modern calculator programming languages,
similar analyses might be expected with different calculators
in mind.

**One-line programming
**The most elemental form of programming involves the
automated repetition of a single step. On the TI-81, and on other
graphics calculators, commands consist of a single line, which
is 'executed' by pressing an 'enter' key. Pressing the 'enter'
key again repeats the previous command each time, until a different
command line is inserted into the calculator. In this way, the
same command can be repeated several times in succession. There
are some circumstances in elementary mathematics where this is
a useful action. For example, if the following command line is
entered:

int (6*rand + 1)

each successive pressing of the 'enter' key will execute the command, which in this case will generate a (pseudo-) random integer between 1 and 6, thus simulating a throw of a single die. Similarly, the more complex command

int (6*rand + 1) + int (6*rand + 1)

will simulate the sum of two dice each time the 'enter' key
is pressed. Such one-line programs could be used to pedagogical
advantage in early probability learning.

Repetition can be used to advantage to evaluate successive terms
of a geometric sequence, by also using the facility most graphics
calculators have to recall the result of the previous operation
from an 'answer' memory. On the TI-81, the answer memory is referred
to as **Ans** so the following command line will act as a one-line
program, giving a new value each time the 'enter' key is pressed:

Ans*1.06

Prior to using this command line, it is necessary to give the
sequence a starting value, followed by the 'enter' key. The successively
pressing the 'enter' key after the command line is entered will
effectively give values from a geometric sequence with common
ratio 1.06, or successive amounts under annual compound interest
growth of 6%.

The idea of repetition lends itself naturally to iterative sequences,
such as that generated by the interesting difference equation
*X*n + 1* = b X*n* (1 Xn) *for various values
of *b* and with a starting value of *X*1 in the interval
(0,1). The following one-line program will allow successive terms
of this sequence to be generated automatically each time 'enter'
is pressed (provided the starting value is first entered, followed
by 'enter', and provided also that the B memory contains the desired
value of *b*):

B*Ans(1Ans)

With such a facility, explorations of sequences like this,
which in fact can lead to an elementary example of the mathematical
idea of chaos, are made easier than before, and students can have
a new investigative tool for personal exploration.

**Scratchpad programming
**Calculator programs usually mimic the kinds of operations
that calculators use, since programmable calculators typically
access a rather limited set of program commands. The intention
of the programming is usually to automate a sequence of calculator
operations. In the case of graphics calculators, some of these
operations may be rather sophisticated, such as drawing a graph
of a function or constructing a regression line. This kind of
programming is sometimes called 'scratchpad' programming, perhaps
because programs are often scratched out on a pad before being
entered into a calculator. The leap from performing a calculation
on a calculator to writing a program to do it is often not very
large, and so it is likely that someone familiar with their calculator
will find the writing of short simple programs easier than they
might otherwise expect. In this regard, Ruthven's (1992) comment
at the ICME-7 conference, noting that many senior school students
in the UK had made spontaneous use of the programmability of their
graphics calculators after they had used the calculators for a
while.

In addition to mathematical functions, programmable calculators
use some input/output commands and some commands to allow for
a limited amount of transfer of control, through the use of *goto*
statements, statement labels (to *go to*) and branching instructions.
Unlike algebraic computer languages, higher level programming
power is not available on the less sophisticated graphics calculators
such as the TI-81. There are no easy equivalents to *while*,
*do...until* or even *for...next* statements, although
these are beginning to appear on more sophisticated calculators
such as the Texas Instruments TI-82 and the Sharp EL-9300. It
is quite possible that computer scientists would find the idea
of programming like this almost as dangerous as BASIC, in terms
of developing poor programming habits and conceptions, as many
would be uneasy about the liberal use of *goto* statements.
As well as programming commands, a programmable calculator will
also have some mechanism for storing, retrieving and editing programs,
akin to a computer operating system.

**Influences on programming style
**I think of a programmable calculator as a hand-held
tool that might be useful for mathematics. The emphasis is on
getting a job done, or exploring some mathematical ideas, rather
than on developing efficient algorithms or elegant programs
although these are often complementary aims. The nature of programmable
calculators suggests that different styles of programming from
those used for computers ma be appropriate.

As for computer programs, calculator programs can be written at various levels of complexity and with various degrees of attention to style and documentation. Some of the issues affecting programming style are briefly described in this section of the paper and exemplified in the next section.

** Audience** a program for oneself can often be
cryptic to someone else. That doesn't matter if others are not
expected to use it. Similarly, it is not necessary to design sophisticated
error-trapping routines in a program if only the author will use
it. (An example of an error-trapping routine would be a way of
detecting that an input to a program for factorising integers
was not actually a positive integer.)

** Usage** a program that is used only once or
twice does not need to be too sophisticated. Many programs are
probably like this, as they are written to address a need in solving
a problem. Even programs that are used repeatedly may use a fairly
rudimentary style.

** Prompting** if a program is stored for later
use (even by the author), a few prompts to the user may make it
more useable and less error-prone. It is very frustrating, for
example, to be presented with a question mark on a calculator
display and to have no idea what input is expected. This can happen
even to the author, if a program hasn't been used for a while.
It is often easier to rewrite a short program than to reinterpret
it.

** Length** the more sophisticated the style and
the more helpful the documentation, the longer the whole programming
task takes, and hence the less useful it is to do it at all. This
suggest that programs are usually short, with most less than a
dozen steps long. Indeed, long and complex programs probably have
little place on programmable calculators, and are much better
written for computers using high-level languages such as Pascal
or Fortran or even BASIC. Short programs are necessarily much
more transparent than long programs it is much easier for
students to understand how they work. As well as educational factors,
calculator storage space is also a constraint here, encouraging
a preference for shorter programs.

** Using** in which a student merely uses a program
that somebody else has written. The main demands on the student
are to understand how to run the program, to input information
to the program, and to interpret the output. At this level, it
is not necessary to know anything of a programming language or
even what a program is.

** Changing** in which a student interacts with
a program written by someone else by changing some of the commands.
Such changes may be small, such as changing a formula or a branching
condition. Studying the effects of a change allows students access
to some important mathematical ideas. At this level, students
need to know what a program is, how to edit program steps and
a little about the programming language concerned.

** Demonstrating** in which a program is used to
demonstrate some aspects of mathematics to a class by means of
an overhead projection device. The demonstrator is usually the
teacher, and some knowledge of how a program works is probably
important for such demonstrations to be valuable. In many cases,
both using and changing are involved in demonstrating.

** Writing** in which students write their own
programs, clearly involving a higher level of thinking than does
the use, modification, or demonstration of a program written by
someone else. At this level, students need a command of parts
of the programming language and the mechanisms for creating, modifying,
storing and retrieving programs for a particular calculator. Some
understanding of programming concepts such as loops and various
kinds of input and output are needed as well.

**TEMP1**

Input C

32 + 1.8C STO F

Disp F

The next version, TEMP2, loops back to the start, assuming
that a series of temperatures are to be converted efficiently
a reasonable assumption, since it would be unnecessary to
write a program to do the conversion only once. There is no end
statement in the program, although the TI-81 allows both a **stop**
and an **end** instruction. This program, like many others
written for calculators, can only be stopped by making an error.
It's not elegant, but it works.

**TEMP2**

Lbl 1

Input C

32 + 1.8C STO F

Disp F

Goto 1

Version TEMP3 uses **Disp** statements to prompt the user
by showing that the first entry is a Celsius temperature and that
the output is in Fahrenheit. This is useful if one other than
the author is using the program, or the author has forgotten what
the program does.

**TEMP3**

Lbl 1

Disp "CELSIUS"

Input C

32 + 1.8C STO F

Disp "FAHRENHEIT"

Disp F

Goto 1

The final version, TEMP4, asks the user to signal whether they
have finished or not, by inputting a 1 to say that there are more
conversions to come. The **If** statement for this executes
the following statement, and skips it otherwise.

**TEMP4**

Lbl 1

Disp "CELSIUS"

Input C

32 + 1.8C STO F

Disp "FAHRENHEIT"

Disp F

Disp "MORE(=1)"

Input M

If M=1

Goto 1

End

TEMP4 is the first (and probably the last!) program with this kind of interrogation I have written for a programmable calculator. It would seem to be quite unnecessary to go to such lengths except to illustrate an idea.

The sample programs given in the next section are not given
in various versions, although in practice educational and social
circumstances may suggest that some of the elements of programming
style would need to be carefully considered.

**Some possible uses in school mathematics
**Calculator handbooks generally show several programs
as illustrations so that calculator owners can learn to write
programs. Many, if not most, of the examples given seem not to
focus on mathematics; rather, more common applications appear
to be in the sciences, in engineering and in business. By considering
these, together with programs that I have written for my own use
in mathematics, I have made a first attempt at classification
of some possible uses for programmable calculators in mathematics
in the secondary school:

1. Situations with intrinsic repetition

2. Evaluation of complex formulae

3. Provision of missing calculator features

4. Pedagogical uses

5. Situations involving random simulation

6. Other

This is clearly not yet a very good classification scheme,
since the last category is open and since I can think of several
programs that fit quite well under more than one heading. In the
limited space of this paper, it is not possible to provide more
than a few examples to illustrate the categories.

Some mathematical tasks necessarily involve doing the
same thing over and over again, which is by definition a tedious
process. These would seem to lend themselves to short programs.
Examples include iterative solutions to equations, such as those
using the Newton-Raphson method, and the evaluation of successive
terms of a sequence, such as the following example, called SEQUENCE.

Intrinsic repetition

**SEQUENCE**

0 STO X

Lbl 1

X+1 STO X

Disp Y1

Pause

Goto 1

In this case, the definition for the sequence is first entered as a function, represented in the program and in the TI-81 as Y1. This is the same procedure normally used before graphing a function.

A program like SEQUENCE may be used in several ways to educational
advantage. For example, a young student may explore the kinds
of sequences created by linear functions, or an older student
may use the program to investigate the apparent convergence of
a sequence by looking at successive terms.

** Formula evaluation**A constant facility on a calculator will help with some
formula evaluation, such as currency exchange rate calculations
using a constant multiplication facility. More complex formulae
need a short program, such as the temperature conversion programs
above. Even rather simple formula can be evaluated efficiently
using a programmable calculator, provided that they are to be
used often. The example given here, COSRULE, uses the cosine rule
to find the size in degrees of the angle in a triangle.

**COSRULE**

Input A

Input B

Input C

(A2+B2-C2)/2AB STO X

(180/pi)cos-1X STO X

Disp X

Other examples include measurement formulae (such as that for the volume of a sphere, given its radius), geometric formulae (such as that for the angle between two lines of given slope), algebraic formula (such as that for the sum of a given number of terms of a particular arithmetic sequence) and probabilistic formulae (such as binomial probabilities).

The implications for the curriculum here are not clear. In
the last generation, we have moved from curricula that expected
formulae to be memorised and used by students, to curricula that
require students to look up appropriate formula in a book when
needed. Is this automation of the evaluation of a formula merely
a further step along the same continuum? Could we take advantage
of programmable calculators to move a little further towards the
justification, meaning and use of mathematical formulae, and a
little further away from the tedium of merely evaluating them?

** Missing features**Many calculators are missing some desirable features that
other calculators have. This will continue to be the case as technological
development proceeds. Most of these 'missing' features can be
programmed to remedy the deficiency. The following example, NEWTRPSN,
finds the roots of a function using the Newton-Raphson procedure.
The function is defined as Y1 and the starting value is X.

**NEWTRPSN**

Lbl 1

X-Y1/NDeriv(Y1,0.0001) STO R

If abs (X-R)<1E-10

Goto 2

R STO X

Goto 1

Lbl 2

Disp "ROOT AT"

Disp R

Other examples in this category might include numerical integration,
the numerical solution of equations, approximation of the cumulative
density function for the normal distribution, inversion of small
(2 x 2) matrices and operations with complex numbers. Programs
like these, unlike many others, would probably be kept in memory
for a long period, rather than being discarded after one or two
uses. As technological help of these kinds becomes readily available
to students, some aspects of the curricula will need review. For
example, to what extent should we seek to develop computational
skills in students that are easily replaced by a machine?

** Pedagogical**It is possible to write brief programs that might meet
a well-defined teaching purpose, such as allowing students to
investigate the relationships between coefficients of a quadratic
function and its graph. Such a program might be written by the
teacher and then used by her students. The example here of QUADPLOT
would not take very long for students to insert into their own
calculators, and could then be used for learning purposes.

**QUADPLOT**

"AX2+BX+C" STO Y1

Lbl 1

Input A

Input B

Input C

DispGraph

Pause

Goto 1

It would not be necessary for students to know how to write
a short program like this, since they could merely copy it from
a blackboard, and concentrate their attention on their observations.
It is not difficult to think of other programs like this one,

** Simulation experiments**Random processes can be simulated with short programs,
since most programmable calculators include a pseudo-random number
generator. The example given here, DICE, simulates the tossing
of a fair die N times.

**DICE**

Input N

1 STO K

Lbl 1

IPart (6Rand+1) STO X

Disp X

IS>(K,N)

Goto 1

Stop

Screen size is a limitation, since the output is limited to a few lines. Longer programs can be written not only to generate random data but also to aggregate the output and to analyse it statistically, but of course, longer programs are less attractive than shorter ones for practical reasons.

Programs like this one allow more opportunity for an experimental
approach to the study of chance. This would complement practical
classroom activities and more theoretical approaches to elementary
probability.

This miscellaneous category could include many examples
(which exposes a defect of the classification scheme rather starkly!).
For example, the FACTOR program finds the factors of an odd integer,
a useful tool to have if investigating aspects of primes and composites.
If the program is used repeatedly, all of the factors of a large
integer can be found.

Other

**FACTOR**

Lbl 1

1 STO D

Disp "NUMBER"

Input N

Lbl 2

If (D>ÐN)

Goto 3

D+2 STO D

If (IPart(N/D) not= N/D)

Goto 2

Disp D

N/D STO Q

Disp Q

Goto 1

Lbl 3

Disp "PRIME"

This program is longer than the previous examples, and contains no mechanisms for detecting improper input (such as an even number, a negative integer or a decimal fraction), which would have made it even longer. Such are the crudities of programming on a programmable calculator!

Similarly, programs to convert between number bases might be
useful for an investigative task.

**Conclusion
**Programmable calculators give access to a powerful
personal tool for secondary students, and there seems to be a
case for considering some ways of exploiting this. This paper
has suggested some of the possible kinds of uses that might be
examined, as well as offering a perspective on how programming
calculators may differ from programming computers. It would surprise
me if there were not some situations in which teachers would find
some of the programming possibilities of programmable calculators
useful, and worth knowing about. A number of different levels
of students use have been identified. Whether the time needed
to become proficient in programming a calculator is worth the
end result for students (or even for teachers) is still an open
question, but it is one worth thinking about and one worth studying.

Fey, J. & C. Hirsch (eds.) 1992,

Ruthven, K. 1992,

Australian Institute of Education

Murdoch University

Murdoch, Western Australia, 6150

Australia.

This paper is reprinted from:

Kissane, B. (1994). Programmable calculators and mathematics. In Graf, K-D, Malara, N., Zehavi, N. & Ziegenbalg, J. (Eds.)

Proceedings of ICME-7 Working Group 17: Technology in the service of the mathematics curriculum:Proceedings of Working Group 17 at ICME-7, Québec 1992

(pp 129-138). Berlin: Freie Universität Berlin.

[http://wwwstaff.murdoch.edu.au/~kissane/icme-7.html]