Visualization is an invaluable companion to symbolic computation in understanding the complex plane and complex-valued functions of a complex variable. The *Presentations* application, an add-on to *Mathematica,* provides a rich set of tools for assisting such visualization. This article demonstrates some capabilities of the application, especially those relevant in an introduction to complex analysis, and it indicates some teaching and learning issues that arise. Included are examples of how complex functions map objects in the complex plane and on the Riemann sphere, and of how complex functions behave near singularities and at branch points.

### Introduction

Visualization and symbolic computation are both essential to understanding how functions behave. Visualizing the behavior of a real-valued function of a real variable is often easy because the function’s graph may be plotted in the plane—a space with just two real dimensions. On the other hand, visualizing the behavior of a complex-valued function of a complex variable is more difficult because the graph lives in a space with four real dimensions. Whereas *Mathematica* is replete with resources for symbolic computation with complex functions, out of the box it provides only a meager set of tools for visualizing such functions. To do much more than what is provided by the two-parameter form of `ParametricPlot`—the replacement for the standard add-on package Graphics`ComplexMap`—even to plot the image of a simple curve in the complex plane requires the effort of constructing the image set and its graphical representation and then combining the graphics objects. The *Presentations* application [1], written by the second author, is a purchasable add-on to *Mathematica* that provides, among many other things, a rich set of tools for plotting complex functions and some utilities for complex symbolic computation. *Presentations* includes full documentation with individual help pages and examples for each command.

*Presentations* is the successor to both the *Cardano3* [2] and *DrawGraphics* [1] applications. In a *Mathematica*-enriched introductory complex analysis course, the first author prepared demonstration and exercise notebooks for *Cardano3* [3] and experimented with students’ using it; experience there led to some enhancement of the application. The course used the textbook by Mathews and Howell [4], which is fairly traditional in approach, although it does go a bit further than some introductions in emphasizing mapping properties of complex functions. *Presentations* would be especially suitable for use with a less traditional, more visually oriented text, such as the one by Needham [5], which inspired and helped guide development of the application.

In this article we demonstrate some capabilities of the *Presentations* package *ComplexGraphics*, especially those relevant in an introduction to complex analysis. The examples include a geometric problem solved by complex means, representations of complex functions as mappings, depiction of singularities, analysis of branch points, and a visualization of the Argument Principle. Typically the examples include embellishments that might be inappropriate for a novice at both *Mathematica* and complex analysis to program, but these embellishments illustrate some of the advanced functionality of the packages.

Various graphical representations of complex functions are often needed to emphasize their various features. `DrawCartesianMap` and `DrawPolarMap` plots within `Draw2D` expressions can be used to emphasize mapping properties. Riemann sphere plots can be used to better depict behavior near the point at infinity, or to emphasize periodic behavior. `ComplexDensityDraw` and other domain-coloring plots give an overall representation of a function in the plane that emphasizes singular points and branch lines.

Representing complex values as vectors is one method for obtaining a four-dimensional picture—two dimensions in the plane and two dimensions in each vector. By moving a single vector as a `Locator` around the domain, we can see how a function varies along a path; superimposing the moving vector upon a background `ComplexPolarContour` plot of the modulus provides even further visual information. This visual information can be accompanied by panels giving dynamically changing numerical values. More generally, dynamic interactivity is especially effective in making various properties come alive. *Presentations* can give an overall picture or zoom in on particular portions of the domain. Multifunctions can be used with several of the plot types. All these techniques increase our ability to understand complex function behavior.

Top-level *Presentations* complex graphics functions ultimately call upon more general graphing routines like those in *DrawGraphics*, which is discussed in [6]; the *Presentations* graphing routines, in turn, ultimately call built-in *Mathematica* functions. To reproduce all the results in this notebook, in addition to *Mathematica* and *Presentations*, will also require Ersek’s *RootSearch* package [7].

Only some of the functionality of *Presentations* is illustrated here, even for complex functions. Visualizations of Riemann surfaces are discussed in [8]. Online resources for visualizing complex functions are available that do not involve *Mathematica* at all; see [9], for example.

