Instead of grading, I have spent far too much time reading “Understanding Maple”. Overall, I like it quite a bit, so much I plan to assign it in some of my courses. There are many features of it that will serve the science, technology, engineering and mathematics instructor well.

So why the positive perspective? Firstly, it is brief which is very important. This is book that is for a course where computational techniques enhance the concepts, but do not drive them. Many students simply ignore books > 200 pages simply because the activation barrier to find something useful is overwhelming. Though this leads to an interesting pedagogical question. The text lacks a traditional index though it does possess an index by “Maple Notation”. Instead, the Table of Contents probably best serves as an index for asking that question, “How do I solve the following type of problem?” I’ll be interested in feedback by the students when I use it next year on this question.

Next, the text is laid out where I could easy assign a chapter weekly or biweekly and students wouldn’t feel their physics course has turned into a course on Maple. In describing what they liked least about my courses, “Too much Maple” comes up about 10-20% of the time. Much of this complaint feel is unwarranted, but that is for another discussion.

Chapter 2 on “Getting Started”, which really is the first chapter of content, is packed with…content. In the past, I’ve highly recommended Doug Meade’s book “Getting Started with Maple”, especially for the students in the first-year course because of it brevity. However, if anything, “Understanding Maple” is terser. Just the facts, mam. Indeed, chapters on solving equations, differential calculus and linear algebra cover the essentials. For me that is enough and should serve as a refresher to students who may have looked at Doug’s book or have worked with me during the introductory course. In the chapter on graphics, I particularly like his use of the modern command *dataplot* . This ties in nicely with the Maplesoft Webinar on the topic.

However, where this book really shines, and why I’ll be requiring the students to pony up $20 for the text, is in the last quarter where he discusses programming. I have agonized, attempted, and not have always succeeded sufficiently well enough the covering of the basic programming properties such as conditional statements, looping, procedures, etc. Most of my students possess no formal programming experience. Yes, they get it, but having it in black and white works better. Now I will simply point to those sections of the text and say, “read.” By the second year, while some of our students will have started Python, enough will not have seen the concept of a procedure. Designing a worksheet with multiple procedures is essential in solving problems the students face in introductory quantum mechanical. Indeed, by the second year, no longer do I say, “Here is an equation of 4 unknowns, I give you three of the unknowns and you solve for the other one.”

One might quibble about the choice of topics or a particular solution. For example, while assumptions are very important in science, we rarely care about limits. L’Hospital’s rule shows up so infrequently for undergradate texts, it usually used as the punch line to a joke. And while I’m not going to discuss “tables”, I will need to add an entire section of statistics. I do like the fact that Ian tends to lean toward the philosophy of greater readability over the clever solution and Maple shortcuts. For example, while it is true we can learn the definition *fi*, the phrase *end if* is so much easier to understand the first time.

However, if there is one pedagogical disagreement I have with this text is the extensive use of the “ditto operator”, %. Since the vast majority of the students I teach have completed, or will complete, a programming class, I strongly emphasis the use of assigning all outcomes to a variable, even if it is the same variable such as *zelda* := *simplify*(*zelda*) assuming *positive*. It is my experience that if you are requiring to approach problems from a programming perspective, then these problems require numerous lines of code and one can’t simply ditto one’s way through the worksheet.

I might also suggest a visible graph or two. While including plots it would increase the thickness of the book, I feel seeing the examples would provide the reader a target to shoot for.

It is clearly apparent that Ian has taught this material numerous times. I particular like the “starred” paragraphs pointing out infamous pit falls such as ‘e’ does not mean exp(1). Several of the gotchas made me laugh. As I read, I would reminise about the experiences of having to show numerous students where their code had failed for exactly those reasons he describes. More than once I bet we both said to a student, “Sorry, Maple simply isn’t sophisticated enough to read your mind.” In my view, his prose is also very easy to read; it is sophisticated without requiring a Ph.D. in English.

In short, this book is targeted to new Maple users who don’t require knowing everything, but just enough to solve 80-90% of the problems the user is going to face.

(*This text was edited for, hopefully, improved clearity. The original post we written in an American pub while enjoying a pint or two.)*