Pages: pp. 7-9

This seems like a good time to stop and catch our collective breaths during our ongoing reviews of Maple, Mathematica, and Matlab. We understand and acknowledge that we aren't experts in any one of these packages (let alone all three), but our inexperience gave us some initial objectivity and helps illustrate how experienced programmers new to these tools might realize certain implementations.

We sent our near-final drafts to representatives at Maplesoft, Wolfram Research, and Mathworks to have them check for technical correctness. Some found explicit errors, but others objected to the quality levels of our implementations. In reading and responding to this feedback, we gained some new insights into these packages' "personalities," and share some of this dialogue with you here, in the hopes that you, too, will find it instructive.

*Not sure what you mean by "In the rush to expand GUI presence, Matlab alone (as of this writing) has a specialized development environment that generates the actual code for producing GUIs." Matlab's GUI development environment has been available since 1999 and is improved at each release.*

To clarify, we were referring to the type of GUI we'd normally associate with the name—a code-free field containing such objects as clickable icons, slider controls, and text-input boxes whose actual code is hidden from users. In a broader sense, the other two packages incorporated GUIs (as opposed to command-line environments) considerably earlier than 1999. Specifically, Wolfram Research introduced its Notebook front end with Mathematica 2.0 in 1991, and Maplesoft introduced its Worksheet user interface with Maple V in the early 1990s.

We believe the earlier differences between Matlab and Mathematica/Maple in their approaches to designing user interfaces indicate the differences underlying their basic personalities. We associate the fact that all three now offer tools for creating GUIs with the convergence in their capabilities as they mature and compete for bigger market shares; this commonality belies their persistent differences.

*Not sure why you say Matlab treats matrices as "numbers." Perhaps it's because they always have values? We think of them as matrices, albeit of any dimension (1 × 1, n × m, n × m × …).*

To clarify, we might have done better to say "array of numbers." In fact, we were echoing what Matlab itself says in its self-revelatory "Getting Started" tutorial:

In MATLAB, a matrix is a rectangular array of numbers. Special meaning is sometimes attached to 1-by-1 matrices, which are scalars …

Our aim was to emphasize Matlab's recurring theme: efficient computing with numerical arrays. Similarly, we indicated that Mathematica's and Maple's treatments of matrices reveal something of their inner character: Mathematica uses the computer science-centric generic list, and Maple uses the mathematician's conventional type distinctions.

*In Figure 6, the Mathematica code applies only to a (2 × 2) matrix, not a function of *n *, as in the Maple and Matlab examples. We suggest changing the Mathematica code to*

n = 2

A = Table [ 2i + 4(j – 1), {j, n}, {i, n}] (* List construction and initial valuation*)

Thank you, Mathworks!

*[Again] in Figure 6, regarding the Matlab code, you don't need the extra square brackets. You need only one "n" to create an n × n matrix of zeros. Also, we wouldn't recommend using a For loop in Matlab for something this simple. There's usually an easier way, using Matlab's matrix-indexing features:*

n = 2;

A = reshape (2 * ( 1 : n*n ), n, n )′;

This critique dramatizes the difference between the expert and the novice. Our article included a disclaimer that we deliberately chose code examples written by skilled programmers who were novice users of these packages. Because our goal is to prepare readers to conduct their own comparative evaluations, we feel our examples should be comparable across packages and embody the same degree of comprehension (or misunderstanding) of the average nonexpert.

We sympathize with product developers who cringe when they see the results of our temerity in trying out their powerful computational systems, but we sympathize even more with the instructors who are reevaluating or contemplating adopting these packages for themselves.