This article is based upon the authors’ original paper [10] for the eighth International *Mathematica* Symposium (*IMS*‘06) that used *Cardano3.* Thanks to the advances in *Mathematica* 6 and the concomitant development of the application, the examples here go well beyond what was possible before.

### Initialization

To begin, we initialize the *Presentations* application.

To open the documentation for *Presentations* directly, evaluate the following input cell.

The function `styleText` will be used in several places to format point labels.

### Geometry in the Complex Plane

*Presentations* contains a complete set of graphics primitives that directly use complex numbers for points. Geometrical diagrams are an important part of mathematical discussions, yet students find it difficult to draw such diagrams. The power of complex algebra is that many such diagrams are more easily constructed and drawn in the complex plane. Such diagrams are not only an excellent introduction to *Presentations* and complex algebra, but also a valuable technique for mathematical work.

The problem considered here is from a posting on *MathGroup* [11] (with Greek letters used for the angle variables of the original):

The following creates a diagram for the problem.

Given a value of angle , find angles such that the blue line joining the two circled points has a length 7. To solve this problem, we simplify things by writing the *complex* equation for with as parameter.

An additional geometrical diagram (not shown) indicates that the equation for always has two roots. The roots are most easily found by using Ersek’s *RootSearch* package [7].

For example, evaluating gives the result . To show how the solutions change as varies from 0 to , we exploit the new dynamic interactivity introduced in *Mathematica* 6 as well as its ability to combine graphical and numerical information. First, the following definition calculates the two solutions with the graphics based on the solutions and returns them in a list.

The following `Manipulate` expression displays the graphics along with panels showing the values of and the corresponding two values of .

Such a dynamic presentation combining graphics and numerical data gives a superb hands-on experience of a relationship and increases confidence in the consistency of the solution method.

### Complex Functions as Mappings of the Plane

The most direct way to represent a function as a mapping is to display side by side the domain and codomain planes (or their Riemann sphere compactifications), to place in the domain some objects of interest, and to display the corresponding images of these objects under in the codomain. Usually we locate the objects with reference to some grid in the domain, and then display their images with reference to the image of that grid.

To represent such a function as a mapping with *Presentations*, we shall use two instances of `Draw2D`, the first for the domain and the second for the codomain. The function `Draw2D` is the basic construct for readily combining plots and other graphics objects without the need for using `Prolog`, `Epilog`, or `Show`.

Our first example is an affine linear function of the form .

This example is a good place to start because it is so easy to calculate directly (even with paper and pencil!) the images of lines and circles, and hence to understand the very concept of a function as a mapping—a concept that many beginners at first find difficult. The plot we are going to construct will show how a triangle and a circle upon a Cartesian grid map under . The following code just forms the objects to be plotted, but does not display them.

The function `DrawCartesianMap` produces the underlying grid for the domain plane. Note that although `DrawCartesianMap` is a two-dimensional construct, it uses only a single complex iterator where *zmin* and *zmax* delineate a rectangular region in the complex plane. This is a general feature of the complex plotting routines in *Presentations*. For polar plots the iterator would use the form of complex numbers provided by the package and would then take the form:

.

The *Presentations* functions `Legacy` and `HTML`, also used previously, provide shortcuts for colors not defined in the kernel. They could also simply be clicked from the ColorSchemes palette.

Finally, we insert the objects into two `Draw2D` expressions and combine the latter in a `Row`. In the second `Draw2D`, it is the derived function that transforms the grid along with the triangle and circle.

The plot suggests that maps lines to lines, and circles to circles; it further suggests that rotation, stretching, and translation are involved. To verify analytically that this is so, we need only write as the composite of a rotation around the origin, a dilation, and a translation. The documentation for *Presentations* illustrates the actions of rotations, dilations, and translations by means of animations in the complex plane and their lifts to the Riemann sphere.

