Preamble
Contents
Preamble#
How this is supposed to work#
This is a different sort of book (indeed, we’re a bit doubtful about calling it a “book”, even), intended for a different sort of course. The content is intended to be outside the normal mathematics curriculum. The book won’t teach calculus or linear algebra, for example, although it will reinforce, support, and illuminate those subjects, which we imagine you will be taking eventually (possibly even concurrently). We assume only high school mathematics to start, although we get pretty deep pretty quickly. What does this mean? We assume that you have been exposed to algebra, matrices, functions, and basic calculus (informal limits, continuity, some rules for taking derivatives and antiderivatives). We assume no prior programming knowledge. We assume you’ve met with mathematical induction. What we mostly assume is that you’re willing to take charge of your own learning. You should be prepared to actually do things as you read. There are activities to do, ranging from simple (with reports on what we did, in the “reports section,” so you have more models of the process) through hard, namely projects that can be done by teams (and if you answer them, you could contribute a chapter to this book, maybe), and some actually open. If you answer one of those, you should publish a paper in a journal. Maple Transactions might be a good place.
Students taking this course have solved some of these (formerly) open problems. You might solve others. (Yes, that’s scary.)
The example computer scripts in this book will help students to teach themselves how to use computer algebra systems to explore mathematical concepts on their own or in teams.
One of the anonymous reviewers of an early draft of this book thought that the material might do very well for Math Circles and indeed it might; we didn’t think of that, but we would love to hear from you if you successfully do use anything from here for a Math Circle.
Keep Good Notes! If you make a discovery worth publishing, you’ll need to write it up so it can be reproduced. Getting your programs to be so clean that they work, reliably, and reproducibly, is also critical. Checkpoint your computations, for instance!
Evaluation methods#
We did not use exams at Western for this course. For a subsequent course on numerical computation (which used Matlab) we did have exams, including the midterm where everyone had to use Matlab for the exam. That was even more stressful than a normal exam, but we had mitigating strategies in place for that. But for this course, we used projects. The course was a “Designated Essay Course”; at Western, Science students need a certain amount of essay credits to graduate. This worked well because both the programs and the reports require writing skills. Indeed we contend that writing a good program requires many of the same skills that writing a good essay does: clarity, precision, organization, and attention to detail.
We also used peer evaluation in part. Students had to give an interim report to the class on the status of their project, and before that had to describe what they hoped their project would be. The other students gave marks on those presentations, which were blended with the instructor’s marking because students can be too critical of their own work. But the bulk of the marks were for the final presentation and the final written report, which was typically about ten or twenty pages including all the diagrams (or in one case a few 3D printed mathematical objects).
The most important phrase in Science is not “Eureka!” but rather, “That’s weird…”
—Anonymous
The Only Difference Between Screwing Around and Science Is Writing It Down.
—Mythbusters
Guidance for the Instructor#
Let go! Trust the students. Let them work together. Let them choose examples to work on. This was especially successful for us in the “Fractals” segment. Allow them to program in pairs, and occasionally move/swap one partner in each team and make them explain their code to each other. We did this with explorations from the paper Strange series and high precision fraud and it was a highlight that year. Encourage active learning. One day, we allowed only questions, no answers, and everyone had to contribute a question. Allow them to do projects of their own choosing. Use peer assessment. Consult the students as to future content—the chapters in this book are models and templates, not prescriptions. Don’t try to prove things (unless the students express serious doubt). Programming largely plays the same developmental role as proof: it requires precisionist-grade thinking, which the students will have quite enough trouble with: it’s inhuman to have to match parentheses, or to remember exactly what they called the variable on the previous page. But using mathematical induction to prove a program correct fits well with the scope of the course, as we envisage it.
RMC found it hard to refrain from solving the problems for the students. Some coding, especially at the start of the course, is okay; and the students need to feel that the instructor “knows what’s on the next page”, (mostly) although they got quite excited when RMC said he didn’t know, or that nobody knows.
Guidance for the Student: How to ask your own questions#
What makes a question a “good” question? Ironically, that’s actually hard to answer. We can point to examples: the fabulous book of Pólya and Szegő is nothing but a collection of good questions. Pólya wrote several books, containing some generically “good” questions, such as “Can you generalize this?” and “Can you find an interesting special case?” But let’s approach this in a more modest way.
Here’s a question: how do you learn to ask good questions? The answer (our answer) is practice: start asking questions, do more of them, keep going, and eventually you will learn what kind of thing works and what doesn’t. We’ll try to help with some guidance here (chiefly from the authorities mentioned above, plus some others we know), but the key is practice. Practice, practice, practice! If you ask enough bad questions then eventually a good one will slip in by accident!
It is better to ask a lot of bad questions than it is not to ask a good question. A bad question at least provides practice!
Humans are social creatures. Even mathematicians are social (yes, really). One way to know a question is good or not is if a lot of people are already asking it. Another way to know if it’s good is if no one has asked it yet—this is known as “finding blank spaces on the canvas”, and it’s both harder and riskier (socially) than asking questions that others are already asking. But this can really be worthwhile.
Asking good questions is very hard. But here is some guidance. Take it with a grain of salt.
A “good” question (mathematically speaking) is one that, when you answer it, illuminates more than just the immediate question. The answers should be like turning on a light switch in a dark room in that you should be able to see things (understand things) that you hadn’t, before.
An example of a “bad” question is “what’s the use of this?” (somewhat ironically, we ask this question frequently ourselves). The reason it’s a “bad” question is that it’s not usually effective immediately to say “I have this answer/idea, now let’s go look for a problem that this solves.”. That’s not applied mathematics, that’s math in search of applications. Sometimes this works, and works spectacularly, but it can take a very long time, perhaps centuries!
As an aside, on the applied-vs-pure front, at least one of us is very much on the “applied” side; RMC believes that quite aside from the instrumental value of using mathematics to solve real problems, the best source of mathematics is the natural world, which contains challenges greater than any human can think of unaided. But he knows that for teaching mathematics, introducing too many applications can be distracting, while introducing just one will typically appeal to only a small segment of the population: he’s heard too many times “I hate biology” or “I hate physics” or “I hate chemistry,” generally not from the same student. So for the most part we won’t talk about applications, although they creep in for the Chaos Game Representation unit because, really, they’re just too cool.
Other kinds of “bad” questions include things like “Why did the computer use Times Roman font?” (i.e. some things are just incidental, and don’t really matter). Even this judgement can be called into question—sometimes the dumb details really matter.
One of RMC’s favourite questions is “How do we know this computation is correct?” This question will get a workout, here. It’s especially important when one writes computer programs.
Sometimes, bugs in the program can lead to other interesting new bits of knowledge. Most of the time not, of course—a bug is a kind of mistake. But we can learn from mistakes, too.
Quite a good question is “can we draw a picture of this?” We’ll be doing a lot of that in this course.
What do you see?
What do you notice?
What do you wonder?
NB: those last three can be treated as a kind of “sandbag” question, unfortunately; some people seem to interpret them as “do you see what I see?”, “Can you guess what I am noticing?”, and “Well obviously you have to wonder the same things as I do about this”. That’s not at all what we mean here. Different people could quite well look at the same picture and see different things, notice different patterns, and wonder about different paths to take. In this course, all of that is good (of course, the cynical student says, you say that now, but when the rubber hits the road…). Well, we do mean it. For instance, several of the images at www.bohemianmatrices.com were created by students choosing completely unanticipated paths—paths unanticipated by us, we mean. We liked that, a lot. Anyway, let’s get back to “generic” good questions.
Here are some other examples of “generic” good questions, mostly from NJC:
What happens if we change the parameters in some way?
If this works for the reals, can we make it work for the rationals? (NJC’s favourite example here is “continuity”!)
What happens mod 2?
Is there a better way to visualize this?
When the program breaks (on the extreme cases), why does it break?
Is this the best algorithm we can find?
Can we prove it?
Can we formulate a conjecture?
Can we formulate a good conjecture?
Can we tell if the conjecture was “good” or not?
How could we test the conjecture?
Don’t blow all your data on generating your conjecture.
—J. M. Borwein
If we can’t solve this question, can we change it to a question that we can answer? And then can that help us answer the original question?
If the problem is continuous, can we solve the discrete analogue? (Is there a discrete analogue?)
If the problem is discrete, can we solve the continuous analogue? (Is there a continuous analogue?)
What happens if we take \(n=1/2\)? (for a discrete problem)
What happens as \(n \to \infty\)? as \(n\to 0\)? When \(n < 0\)? When \(n \in \mathbb{C}\)?
Can you solve the first few cases and guess a pattern? (This is kind of our “go-to” modus operandi)
Can you write a program to solve larger cases? (This is a very significant step)
If there is a structure to the data, can you find a way to explain that structure?
Why are we not seeing what we expected to see in this picture?
If we generate an object “at random”, how does it behave?
Does this look like a random process?
There are many, many other questions of this sort and many, many other sorts of questions.