*In Figure 7 … the constant 3.14159… is always lowercase "pi." (Therefore, the "boxed" response couldn't be the result of the entry on the line above it.)*

E = @ ( t ) Eo * exp( i * 2 * Pi * f * t); % function definition

E = @ ( t ) Eo * exp(i *2 * pi * f * t)

Good point; we failed to catch this mistake in the final galley. However, this error also reflects the inherent difficulty in working among multiple packages: each has its own way of expressing common entities (for example, "I" versus "i" for the imaginary identity element). This type of confusion reinforces our conclusion about the benefits of adopting a single package over as wide an institutional scope as possible. Put yourself in the place of a student taking two courses that use different packages, for example.

*In Figure 8 …, I don't understand why you chose to insert the two functions into a structure:*

combo.series = @(x, y) x+ y ; combo.parallel= @ (x, y) x * y/(x + y)

combo = series: @ (x, y) x + y parallel: @ (x, y) x * y/(x + y)R=10; Xc= 1/(2*i*pi*0.02);

combo.series (R, Xc)

ans = 10.0000 – 7.9577i

combo.parallel (R,Xc)

ans = 3.8773 – 4.87231

*These two unrelated syntaxes might confuse the reader; perhaps just have*

series = @(x, y) x + y ;

parallel= @ (x,y) x * y/(x + y);

R=10; Xc=–1/(2*i*pi*0.02);

series (R, Xc)

ans = 10.0000 – 7.9577i

parallel (R,Xc)

ans = 3.8773 + 4.87231

We used two variants of the combo function to structure the two algorithms for computing effective, combined impedances because of the (peculiar) way in which scientists and electrical engineers think about circuit connections. These two primitive operations connect circuit elements, which makes this semantic association natural for some people (the authors included). Among readers in this subset, such syntax is more likely to promote clarification than confusion (although it could well be confusing to others). It was prescient of Matlab's designers to have implemented this structural capability, which serves peculiar thinkers so well.

This exchange raises an interesting question: Does language conform to thinking, or thinking to language? Regardless of how you answer, the extent of this question's importance seems to determine the significance you assign to personality as a criterion for choosing a software package.

*Regarding Figure 7, never use delayed assignment [:=] for functions [definitions]. This means that the function body gets evaluated only when we give an argument to the function. On the other hand, for variables like Eo and f, you should use "=" (known as "Set"). Here's the code:*

(* Definitions *)

In[1]:= Eo = 20; f = 1/2; Einst[ t_] := Eo Exp[2 I Pi f t]

(* Evaluation *)

In[2]:= Einst[t]

Out[2]= 20 e ^{ π}

*Likewise in Figure 8, the code should be*

(* Definitions *)

In[1]:= seriz[z1_, z2_] := z1+z2; parallelz [ z1_, z2_] := (z1 z2)/(z1+z2)

In[2]:= R = 10; Xc = -1/(2 I Pi 0.02);

(* Evaluation *)

In[3]:= seriz[R, Xc]

Out[3]= 10+7.95775 i

In[4]:= parallelz[R, Xc]

Out[4]= 3.87727 + 4.87232 i

*In this case, there is really no need … for local variables, as the pattern variables used in the function definition are local (if you use delayed assignment).*

This is the most interesting of all the critiques we received. It came as a corrective to a draft of the article; in that version's figures, one of us (Chonacky) used Mathematica code in which the function definition used the "Set" operator (=) instead of the delayed assignment (:=) operator. Moreover, in Figure 8, we used the "Module" construct in the function definitions to illustrate encapsulation (to localize the variables "x" and "y"). The resulting functions in each case behaved just as expected for ordinary functions, but we unknowingly violated one of Mathematica's cardinal design features.

Mathematica uses a unique expression evaluator in the kernel to distinguish between pattern expressions and evaluated expressions; this is how the package simultaneously handles both symbolic and numeric quantities. This mechanism allows programmers great flexibility, which you fully appreciate if you use Mathematica as a computer scientist or software engineer would (to explore theoretical concepts or engineer software systems). Once we understood it, we also realized its value to run-of-the-mill scientists or engineers as well.

The blunder was clearly of our own making. This rule for defining functions appears clearly in the early chapters of Wolfram's *Mathematica Book*, which comes in every distribution of the product. What caused the error? We didn't read the manual—sound familiar?

We designed our review with the understanding that these multifaceted tools try to address generally similar computational needs for a variety of educators, but using significantly different approaches and embodying decidedly different personalities. It would be presumptuous, at best, for us to attempt an evaluation based on our values as a substitute for yours.

The three Ms aren't the only productivity packages of this ilk; two others, IDL ( www.rsinc.com) and Mathcad ( www.mathcad.com), are roughly comparable. We also haven't explored the many open-source software counterparts. We based our original choice of the three Ms on a wish to explore a limited number of the most-used packages supported simultaneously on all three major platforms (Macintosh, Linux, and Windows), but that still represented several different archetypes. Future Technology Reviews will hopefully remedy any shortcomings.

Norman Chonacky is currently a research fellow in the Center for UN Studies at Yale and *CiSE*'s editor in chief. Contact him at cise-editor@aip.org.

David Winch is emeritus professor of physics at Kalamazoo College. His research interests are focused on educational technologies. Contact him at winch@taosnet.com.

CITATIONS