For a novice, such a first example should surely be simpler; for example, it might involve mapping just a single line segment, foregoing labeling the points, and using default colors. Producing such a graphic may either precede the analysis, to suggest what the analysis will reveal, or else follow the analysis, to confirm visually what the analysis predicts.

The simplest nonlinear polynomial is the squaring function. Here is a naive student’s attempt to show how it maps.

The parabolic arcs shown as the images of the horizontal and vertical segments of the grid are correct, but the images of the highlighted horizontal and vertical segments are *wrong*. The student, trying to generalize from the case of affine linear mappings, had unreasonable expectations as to what the application would do.

What went wrong is this. When using `ComplexMap` to form the image of the grid itself, *Presentations* applies the target function (here ) to points along the lines of the grid and then connects the resulting image points in the codomain. For a primitive graphics object such as `ComplexLine`, however, it merely applies the function to distinguished points of the object—for `ComplexLine`, its vertices—and then forms the corresponding object in the codomain based upon the images of the distinguished points.

It was the encounter with this misunderstanding by students that led to the new *Presentations* primitive `ComplexCurve` to represent a curve in the complex plane parameterized by a real variable. The *Presentations* routines find the image of such a curve in the same way as for the lines in a grid—by sampling points along the curve, calculating their images, and then connecting the image points. The following modified curve, employing `ComplexCurve` objects, correctly represents the mapping.

Of course a rectangular grid is hardly the best way to understand how the squaring function maps. A polar grid, in this case covering a half-disk that we create first, is much better.

Then the plot produced by the following code would show that the squaring function doubles angles as it squares moduli. (The result has been suppressed.)

With *Mathematica*, and its special dynamic features, it takes little extra work to convert such a static display into a dynamic presentation. We only have to keep in mind which parameters are going to be variable or dynamic, and so it is useful to develop the initial graphics within a `Module` or `With` expression that has the parameters as local variables.

Similarly, the code could be modified to show dynamically what happens for varying powers of .

### Lifting Complex Mappings to the Riemann Sphere

Mapping properties of some complex functions may be nicely visualized by considering them as mappings of the Riemann sphere . Let be the extended complex plane, and let be the stereographic projection onto the equatorial plane, with the north pole going to the point at infinity. To visualize the map , consider the part of the closed disk in the closed first quadrant.

First, we create a double polar grid on to distinguish points inside the unit circle from points outside it and highlight parts of the boundary of .

The output from the following depicts both and its image on the Riemann sphere. Projection of the plane onto the sphere is handled by `StereographicMap`.

In the first author’s course, stereographic projection had been described geometrically. When this graphic was demonstrated, students were curious to learn how the application implemented the projection. The explicit formula for `StereographicMap` appears in the *ComplexGraphics* package code, but students could not readily ferret that out. Using the application motivated the students to discover the formula and thereby presented an opportunity for them to exercise three-dimensional vector methods.

Our final example of visualizing complex functions as mappings is the complex sine. The following shows how maps a square grid in the plane, with the image lifted to the Riemann sphere.

The grid is embellished with colored points. Sine is periodic of real period , and nothing better illustrates this than the way the image wraps around the Riemann sphere, bringing the ends of the string of colored points together.

### Singularities

One way to visualize the behavior of a function at singularities is to plot in 3-space the modulus. This can be realized in a `ComplexPolarSurface` with second argument `Abs`. (More generally, a second argument for a function will provide a plot of the composite . Other instructive cases are and .)

The following function has poles at , , , , and .

Due to the symmetry about the origin of two pairs of the poles of , it is appropriate to plot over a polar region. The following plot depicts that at each pole . (We could have used dynamic interactivity to zoom in on each pole.)

The funnels at the poles appear to have different girths. The following calculation confirms that observation quantitatively.

### Multifunctions

The next example, suggested by a problem in Needham [5, p. 117] uses functionality of *Presentations* that is more advanced than what might be introduced in a first course in complex analysis. It concerns the following complex function.

The objective is to determine the nature of the branch points and and how the function varies as we follow various paths in the complex plane. To do so we shall employ a different representation of a complex function that uses a single movable point in the complex domain with an attached vector pointing from to .

