A calculus-with-computer experiment

D A V I D A. S M I T H

A C A L C U L U S - W I T H - C O M P U T E R E X P E R I M E N T

I. I N T R O D U C T I O N

This is a report of an experiment conducted during the academic year 1967-68 at Duke University. The experiment was carried out with freshman students in an honors-level calculus course, and consisted principally of assigning problems which were intended to be solved with the aid of a computer. Most of the students had no prior exposure to either calculus or computers. The purpose of the computer problems was to enhance the study of the concepts of the calculus, not to teach programming, numerical analysis, or applications.

In a recent article [4] on the subject of using a computer with elementary calculus, Young has suggested the two extremes for possible approaches: "to use the computer only in the places where the course at present uses numerical methods" and "to rethink the course from the beginning". He argues persuasively for the latter as an introduction to the efforts of CRICISAM, a group whose initial text materials have subsequently appeared [2]. Our project was much less ambitious, and the approach was somewhere between the extremes suggested by Young.

It is our belief that the use of the computer as a standard tool throughout the mathematics curriculum is inevitable, as is the restructuring of the curriculum to benefit most effectively from this routine use. However, we also believe that, due to the large amount of inertia in our educational systems, this change will be many years in coming. In the meantime, there will have to be many experiments tampering with the standard curriculum in a variety of ways, to gain the necessary experience to make changes wisely. We hope that this report will encourage others to try similar experiments and will also enable them to avoid some pitfalls.

II. P R O C E D U R E

Entering freshmen are selected for our honors calculus sequence on the basis of College Board scores and class rank prior to their arrival on campus. A student selected for the honors sequence has the option of entering the regular sequence if he desires. No special effort was made to select students particularly suited for the experiment beyond the usual selection of honors students.

Educational Studies in Mathematics 3 (1970) 1-11. All Rights Reserved Copyright �9 1970 by D. Reidel Publishing Company, Dordrecht-Holland

2 DAVID A. SMITH

During August, 1967, the course was planned in some detail. A text was sought which would have a sufficiently high level of rigor, would cover the appropriate material, and would at least be consistent with the aims of the course, for example, in presenting constructive proofs where possible and suggesting appropriate computer problems. The text selected was Modern University Calculus, by Bell et al. [1], hereafter referred to as MUC. This book generally meets the criteria listed above. It turned out to be very good in some respects, rather weak in others. We will not attempt to review the book here, but some of its strengths and weaknesses will appear in the remarks to follow.

A short 'Introduction to Computer Programming'* was prepared for the students. This included flow diagramming, a small subset of the FORTRAN language (arithmetic assignment statements, GO TO, IF, DO, STOP, END, WRITE, CONTINUE) and some detailed examples. Input data, subscripting, logical IF statements, and other standard features were considered unnecessary for the particular problems we intended to assign.

A detailed list of problems was prepared, along with a schedule for coordinating them with the course material and flow diagrams to de- termine their suitability in terms of the level of complexity. (Some changes were made in the list as the year progressed, but it remained basically intact.)

A graduate assistant was hired for the academic year, to hold regular office hours, to assist the students with programming problems, to run some of the problems on the computer to check feasibility and try to anticipate difficulties, and to assist in a number of ways in evaluating the experiment (record-keeping, preparation of a questionnaire, etc.).

The students were informed at the beginning of the course of the nature of the experiment and the way in which the computer problems would be grafted on to an otherwise complete honors-level course. It was decided before the course began that these problems would not be a required part of the course, in order to avoid having the students spend inordinate amounts of time on programming and debugging, at the expense of learning mathematics. We hoped that the combination of student interest in the computer, relative simplicity of the problems, natural tie-in with the course material, ready access to all the help they needed, and occasional pep-talks, would be sufficient stimuli for most of the students to do most of the problems, and without spending large amounts of time on them. The results showed that this hope was too optimistic.

At the third meeting of the class the instructions for programming were handed out. The students were also provided with detailed written instruc-

* Copies are available from the author on request.

A C A L C U L U S - W I T H - C O M P U T E R EXPERIMENT 3

tions from the Computation Center for getting cards punched, submitting and picking up program decks, etc. The fourth and fifth class meetings were devoted to programming and the mechanics of getting programs run on the computer. From time to time, specific difficulties encountered with the computer problems or the mechanics of running them were discussed briefly in class, like any other homework problems.

