I believe that any "1D" math (which I prefer to think of as textual input) is equivalent to its "2D" counterpart (which I prefer to think of as typeset input). Of course, I have not tested each and every instance of this in the whole of AEM, so this is a conjecture on my part, based on feedback and information from the developers of typeset math notation.

There are many places where typeset math as input is easier to read. For example, I find reading a raised exponent easier than reading syntax such as x^2. On the other hand, there are lines of Maple code in the AEM book that lean toward "programming" and it's not at all a generally accepted position that typeset math is appropriate for coding.

So much for the pro & con on whether the ebook should have all its "red code" simply changed to typeset "black code."

The bigger issue is whether or not the format of the ebook is optimal. Apparently, there's some voices being raised to the contrary. No doubt, Maplesoft has, in the years since the AEM book was first written, developed many new features in Maple itself that would all for a different paradigm in an ebook. I'll be retiring at the end of the year and meanwhile, I'm contemplating a complete rewrite of the ebook to take into account the new tools available in Maple.

But for now, let me just point out a few details of the evolution of the text and its ebook form. The materials grew from worksheets written in the early '90s for use in my classes at RHIT. These worksheets were exported to LaTex, massaged so that the obvious Maple was removed, and given to Addison Wesley as the deliverable for the text. The worksheets themselves went into the back of the book on a disk. When the text went out of print, I got the copyright back, and at the suggestion of Maplesoft itself, morphed the worksheets that accompanied the book and upon which the book itself was built, into the ebook.

So, the worksheets in the ebook still have the flavor of their classroom roots, namely, to capture the mathematics, and to show users how to implement that mathematics in Maple. In the Maple content projects I've worked on directly for Maplesoft, I've moved in the direction of separating the presentation of mathematics from the implementation in Maple. So, for example, in the calculus study guides I've written, examples are presented in three forms. First, there's a mathematical form where no Maple appears. Then, there's a Maple version using syntax-free techniques. Finally, there's a version using Maple commands.

Would a similar separation of mathematical presentation and implementation in Maple be appropriate for AEM? I really don't know. I wouldn't mind hearing from users of AEM what they think. And for anyone who bought a copy of the ebook and was less than satisfied, I apologize for having failed. But I would appreciate hearing from anyone with suggestions for improvements that I'd like to spend my retirement making.