First, we make a background plot on which to superimpose the moving complex vector.

Strictly speaking, we do not need a background plot, but could just move a `Locator` around in the plane with perhaps a domain mesh. We could also choose between many different types of background plots. Although the information in the background plot is redundant, it does help orient the viewer, and modulus information is one of the best “orienters”.

In order to find all branches of the multifunction, we solve for by taking sixth powers to clear the radical, so that the equation to be solved becomes .

The *Presentations* multifunction capability allows the generation of continuous sets of solutions along a path, even if a branch line is crossed. A path in the complex plane is first initialized using the `Multivalues` function. `Multivalues` has memory, and its first argument will routinely contain the values from the most recent evaluation. On initialization there are no previous values, so `Null` is supplied. The second argument is the list of expressions for the solutions and the third is the variable.

We then calculate two successive values, which were conveniently picked to cross the branch line going from to . Successive sets of multivalues are calculated using the companion function `CalculateMultivalues`, which carries the particular pathname as a subvalue. The routine returns the list of values and the permutation of the solutions used for those values.

Note that the values have been permuted between the two solutions and that all the solutions from the second evaluation are close to the solutions from the first evaluation. Often we will only be interested in the first solution that is generated. The following generates a table of values of the first solution as `testpath` circles the branch point at . For multivalues with memory to work properly, the steps on the path should be reasonably close. Here they are just close enough to work and yet give a short output list of angle, first function value, and permutation used.

Note that a complete circuit has reversed the function value. As we will show, it takes two complete circuits to return to the original function value.

In the following a background graphic consisting of a contour plot of the modulus is given to provide some overall orientation for the viewer. A locator is provided as a red `CirclePoint`. This can be used to sample at any point included in the domain of the graphic. Attached to the locator is a vector that gives the value of the first solution (at half scale) of at that point. On the right of the graphic, the numerical values of and are given, in Cartesian and polar form. The notation is the form returned by the *Presentations* function to represent the polar form , in other words, the value of .

Dragging the locator around the branch points demonstrates the multivalued nature of . The locator must be dragged twice around the point , or three times around the point , in order to return to its original value. It must be dragged six times around the complex of both branch points in order to return to its original value. This illustrates that it is not possible to have only a single branch line that joins the two branch points. There must be at least one branch line that goes to infinity.

Another way to present the same situation, carried out in [10], would be to attach all six solution vectors to each point in an array. But it is amazing how much information can be obtained with a single movable point and a single continuous solution. This is a true four-dimensional representation, although a local one: the domain of the function provides two dimensions, and the vector provides two more dimensions. By moving the locator, the complete four dimensions are revealed. Lastly, by showing only a single solution, we are in effect moving on the function’s Riemann surface, where the function is single-valued. By moving to various points on the surface we can recover all of the values. Thus we can explore the entire surface and return to a starting point with no discontinuities and no artifacts of intersecting surfaces. Of course we do not see the surface as an object in four-dimensional space; it just smiles at us like the Cheshire cat.

The Riemann surface is a complex surface. One way to visualize it as surface-like in real three-dimensional space is to represent it as a `ComplexPolar` object but, instead of and as arguments, use graphical objects that give the modulus and argument of the surface.

For aesthetic reasons the `Box` and `Axes` for the images were suppressed. There is one artifact in this presentation: in the argument graphic we must identify the upper edges (which occur at ) with the corresponding lower edges (which occur at ). Moreover, it is quite difficult to trace the paths that were used around the branch points in the previous, vector-locator, presentation. Perhaps a better presentation is obtained by a picture that looks more closely about one of the branch points, for example, .

Viewed closely about the point , the Riemann argument surface appears as three separate surfaces, each of which requires two revolutions to return to the original value. Go back to the dynamic vector-locator presentation. Circle closely around the zero at and you will see one of the surfaces. Now take a detour around the other zero at and return to circling the zero at . You will be on a different surface. Take one more detour and you will be on the third surface. This behavior might not have been discovered from the vector-locator presentation alone. Multiple presentations that complement each other are often the route to a fuller understanding of the beauty of complex functions.