When the experiment was conceived, we had planned to make use of the WATFOR system of FORTRAN programming on the newly-installed IBM 360/Model 75 at Triangle Universities Computation Center, which is con- nected by telephone lines to a 360/Model 30 on the Duke campus. However, technical problems which had not been resolved as of September, 1967, forced us to use the FORTRAN compiler available on the Model 30 instead, to avoid rather long turnaround times. Thus we did not have access to the excel- lent diagnostics, free-form input-output, or other useful features of WATFOR.

At the end of the academic year, each student was asked to fill in a questionnaire with questions ranging over all aspects of the experiment. There was a wide variation in the answers to most of the questions, but our conclusions below are based in part on these responses from the students.

I l l . THE ASSIGNED PROBLEMS

The heart of the experiment was the selection of computational problems and their interaction with the course. There were 14 such problems assigned throughout the year at times coordinated with the pace of the lectures. We give here a brief description of each problem and its intended relationship to the course.

Problem I: Compute x/2 by successively averaging x and 2/x, starting with x = 1, printing successive iterates.

This was related to material on the real number system in two ways: (1) x/2 was the only number they knew for sure that was not rational; (2) they learned that all numbers in a computer (indeed, in actual com-

putation) are rational, that approximation by rationals is important for practical purposes and possible because of density, but that real numbers are important for theoretical purposes. The problem is also useful as an easy, but not trivial, first program to put on the computer.

Problem II: Tabulate x/x for x from I to 10, in steps of 0.1, using the same method as in Problem I, but suppressing intermediate printout.

This was intended to be a first example of a familiar function in tabulated form. Most students have seen square root tables, and at this point they can make their own. The problem also escalates the level of the programming slightly.

4 D A V I D A. S M I T H

Problem 111." This problem is quoted from MUC, p. 136: "Suppose that when x hours per day are devoted to a certain manufacturing process, the profit per dollar invested, f (x), is given by

f ( x ) = - 26/(x + 2) - (x/6) s + x + 13.

For example, labor costs might skyrocket if too many hours are put in; other processes might have to shut down which would cost money, etc. Find an expression 6o > 0, depending on e and the above formula forf(x) (but not on the values x and x0 which lie between 0 and 24), such that

