The changing face of Mathcad
Was someone at PTC listening to Jack when they created Mathcad Prime 1.0?
Editor's note: Due to unforeseeable circumstances (including a sick computer), Jack Crenshaw will finish writing about the Kalman filter in upcoming months. Stay tuned.
|Click image to go to digital edition.|
Regular readers know that most of my columns are math-oriented, as is most of my work. For that reason, I'm a heavy user of Mathcad. For more than 15 years, I've maintained a love-hate relationship with Mathcad. I've mentioned it many times in my columns, in terms ranging from wholehearted endorsements to heated, curmudgeonly rants. Although I often curse Mathcad as I use it, the reality is it remains, by far, the most oft-used tool in my toolbox.
Why do I continue to use Mathcad when it frustrates me so? To quote the old joke, it's the only game in town. Oh, yes, other math-analysis tools exist—some with more impressive resumes, more respected pedigrees, and much higher prices. But none of them do quite what I want done. For me, Mathcad stands alone. The reasons are part of this story.
I've not told just you readers my beefs about Mathcad. I've also communicated them to Mathsoft and now PTC. I've talked to people from technical support—very excellent people, by the way—to vice presidents. I've posted my opinions on their web sites and blogs. I was a long-time member of their "Power Users' Group," and I still post from time to time in the Mathcad Community site. I've given them so much "feedback," I think they must surely cringe when they hear my cybernetic footsteps.
Do you get the idea that I am not among Mathcad's biggest fans? Then what I have to tell you next should carry all the more weight.
PTC has recently announced a new version of Mathcad. It's called Mathcad Prime 1.0, and it represents a bold and dramatic departure from older versions.
No, belay that. Prime 1.0 isn't just yet another version, the 16th of 16. It's a brand new product, written on a blank sheet of paper and built from scratch to new specifications. You have to admire the courage of a company willing to invest the time and money in these precarious times.
More importantly for me, the user interface—the part that elicited most of my rants—is radically new. I don't deceive myself that PTC made the changes just for me, but it's as though they were reading my mail (hey, maybe they were). As near as I can tell, every one of the idiosyncrasies I used to fuss about has not just been changed, but changed in just the way I'd hoped for, It's an awesome turn of events, and I'm very excited about it. Can you tell?
The back story
What is a math aid, anyhow? Well, it's something that makes doing math easier. Until the advent of digital computers, we all used to do math the same way the Sumerians and Egyptians did it: First with stylus and clay, then quill and papyrus, later pencil and paper. What alternatives did we have?
When you're doing long math calculations, it's easy to get something wrong. The great astronomer, Ernest William Brown, developed a theory for the motion of the Moon, in terms of a trigonometric series with some 1,500 terms. Later, it was discovered that he'd made an error in the 500th term, give or take, rendering the next 1,000 terms useless.
My own favorite errors were stupid ones; getting a sign wrong, or leaving out a factor of 2. I often wished I could hire an apprentice, whose only job would be to check my math and catch those errors. Or, better yet, do the tedious, turn-the-crank manipulations for me. Just say, "start with these equations, and solve for x." The ideal apprentice would know the rules of algebra, trig, and calculus.
Such an idea became practical with the advent of digital computers. Computers don't just crunch numbers. They can also deal with concepts. The rules of algebra, operator precedence, and so forth, are well known and never change. Ditto for the rules of calculus and trig identities. If we can explain the rules, a computer program can do all the tedious work. And it won't get the sign wrong.
One of the earliest math analysis tools was Macsyma, developed at MIT and refined in various commercial forms. Versions of Macsyma, highly refined, are still with us today.
You must understand: in those days, the acronym WYSIWYG wasn't even on the radar. We gave computers data by punching text into IBM cards or paper tape, and they gave stuff back by printing them on a chain printer (very fast, very loud). In a real sense, a computer program only changed one text string to another. There was no hope to input formulas as they'd look in a math textbook. If you wanted to write an equation like the quadratic formula:
You had to convert it to its equivalent Fortran form:
X1 = (-B + SQRT(B**2 - 4*A*C)/(2*A) X2 = (-B - SQRT(B**2 - 4*A*C)/(2*A)
Macsyma's forte' was symbolic processing. That is, it could take an expression and transform it into an equivalent one, using the rules of algebra, trig, and calculus. Macsyma was, in fact, one of the very first knowledge-based systems. But it could only operate on Fortran inputs, and it could only give back more of the same. One of its most important applications was in taking the calculus derivatives of expressions.
I once got to see Macsyma used—or misused. A company building robotics controllers was writing new embedded software, and they needed to implement the rather complicated vector/matrix math and Euler angle rotations. The project lead had a most boneheaded idea. Arguing that calling functions and subroutines would be "too inefficient," he decided to get Macsyma to expand them all into scalar equations involving a whole lot of trig functions. He chose Macsyma to expand the equations into Fortran. Pages and pages of it. Then he turned the Fortran over to a bunch of new-hire programmers, trained in C. Their job: To turn the Fortran into yet another language: Pascal. Think that was efficient?
Most computer programs don't yet have the intelligence to say, "You want me to do WHAT?"
Maple and friends
The folks at Waterloo University in Waterloo, Ontario, Canada enjoy a long and honored reputation in the fields of language translation and symbolic computations. In the 1960s, computer science departments all over the world were hurting because of all the students running Fortran jobs for class credit. What the world needed, the educators pleaded, was a Fortran compiler system that would read the students' programs, compile, link, and run them, all in one batch process. IBM experts said building such a system was impractical, if not impossible.
Someone forgot to tell the folks at Waterloo, so they just went and built it. They called it Watfor.
A similar situation came up around 1980. The story goes that the Waterloo folks wanted to run Macsyma, but couldn't afford the large mainframe computer it required. So they wrote a symbolic engine of their own. They called it Maple. Over the years, Maple has continued to evolve and is generally considered to be one of the premier symbolic engines of all time. It's commercially available today, from Maplesoft.
The printed page
While we technical types were learning to computerize the processing of math equations, another group had been routinely creating more beautiful equations for centuries. These were the book publishers, who published, among other things, the math textbooks from which we learned our craft. It was only natural that typesetting systems evolved into computer systems capable of driving automated typesetting machinery.
Generating print for textbooks is one thing. For a single scientist or small group, generating it for published papers was quite another. I well remember serious technical papers written on a typewriter, with all the math equations written by hand. Or, not much better, generated by a typist skilled in typing subscripts, superscripts, and Greek letters. It was only natural that we average computer users would yearn to be able to generate book-quality print and equations, from a computer. In other words, let the text output of a general-purpose computer be the text input to a typesetting system. One of the early typesetting systems was the Unix program, troff. Another was Donald Knuth's justly famous TEX, developed ca. 1980. To see the quadratic formula written in TEX, go to http://en.wikipedia.org/wiki/TeX.
The problem with troff and TEX was that you couldn't actually see their output until it went to the typesetter or a pixel-capable printer. The input itself was still a mere text string.
WYSIWYG changes everything
All that changed when Apple introduced its ground-breaking MacIntosh computer, with its high-resolution pixel graphics and a laser printer to match. Suddenly, an affordable personal computer could generate output rivaling the book publishers.
Seemingly the next day, Microsoft came out with Word for the Mac, and we learned that we no longer had to deal with Courier-in, Courier-out text. We could see on the screen the printed page exactly as it would appear. WYSIWYG was upon us with a vengeance, and we'd never be satisfied with pure text editing again.
If we could create text and graphics on a personal computer, it was only natural that we'd want to create math equations as well. Microsoft came through again, with its Microsoft Equation Editor, based on Design Sciences very excellent MathType. It's Word with MathType that I use for all my columns you've seen.
Tying things together
As nice as the output of WYSIWYG editors with equation editing was, it was still completely dumb. Mathtype, like troff and TEX, has no smarts behind it. You have to put the symbols where you want them, one by one. Symbolic math processing remained a largely text-only operation. Math aids like MacSyma, Maple, and Mathematica (loosely derived from MacSyma) still used ordinary text strings for input and output. Mathematica at least made an attempt to pretty-print math equations, by simply printing their parts on separate lines. But the results were a far cry from book-publishable.
The next step is obvious: Give me a math analysis program that lets me input my equations in a form that looks just like a book publisher might typeset it, and give me the results the same way.
This is where Mathcad comes in. To my knowledge, it was the very first personal computer program capable of accepting symbolic inputs in natural mathematical form, performing operations on them symbolically, and showing the results in the same form. As far as I'm concern, they still remain alone.
In fairness, Maple too has evolved over the years, and later versions do indeed support mathematical forms for both inputs and outputs. But, for me at least, the text-oriented nature underpinning Maple still shows through. The math expressions are basically sleight-of-hand tricks to hide its inherent nature.
A lot of my work involves deriving the math equations associated with new problems and documenting the results. For me, it's important that I be able to intermix text with math equations, as well as the numerical and symbolic computations associated with them. Only Mathcad can do this seamlessly.
Which is why I use it.
How hard can it be?
While the ability to input equations in WYSIWYG form is Mathcad's strength, you should never get the idea that it's easy to do. It's not, and that's because the most convenient input device remains the keyboard. So how do you get the computer to accept text inputs and display the equivalent WYSIWYG form? Granted, I should be able to type a "Fortranish" character string like:
"x = a+b+2*y"
x=a+b+2 • y (2)
But try to get fancier, and things start to go south in a hurry. Type the harmonic series:
"x = 1+1/2+1/3+1/4+…"
And you might be surprised by the result. It'll be:
Mathcad understands operator precedence but can't possibly know your intentions unless you tell it. Think about it for awhile, and you'll realize that you can't possibly avoid the need to navigate around inside an equation, selecting the place where you want to put the next symbol. To do it, you're going to need to use the navigation keys, plus some special keys for things like superscripts, subscripts, square root symbols, matrix operations, and the like.
It's this navigation that's the hard part. It gets even harder when you're not just inputting an expression from scratch, but modifying an existing one. Or, worse yet, editing the output of the symbolic processor. Over the years, the Mathcad folks have tried several schemes, each with their pros and cons.
This is the big area of change in Mathcad Prime 1.0. They've completely replaced the user interface, including the rules for navigating inside expressions. It's the area of the program that elicited by far my most vociferous comments and under-the-breath curses. And the new interface is exactly what I had hoped for. It's a dramatic change, and it's the reason I'm so excited about Mathcad 1.0 Prime.
Now for the bad news: Mathcad Prime 1.0 is still not complete. In developing it, PTC decided—wisely, in my opinion—not to put things in until they were robust and fully refactored. So key parts of earlier versions are still missing, notably the symbolic processing.
What's that you say? A symbolic processing program that can't do symbolic processing? Well, don't forget that symbolics is far from Mathcad's only function. It can also do ordinary numerical computations, vector/matrix operations, graphing, and much more, just as Mathematica, Maple, Matlab, and others do. Plus a bewildering array of special functions and numerical methods. It's only the connection with the symbolic engine that's missing.
To complete the picture, PTC has a plan. First, the purchase price of Prime 1.0 includes a maintenance contract, providing free upgrades for a year. They expect that, long before the year is out, the missing features will be included. To cover the missing features in the interim, they're bundling Prime 1.0 with a new version, Version 15, of the old Mathcad.
Can you tell that I'm excited? I think it's a great plan, and a great product. If you have a need for math processing, I think you should take a hard look at Mathcad Prime 1.0. If you've been avoiding Mathcad because of its steep learning curve or my dire warnings, it's time to take another look.
Jack Crenshaw is a systems engineer and the author of Math Toolkit for Real-Time Programming. He holds a PhD in physics from Auburn University. E-mail him at firstname.lastname@example.org.