Visualizing Riemann surfaces of multifunctions by means of surfaces in three-dimensional space also appears in [8].

### The Argument Principle

Domain coloring may also be used to visualize general principles about complex functions. We illustrate this with an adaptation of an example by Lundmark [9] concerning the Argument Principle. (Lundmark also provides online examples of similar types of domain-coloring plots created using tools other than *Mathematica*.)

The following function has a pole of order 3 at , a zero of order 2 at , and zeros of order 1 at and .

To illustrate the Argument Principle, we shall construct a graphic in two stages. In the first stage we construct a background graphic that is colored according to the argument of the function and then superimpose modulus contours on top of that. The function `DomainColoring` can generally be used for three-color coloring to indicate argument and modulus simultaneously. But here we use it with an `ArgColor` routine that colors from `IndianRed` to `Yellow` as the argument varies from to . (This results from the “`0`” argument in `ArgColor` that specifies the branch point in the domain to be at radians. Normally it is at .) Finally, `ComplexCartesianContour` is used to plot a selected set of modulus contours without any contour shading so that they overlay the argument coloring.

In the second stage of constructing the graphic, upon that background we plot two simple closed curves, the first around the points and , and the second around and . (In *Mathematica* 5 these points were obtained by clicking and copying points. In *Mathematica* 6 they could be obtained by using the `LocatorLine` routine in *Presentations* that allows any number of locators to be positioned on the graphic and used to copy their coordinates.) Each of the branch points is labeled with its signed multiplicity, a positive sign denoting a zero and a negative sign denoting a pole.

As the argument coloring indicates, as makes a circuit of each simple closed curve, the number of times the argument of increments by equals the sum of the orders of the zeros and poles inside that curve. And that is precisely what, according to the Argument Principle, happens in general for a meromorphic function : Let be a positively oriented, simple closed curve that does not pass through any zeros or poles of . As winds around , the image curve winds times around , where is the number of zeros of inside and is the number of poles inside , where each zero and pole is counted as many times as its multiplicity.

### Conclusion

Ideally, students coming to a complex analysis course where *Presentations* is used would already be experienced with *Mathematica*. In reality, unfortunately, this is seldom the case: students must learn *Mathematica *fundamentals with specifics about *Presentations* as they are learning about complex numbers and complex functions. In the first-named author’s course, two days’ class time was spent in a laboratory setting with a hands-on, rapid introduction to *Mathematica*, including a first glimpse of some functionality of *Cardano3* that is now in *Presentations*. Although that arrangement was hardly optimal, it sufficed to get them started.

To a *Mathematica* novice, the syntax of graphics routines in *Cardano3*, with their multiple, deeply-nested list arguments, was daunting. In the first author’s course, few students succeeded in constructing a syntactically correct domain-codomain mapping graphic without direct access to the documentation; they therefore relied upon instructor-provided templates for their own work.

As a result of that teaching experience of the first author and the entirely new features introduced with *Mathematica* 6, the *Cardano3* routines were completely redesigned and rewritten and then incorporated in the *Presentations* application, the successor to *DrawGraphics*. One major flaw in the *Cardano3* design was an attempt to create a container and user interface that would handle all complex-function graphics. It is now recognized that packages should not create new interfaces, which are just additional specialized things that students have to learn, but should instead simply extend *Mathematica* and mesh with its standard usage.

Until such a time as technical students can begin learning *Mathematica* in secondary school, it will remain a challenge to bring them up to speed for *Mathematica* use in college courses. A temporary and imperfect, but still useful, alternative could be to provide the kinds of examples shown here as web*Mathematica* applications or Demonstrations (demonstrations.wolfram.com). For now the best solution may be specially designed *Mathematica* tutorials that present the common constructions used in the course and introductory labs. But there is a wonderful payoff when students can obtain hands-on visual experience of the mathematical objects to complement their analytical work.

### References