[ x - x0[ ~< f i o ~ l f ( x ) - f(xo)l ~< e.

... Find a value v such that for all x between 0 and 24

[0~<y~<24 and l y - v l ~ < f o ] = : ' f ( Y ) > ~ f ( x ) - 2 ~

with.., e = .1". That is, maximize a function by finding a modulus of uniform continmty

and computing a finite number of evenly spaced values of the function. This problem occurs in an early chapter of MUC, right after a discussion of the number system, and before the chapter on functions. We judged this timing to be incorrect and deferred this chapter until after discussing functions. The subject of the chapter is a computational approach to e's and 6's, viewed in terms of error analysis or control of inputs to produce desired outputs. It was our opinion that this chapter was very helpful in making e-6 computations (with specific numbers) routine and familiar before the more abstract treatment of limits, continuity, and uniform continuity.

We considered Problem Ill to be a useful problem to illustrate how the concept of uniform continuity could be utilized to reduce the problem of maximizing a function to a finite problem, within the reach of a computer but not of hand computation. It also offered a useful contrast to the later use of the derivative.

From the students' point of view, the idea of selecting the largest in a list of numbers was a big jump in programming sophistication, even though a substantial hint was given. Most of the ones who completed the problem found out by graphing the function that it increased to an absolute maximum, then decreased, and used this to simplify the program.

Problem IV: Find the positive root of the function in Problem III, by interval-halving. This would be the break-even point, beyond which the manufacturer would actually lose money by devoting more hours to the manufacturing process.

In MUC, the Intermediate Value Theorem, in the form of a continuous function with both positive and negative values having a root, is proved


constructively by interval-halving. Thus it is natural to demonstrate at this point that the method of proof is also a practical computational technique. Curiously, MUC does not contain such a problem at this point. (There is a much later section on root-finding.) The programming problem was simpli- fied somewhat by using the fact that this particular function is decreasing in the vicinity of the root.

Problem V: Approximate S~ ( x2-1/x) dx by computing lower sums, upper sums, and their average, for regular partitions of 10, 100, and 1000 subintervals. (The students were also asked to give theoretical bounds on the error in each case, and to compare these with the true error, given the value of the integral to 5 places.)

MUC treats the integral before the derivative. We don't have strong feelings about this, but slightly prefer the other order for pedagogical reasons. However, we agree with the authors of the CRICISAM text [2] that in a thoroughly computer-oriented course it is most natural to consider sequences and the integral before taking up differentiation.

Given access to a computer, we consider it silly to devote substantial amounts of class time to deriving summation formulas so that one may integrate x and x 2 and thereby illustrate the definition. It is doubtful that these hand computations are ever really appreciated by students, since they are more complicated than the definition they are to illustrate, and the results (especially the area of a triangle) are essentially trivial.

Accumulated round-off error was mentioned briefly in class later, in con- nection with the trapezoidal rule and Simpson's rule. Allowing the students to discover it at this point, but not commenting on it, was intentional.

Problem VI: Repeat Problem V, using the trapezoidal rule with 10, 100, and 1000 subintervals.

The function in Problem V was selected to be increasing to make the computation of upper and lower sums easy. But since this is the case, the trapezoidal approximation agrees with the average of the upper and lower sums. This was not pointed out to the students until later.

One of the curious omissions in MUC is that there is no mention of any method of numerical integration except those in Problem V. In [2], the trapezoidal rule (without error estimate) is introduced very early. In a later chapter on integration techniques, the error estimate for the trapezoidal rule is derived, Simpson's rule is introduced, and the error bound for it stated without proof.

Problem VII: Tabulate the reciprocal function from 2 to 10 at values close enough to each other to read off the reciprocal of any number in [2, 10] to within .01, without interpolation.

The subject of moduli of uniform continuity was revived at this point as an


application of the derivative, i.e., using a bound on the derivative to simplify the computation of the modulus.

Problem VIII." Compute the maxima and minima of . f ( x )=l /x+3x6+ + x 5 - 10x, fiao ~<x~< 5, using either interval-halving or Newton's method to

solve f ' ( x ) =0. MUC uses this function as an example (p. 373) to show that the theoretical

solution of the max/rain problem may get snarled on the practical problem of finding the roots of the derivative. One method of root-finding had already been introduced, and Newton's method was taken up at this point as an application of the derivative.

Because this problem was somewhat difficult, an alternate problem was suggested: compute a cube root table to go with the square root table of Problem II. This involved using Newton's method to derive the appropriate cube root formula.

Problem IX: Use the trapezoidal rule to tabulate the log function from the integral definition.

The integral definition of the logarithm is, of course, based on the Fun- damental Theorem. The error estimate for the trapezoidal rule was derived as an application of the Fundamental Theorem, so it was natural to combine these two things at this point. It was in conjunction with this problem that the need to make a reasonable guess about how many subintervals to use was pointed out in class, and the error estimate can be used for this purpose.

Problem X: Same as Problem IX, but using Simpson's rule. The Mean Value Theorem is treated very late in MUC, and the only

applications of it to the subject matter indicated thus far are the error analysis of Newton's method and a refinement of the error analysis of the differen- tial approximation. (We were not particularly happy with this late appearance of the Mean Value Theorem, but the treatment of max]rain avoiding it is of interest in its own right; see p. 349 of MUC for an explanation.) We derived Simpson's rule as a follow-up to the trapezoidal rule, and derived the error estimate as an application of the Mean Value Theorem.

In [2], the Mean Value Theorem appears as early as possible, namely, shortly after the derivative has been introduced, and it is used extensively thereafter.

Problem XI: Compute e by solving logx-1 =0 by Newton's method, using Simpson's rule to compute logx. (This is essentially a problem in MUC, p. 450; the authors suggest using a "good" scheme for numerical integration, but they haven't included any in the text.)

Problem XII: Compute an arc length, using numerical integration. Problem XIII: Compute 7z to within .002 using numerical integration and a

scheme suggested by a problem in MUC, p. 548: Find a number b < 1 such

A C A L C U L U S - W I T H - C O M P U T E R E X P E R I M E N T 7

that b

dt zc x / l _ t z 2 ~<'001"

o

The method for doing this is outlined in the answer book. Problem X I V : Tabulate a function using a Taylor polynomial approxi-

mation, indicating a bound on the errors.

IV. R E S U L T S

Of the 23 students who began the course, only 17 participated in the experiment. Most of these did relatively few of the problems, for a number of reasons which we shall indicate.

Only one student completed substantially more than half the problems, and he was the only one who became enthused about the opportunity to use the computer, in the way we had na'/vely hoped most of the students would. He had no previous exposure to computers, and was not taking our programming course, but he went beyond the assigned problems, experimenting with output formats, double precision arithmetic, and other features not mentioned in class, and sought out reference materials to learn as much as he could about the computer. We were able to observe with this student that he also benefited mathematically from the experience. We were unable to be confident of this with respect to any of the other students, except for the contribution of Problem III and the corresponding chapter in MUC which, as we have already indicated, did contribute to their understanding of the 8-6 concept.

In contrast to the one student who needed no prodding to do the computer problems, one of the brightest students in the class commented that she would have got a lot more out of the problems if they had been required, because then she would have made time to do them. Some of our best students are experts at completing (required and graded) assignments, on time, and in detailed compliance with instructions. (This statement obviously has more general application than just the subject at hand.) Some compromise between these two points of view appears to be necessary, and several of the students suggested that some fraction of the assigned problems (ranging from about �89 to a z) should be required, with the choice of which ones to complete left to the student, and possibly with flow-diagrams required for some others. We are in general agreement with this suggestion, but the question of a reasonable amount of assigned work depends very heavily on time considerations such as the other requirements of the course, the student's

8 DAVID A. SMITH

total load, and, perhaps most important, the time required to get something in and out of the computing laboratory.

Some of our students had difficulty getting started with the amount of programming instruction given. Their comments on the preparation covered the entire spectrum from 'definitely not adequate' to 'very adequate', with the overall opinion evenly split.

Some students complained that the handout or the lectures should have included a fully worked-out example (each did), others that they had to learn a lot on their own (which was intended). This is one area where an in-class terminal to the computer could be very helpful. An example which included the actual computer run (possibly with some debugging) would be less likely to be forgotten.

With the very first problem we learned that the absolute value function should have been included in the subset of FORTRAN included in the programming handout. A few students figured out how to avoid its use and thereby learned something. However, its absence created a good deal of confusion, and the notes were supplemented to this extent in class.

In addition to the voluntary nature of the assigned problems and the minimal preparation, and more important than either of these aspects, the productivity of the students was adversely affected by technical problems over which we had little control. Some of these problems are strictly local, but every computer user has experienced the gap between promised and performed computing services, particularly in the early life of a new computing system.

We have already noted the compromise of accepting a less-than-ideal compiler in order to achieve satisfactory turnaround times. Actual turnaround times ranged from 10 minutes (late at night, when the computer was not in use for other things) to several days, and in some instances, more than a week.

Because of the normally heavy keypunching load in the lab, this service could not be provided on a while-you-wait basis, and the students could not be given an accurate prediction of day and time of completion. Most of the students decided early that they would have to punch their own program decks. This is time-consuming in itself for students with little keypunching experience; it produced more failed runs for grammatical errors; and it sometimes resulted in long lines waiting for the few available keypunch ma- chines.

The use of the computer itself also produced some time-consuming problems. Students complained that the time of completion of jobs was consistently underestimated, so that two or three separate trips to the lab might be necessary to get the results of a single run. It was clearly desirable


for the students to utilize the late-night hours for rapid turnaround, but travelling between campuses late at night was inconvenient and of question- able safety for the girls.

A further aspect of inconvenience was due to the fact that the office of the graduate assistant was not in the same building as the computer, and his normal hours differed considerably from the optimal time for use of the computer.

We had hoped that the programming of the assigned problems would be so simple that the solution would typically be obtained with from one to three runs per problem, and that this would be possible within about two days of having written the program. Some of the reasons why this hope was too optimistic have just been indicated, but there are others. We overesti- mated the students' abilities to catch on quickly to programming, especially to appreciate the absolute necessity of compliance with the grammatical rules of the language. FORTRAN is not ideally suited to the kinds of things we wanted to accomplish, but it was what we had to work with. We had not counted on a high incidence of keypunching errors, which resulted from causes mentioned above. Error diagnostics in the FORTRAN system used were inadequate for students with this little preparation. (One student described most of his debugging as guesswork after receiving a coded 'exponent underflow' message for virtually every error.)

V. C O N C L U S I O N S

Here we summarize some of our conclusions and add a few observations about the experiment. These conclusions are admittedly influenced by opinions we held prior to the experiment, at least those that were not subsequently shattered.

(a) The particular problems outlined above form a reasonable, and for the most part useful, set of supplementary computer exercises for a course of this sort. The problems assigned in any such course should be tailored to the content and pace of the course itself. Where necessary, the students should be guided carefully through the solutions of the harder problems. At this level, they should be shielded from, not confused by, significant problems of numerical analysis.

(b) With a few exceptions, freshmen are not sufficiently well-motivated to work hard at optional extra material solely for what they can learn from it, particularly if a significant amount of time is involved. Our reward system, of course, does not encourage such motivation. Consequently, in order to assure that most of the students complete enough computer problems to benefit from the experience, some portion of the assigned work should be


required and made a part of the grade. This requires that the instructor makes a careful evaluation in advance of whether the solution of such problems is sufficiently important to replace other required parts of a calculus course.

(c) The type and quantity of preparation given the students was barely adequate. For this type course, we would not recommend more lecture time or more extensive notes devoted to programming as such, but rather sup- plement this sort of preparation with the requirement indicated in (b), with demonstrations on an in-class terminal, with an orientation tour of the computing facilities, and with better access to personal assistance with problems as soon as they arise.

(d) At a number of places in the course, a classroom terminal to the computer would have been extremely useful and highly desirable. We have already mentioned a demonstration to accompany the lecture on programming. It could also be used to deal with difficulties brought up in class concerning the assigned computer problems and to illustrate various points in the calculus lectures not directly related to assigned problems.

(e) Easier access to the computer and consistently fast turnaround time are essential to real success with a project of this sort. In this regard, we heartily endorse the recommendations of Walker [3] with regard to programming languages and computing service for undergraduates.

(f) The personal assistance provided the students, whether by programming consultants attached to the Computation Center or by a graduate assistant attached to the course, should be available at the time and place in which the student is actually communicating with the computer. Of course, this can be arranged most easily by having a lab period, but this limits flexibility in some other respects. Alternatively, there might be periods of time during the week when student work would have high (even sole) priority on the computer, and these would also be the times when assistance would be most readily available.

(g) Our graduate assistant has suggested, on the basis of other experience, that an alternative to the digital computer for in-class use might be one of the 'new generation' of programmable electronic calculators, which can handle the types of problems described above.

Finally, our overall judgement of the experiment is that it was a partial success: with respect to the principal goal of using numerical computations to enhance the study of the calculus, we observed some solid indications that this goal is reasonable and desirable. A partial success is also a partial failure: we failed, most importantly, to get the students to complete an adequate amount of work on the computer to be very confident of our conclusions or for them to get the maximum benefit from the experience. Further- more, the experiment generated more interest in computers and program-

A CALCULUS-WITH-COMPUTER EXPERIMENT 11

ming than in calculus. This is not surprising, and perhaps is inevitable, but we feel that the relatively small contribution it actually made to the students' understanding of calculus is also tied to the low volume of output.

ACKNOWLEDGEMENTS

Support for the planning phase of this project and the salary for the graduate assistant were provided by a grant from the IBM Corporation. Computing time and services were provided by the Duke University Computation Center, which is supported in part by the National Science Foundation.

The author wishes to thank Professors F. J. Murray and T. M. Gallie, Jr., for their advice, assistance, and encouragement during this project.

Duke University, Durham, N.C.

BIBLIOGRAPHY

[1] S. Bell, J.R. Blum, J.V. Lewis, and .l. Rosenblatt, Modern University Calculus, Holden-Day, San Francisco, 1966.

[2] Warren Stenberg, R.J. Walker et al., Calculus- A Computer Oriented Approach (preliminary edition), Center for Research in College Instruction of Science and Mathematics (CRICISAM), Tallahassee 1968.

[3] R.J. Walker, 'Student Use of a Computer', Educational Studies in Mathematics 1 (1968), 111-117.

[4] Gail Young, 'The Computer and the Calculus', Educational Studies in Mathematics 1 (1968), 105-110.

Documents

A calculus-with-computer experiment