[1] | D. J. M. Park, Jr. “Presentations Package for Mathematica: Custom Graphics and Presentations with Mathematica.” (Dec 12, 2007) home.comcast.net/~djmpark/DrawGraphicsPage.html. |

[2] | D. J. M. Park, Jr. “Cardano3 Package.” (Jun 19, 2006) home.comcast.net/~djmpark/Cardano3Page.html. |

[3] | M. Eisenberg. “Math 421—Fall 2006: Complex Variables.” (Jan 7, 2007) |

[4] | J. H. Mathews and R. W. Howell, Complex Analysis for Mathematics and Engineering, 5th ed., Sudbury, MA: Jones and Bartlett Publishers, 2006. |

[5] | T. Needham, Visual Complex Analysis, New York: Oxford University Press, 1997. |

[6] | D. J. M. Park, Jr., “DrawGraphics,” Mathematica in Education and Research, 10(1), 2005 pp. 41-66. |

[7] | T. Ersek. “RootSearch Looks for All Roots of an Equation between xmin and xmax.” (May 2, 2006) library.wolfram.com/infocenter/MathSource/4482. |

[8] | S. Kivelä, “On the Visualization of Riemann Surfaces,” in Applied Mathematica, Electronic Proceedings of the Eighth International Mathematica Symposium (IMS‘06), Avignon, France (Y. Papegay, ed.), Sophia Antipolis, France: INRIA, 2006 ISBN 2-7261-1289-7. internationalmathematicasymposium.org/IMS2006/IMS2006_CD/html/articles.html. |

[9] | H. Lundmark. “Hans Lundmark’s Complex Analysis Pages.” (Jan 28, 2008) www.mai.liu.se/~halun/complex. |

[10] | M. Eisenberg and D. J. M. Park, Jr., “Visualizing Complex Functions with the Cardano3 Application,” in Applied Mathematica, Electronic Proceedings of the Eighth International Mathematica Symposium (IMS‘06), Avignon, France (Y. Papegay, ed.), Sophia Antipolis, France: INRIA, 2006 ISBN 2-7261-1289-7internationalmathematicasymposium.org/IMS2006/IMS2006_CD/html/articles.html. |

[11] | Anonymous. “MathGroup Archive 2006.” (Feb 2006) forums.wolfram.com/mathgroup/archive/2006/Feb/msg00336.html. |

M. Eisenberg and D. J. M. Park, Jr., “Visualizing Complex Functions with the Presentations Application,” The Mathematica Journal, 2011. dx.doi.org/doi:10.3888/tmj.11.2-6. |

### About the Authors

Murray Eisenberg is a professor of mathematics and statistics at the University of Massachusetts Amherst and received his A.B. and A.M. from the University of Pennsylvania and his Ph.D. from Wesleyan University. Eisenberg’s principal mathematical interest is the topology of dynamical systems. He has published articles on topological dynamics, the APL and J programming languages, and the use of computers in teaching undergraduate mathematics, and is the author of three undergraduate textbooks.

David J. M. Park, Jr. received a B.S. and M.S. in electrical engineering from M.I.T. Park worked on microwave and beam design elements of early cesium beam tubes for atomic clocks and on masers. While working as a computer consultant he became involved in biochemistry and developmental biology, published a number of articles in the field, and worked for a period of time at the Laboratory for Theoretical Biology at N.I.H. In his retirement he has used *Mathematica* to renew an interest in mathematical physics and in the process has developed packages used by many *Mathematica* users. Most recently he has been collaborating with Renan Cabrera and Jean-François Gouyet to design *Tensorial*, a *Mathematica* package for tensor calculus.

**Murray Eisenberg**

*Department of Mathematics and Statistics
University of Massachusetts
Lederle Graduate Research Tower
710 North Pleasant Street
Amherst, MA 01003-9305 USA*

*murray@math.umass.edu*

*www.math.umass.edu/~murray*

**David J. M. Park, Jr.**

*1429 Searchlight Way
Mount Airy, MD 21771 USA
*

*djmpark@comcast.net*

*home.comcast.net/~djmpark*