On Coding XIII: Retrospective.

I published the first installment of On Coding on September 11, 2016.  It seems a bit surreal that this thread is over a year old — but all good things must come to an end.  I really enjoyed writing these posts; they helped me organize my thoughts about my own personal coding history.

But there are some loose ends I’d like to tie up.  I’ve had brief forays into other languages — too brief to devote an entire post to any one of them.  I’ve mentioned a few of them here and there, but I’d like to take the opportunity to include them all in one post.

Before doing so, I should mention that Processing is my most recent programming adventure.  But I have written so much about using Processing in the context of my digital art course, I don’t feel the need to devote a separate post to it.  And I feel I might bore you, dear reader….

The first is PASCAL, which I first learned while taking an undergraduate programming class.  Other than the course, I only did a few other things with PASCAL.  I did write a routine that printed out 4 x 4 magic squares — I was really into magic squares back in college.  I also dabbled with computer graphics and geometrical inversion — I recall giving a talk where I discussed geometrical inversion, and I split the screen so on one side you saw lines tangent to a conic section, while on the other side, you saw inverse circles tangent to the inverse limaçon.

While in graduate school, I had a one-year stint filling in for a faculty member at a nearby college, and I taught a data structures course using PASCAL.  Now, I would never think of PASCAL as a go-to language for any particular purpose.  It’s still around, but not nearly as popular as it was then.

The next is LISP*, which I used while teaching at a summer program during graduate school.  This was a parallel version of LISP written for the Connection Machine, a state-of-the-art supercomputer in its day.  It had literally thousands of different processors, each very simple.  But because of the sheer number of processors, the speed of the Connection Machine merited it the designation “supercomputer.”

The language was quite similar to LISP, except that many functions had parallel versions which could be executed on each processor.  I can’t recall much of what I did on the Connection Machine, but I do remember programming Conway’s Game of Life on a 1000 x 1000 torus.  Of course I can do that on my laptop right now in Mathematica, but at the time, it was a real feat!  Remember, that was back in the day when Mandelbrot sets were calculated pixel by pixel and computers were so slow you could actually see the pixels march right on by….

Chronologically, Maple — a direct competitor of Mathematica — comes next, sort of…I used Maple around the same time as LISP*.  I seem to recall the only reason I played around with it was that I had a house-sitting job for a few summers, and there was a computer I could use which had Maple on it.

I recall finding Maple really useful, but there was a bit more syntax than with Mathematica.  I really like Mathematica‘s fundamental data type — the list, just like LISP.  But I think part of the reason I’ve stuck with Mathematica through the years is that most places I’ve been have supported it — and being free is a big advantage.  I know Maple has changed a lot since I last used it, so I don’t feel I’m able to say more about a comparison with Mathematica than what I’ve already said.

Jump ahead a few years to C++.  I can’t remember exactly when I started learning it, but I was teaching at a small liberal arts college, and a colleague who usually taught an algorithms course was going on sabbatical.  I was really the only other faculty member at the university qualified to teach it, and so there it was!  The students in the course knew C++, so I needed to learn it, too….

Well, I should say I learned enough to write code for an introductory algorithms course, which means I didn’t have to dive too deeply in.  I can’t say I used C++ for much after I taught the course, except I remember writing some routines to do financial planning.  You know, like if you have different investments at different interest rates for different numbers of years, etc., how much will you have when you retire?  (Being a mathematician, I thought it insane that I should pay someone else to do my financial planning, so I read everything I could on the topic and did it myself.)  But I haven’t used C++ since.

Last — and perhaps least — there’s Java.  I learned Java was when I was applying for a job teaching mathematics and computer science, and the language taught was Java.  I had never written a line in Java before, and there was some concern that I wasn’t qualified.

So I wrote a little interactive game based on some puzzles I created, which was really quite nice, if I must say.  The only way to show you know how to code in a language is to code, so I did it.

It was rather unpleasant, though.  What I needed to do was really just algorithmic, and the object-orientedness of Java and the need to precisely define data structures really got in the way.  I hope never to write another line of Java again.  (Incidentally — long story — I was offered the job but turned it down.  Saved me from teaching Java….)

And I think that’s about it!  If I can leave you with anything after this series, it’s GO CODE!  Learn as many different types of languages as you can.  The best way to learn is to find something you really want to do, and then go for it.

Remember, my first programming language was Fortran — using punch cards.  Running batch jobs.  Today, you’ve got laptops and the internet.  The only limit is your imagination….



On Coding XII: Python

It has been some time since I wrote an installment of On Coding.  It’s time to address one of my more recent programming adventures:  Python.  I started learning Python about two-and-a-half years ago when I began teaching at the University of San Francisco.

One of my colleagues introduced me to the Sage environment (now going by “CoCalc”) as a place to do Mathematica-like calculations, albeit at a smaller scale.  Four features were worthy of note to me:  1)  you could do graphics;  2)  you could write code (in Python);  3)  you could run the environment in your browser without downloading anything;  and 4)  it was open source.

For me, this was (at the time) the perfect environment to develop tools for creating digital art which I could freely share.  Yes, I had thousands of lines of Mathematica code, but Mathematica is fairly expensive.  I wanted an environment which would be easily accessible to students (and my blog followers!), and Sage fit the bill.

So that’s why I started learning Python — it was the language I needed to learn in order to use Sage.

For me, two things were a challenge.  The first was how heavily typed Python is.  In Mathematica, the essential data structure is a list, just like in LISP.  For example,

{1, 2, 3}

is a list.  But that list may also represent a vector in three-dimensional space — even though it would look exactly the same.  It may also represent a set of numbers, so you could calculate

Intersection[{1, 2, 3}, {3, 4, 5}].

In Python you can create a list, tuple, or set, as follows:

list([1, 2, 3]),  tuple([1, 2, 3]), set([1, 2, 3]).

And in Python, these are three different objects, none equal to any other.  I don’t necessarily want to start a discussion of typed vs. untyped languages, but when you’re so used to using an untyped language, like Mathematica, you are constantly wondering if the argument to some random Python function is a list, tuple, or….

Second, Python has a “return” statement.  In languages like LISP and Mathematica, the value of the last statement executed is automatically returned.  In Python, you have to specify that you want a value returned by using a return statement.  I forget this all the time.

And while not a huge obstacle, it does take a little while to get used to integer division.  In Python, 3/4 = 0, since when you divide integers, the value of the fraction is the quotient when considered as integer division.  But 3/4. = 0.75, since adding the decimal point after the 4 indicates the number is a floating point number, and so floating-point arithmetic is performed.

Of course, if you’ve been reading recent posts, you know I’ve moved from Sage entirely to Processing in my Mathematics and Digital Art course.  You can read more about that decision here — but one key feature of Processing is that there’s a Python mode, so I was able to take work already done in Sage and adapt it for Processing.

It turns out that this was not as easy as I had hoped.  The essential difficulty is that in Sage, the bounding box of your image is computed for you, and your image is appropriately scaled and displayed on the screen.  In Processing, you’ve got to do that on your own, as well as work in a space where x– and y-coordinates are in units of pixels, which is definitely not how I am used to thinking about geometry.

I am finding out, however — much to my delight and surprise — that there are quite a few functional programming aspects built into Python.  I suspect there are many more than I’m familiar with, but I’m learning them a little at a time.

For example, I am very fond of using maps and function application in Mathematica to do some calculations efficiently.  Rather than use a loop to, say, add the squares of the numbers 1– 10, in Mathematica, you would say

Plus @@ (#^2& /@ Range[10])

The “#^2&” is a pure function, and the “/@” applies the function to the numbers 1–10 and puts them in a list.  Then the function “Plus” is applied, which adds the numbers together.

There is a similar construct in Python.  The same sum of 385 can be computed by using

sum([(n + 1)**2 for n in range(10)])

OK, this looks a little different, but it’s just the syntax.  Rather than the “#” character for the variable in the pure function, you provide the variable name.  The “for” here is called list comprehension in Python, though it is just a map.  Of course you need “(n + 1),” since Python always starts at 0, so that “range(10)” actually refers to the numbers 0–9.  And the “sum” function can take a list of numbers as well.  But from a conceptual level, the same thing is going on.

The inherent “return” in any Mathematica function does find its way into Python as well. Let’s take a look at a simple example:  we’ll write a function which computes the maximum of two numbers.

Now you’d probably think to write:


This is the usual way of defining “max.”  But there’s another way do to this in Python.

If you ask Python to

print 3 > 2,

you’ll see “True.”  But you can also tell Python to

print (3 > 2) + 7

and get “8.”  What’s going on here is that depending on the context, “3 > 2” can take on the value “True” or “1.”  Likewise, “3 < 2” can take on either the value “False” or the value “0.”

This allows you to completely sidestep making Boolean checks.  Consider the following definition.


This also works!  If in fact a >= b, you return the value 1 * a + 0 * b, which gives you a — the maximum value when a >= b.  And when a < b, you return b.  Note that when a = b, both are the maximum, so we could just as well have written


I think this is a neat feature of Python, which does not have a direct analogue in Mathematica.  I am hoping to learn many other intriguing features like this as I dive deeper into Python.

Python is my newest language, and I have yet to become “fluent.”  I still sometimes ask the internet how to do simple things which would be at my fingertips in Mathematica.  But I do love learning new languages!  Maybe in a year or so I’ll update my On Coding entry on Python with a flurry of new and interesting things I’ve learned….

On Coding XI: Computer Graphics III, POV-Ray

It has been a while since the last installment of On Coding.  I realized there is still more to say about computer graphics; I mentioned the graphics package POV-Ray briefly in On Coding IX, but feel it deserves much more than just a mere mention.

I’d say I began using POV-Ray in the late 1990’s, though I can’t be more precise.  This is one of the first images I recall creating, and the comments in the file reveal its creation date to be 19 September 1997.


Not very sophisticated, but I was just trying to get POV-Ray to work, as I (very vaguely) remember.  Since then, I’ve created some more polished images, like the polyhedron shown below.  I’ll talk more about polyhedra in a moment….


First, a very brief introduction.  POV-Ray stands for Persistence of Vision Raytracer.  Ray tracing is a technique used in computer graphics to create amazingly realistic images.  Essentially, the color of each pixel in the image is determined by sending an imaginary light ray from a viewing source (the camera in the image below) and seeing where it ends up in the scene.

Image by Henrik, Wikipedia Commons.

It is possible to create various effects by using different light sources, having objects reflect light, etc.  You are welcome to read the Wikipedia page on ray tracing for more details on how ray tracing actually works; my emphasis here will be on the code (of course!) I wrote to create various three-dimensional images.  And while the images you can produce using a ray tracing program are quite stunning at times, there is a trade-off: it takes longer to generate images because the color of each pixel in the image must be individually calculated.  But I do think the results are worth the wait!

My interest in POV-Ray stemmed from wanting to render polyhedra.  The images I found online indicated that you could create images substantially more sophisticated than those created with Mathematica.  And better yet, POV-Ray was (and still is!) open source.  That means all I needed to do was download the program, and start coding….


POV-Ray is a procedural programming language all in itself.  So to give you an idea of what a typical program looks like, I’ll show you the code which makes the following polyhedron:


Here’s how it begins.


The #include directive indicates that the given file is to be imported.  POV-Ray has many predefined colors and literally hundreds of different textures:  glass, wood, stone, gold and other metals, etc.  You just include those files you actually need.  To give you an idea, here is the logo I created for Dodecahedron Day using  silver and stone textures.


Next are the global settings.  There are actually many global settings which do a lot more than I actually understand…but I just used the two which were included in the file I modeled my code after.  Of course you can play with all the different settings (there is extensive online documentation) and see what effects they have on your final image, but I didn’t feel the need to.  I was getting results I liked, so I didn’t go any further down this path.

Then you set the camera.  This is fairly self-explanatory — position the camera in space, point it, and set the viewing angle.  A fair bit of tweaking is necessary here.  Because of way the image is rendered, you can’t zoom in, rotate, or otherwise interact with the created image.  So there is a bit of trial-and-error in these settings.

Lighting comes next.  You can use point light sources in any color, or have grids of light sources.  The online documentation suggested the area lighting here (a 5-by-5 grid of lights spanning 5 units on the x-axis and 5 units on the z-axis), and it worked well for me.  Since I wanted the contrast of the colors of the faces of the polyhedra on a black background, I needed a little more light than just a single point source.  You can read all about the “adaptive” and “jitter” parameters here, but I just used the defaults suggested in the documentation and my images came out fine.

There are spotlights and cylindrical lighting sources as well, and all may be given various parameters.  Lighting in Mathematica is quite a bit simpler with fewer options, so lighting was one of the most challenging features of POV-Ray to learn how to use effectively.

So that’s the basic setup.  Now for the geometry!  I can’t go into all the details here, but I can give you the gist of how I proceeded.


The nested while loops produce the 60 yellow faces of the polyhedron.  Because of the high icosahedral symmetry of the polyhedron, once you specify one yellow face, you can use matrices to move that face around and get the 59 others.

To get the 60 matrices, you can take each of 12 matrices representing the symmetries of a tetrahedron (tetra[Count]), and multiply each by the five matrices representing the rotations around the vertices of an icosahedron (fiverot[Count2]).  There is a lot of linear algebra going on here; the matrices are defined in the file “Mico.inc”, which is included.

The vertices of the yellow faces are given in “VF[16]”, where the “VF” stands for “vertex figure.”  These vertex figures are imported from the file “VFico.inc”.  Lots of geometry going on here, but what’s important is this:  the polygon with vertices listed in VF[16] is successively transformed by two symmetry matrices, and then the result is defined to be an “object” in our scene.  So the nested loops place 60 objects (yellow triangles) in the scene.  The red pentagrams are created similarly.


Finally, the glass tabletop!  I wanted the effect to be subtle, and found that the built-in texture “T_Glass2” did the trick — I created a square (note the first and last vertices are the same; a quirk of POV-Ray) of glass for the polyhedron to sit on.

POV-Ray does the rest!  The overall idea is this:  put whatever objects you want in a scene.  Then set up your camera, adjust the lighting, and let POV-Ray render the resulting image.


Of course this introduction is necessarily brief — I just wanted to give you the flavor of coding with POV-Ray.  There are lots of examples online and within the documentation, so it should not be too difficult to get started if you want to experiment yourself!

On Coding X: Computer Graphics II

Now that I’ve talked about what I use computer graphics for in my last installment of On Coding, I’d like to talk about the most useful graphics package I’ve come across for writing mathematics:  TikZ.

First a word about the name, TikZ.  It’s an example of a recursive acronym, like GOD used in Douglas Hofstadter’s Gödel, Escher, Bach, which stands for “GOD Over Djinn.”  (By the way, read Gödel, Escher, Bach if you haven’t already — it’s an amazing book about Gödel’s Incompleteness Theorem.)

So TikZ stands for “TikZ ist kein Zeichenprogramm,” which is German for “TikZ is not a drawing program.”  According to its creator, Till Tantau, this indicates that TikZ is not a way to draw pictures with your mouse or tablet, but is more like a computer graphics language.  It is designed for use in LaTeX, and is built with a lower-level language called PGF, which stands for “portable graphics format.”

So enough history — you can read more in the TikZ manual.  But a word of caution — it’s over 1000 pages long, so there’s a lot there!  I’ll only be able to scratch the surface today.

The two most important features of TikZ, in my opinion, are (1) you can draw very precise graphics because you’re writing in a high-level langauge, not using a WYSIWYG environment, and (2) you can use it in LaTeX, including putting any LaTeX symbols in your graphics.  This second point is extremely important, since it means when you’re labelling a diagram, the labels (usually involving mathematical symbols) look exactly the same way as the do in your text.

I use TikZ almost exclusively for two-dimensional mathematical graphics.  In a recent paper, for example, I created the following image.


Note how precisely all the elements are rendered — this is because you give precise coordinates for all the individual graphics elements.

Let’s take a look at another, somewhat simpler example from this paper.


I chose this example for a few reasons.  First, it requires using a lot of the basic TikZ commands.  Second, it illustrates the practical side of drawing computer graphics.  No, I’m not going to submit this image to a Bridges art exhibition any time soon — but if I need to make an image for a paper, I want it to look good.

So I thought I’d take some time to explain various aspects of the code which creates this image.  Maybe not the most glamorous graphic — but you’re welcome to look at the 1000+ page manual for hundreds of neat examples.  Here is a diagram for a finite-state automaton from page 179, for example.



Here’s what you’d need to type in LaTeX to get the simple graph I mentioned a moment ago.


Let’s look at several different excerpts from this example.  The first line opens your TikZ environment, and scales the image.  The default unit is 1 cm, so you need to set the scale to get your image the right size.

The next line is just a comment — I don’t use comments much for simple images.  But for more complex images, they’re important.  Just as important as commenting computer code.

The next line draws a set of axes.  What’s important here is that I defined my own “\axes” command — so you can include user-defined functions as well.  The advantages of being able to do this are huge.  You can use any command you define in LaTeX in a TikZ image.

Another great feature is the looping construct, “\foreach.”  The red segments above are one unit long, and so the only difference is the starting points.  Also important here is that you can use mathematical expressions inside TikZ, like the “{(\x^2+9)/6}” expression in the curly brackets.

Note the directives “[thick, red]” after the “draw” command.  You have control over every aspect of the drawing routines in TikZ — and there are lots of them.  For example, there is the “dashed” directive in line 10.  But not only can you draw a dashed line, but you can also specify the lengths of the dash marks and the spaces between them, too!  Further, you can create user-defined styles if you use the same set of directives over and over again.  This is helpful if you are creating several related images, and you want to tweak the color, for example.  You only have to change the color specification in the style, and every image which uses that style will be rendered using the new color.

Notice the “\filldraw” command in line 6.  I wanted open circles, so I drew the circles in red, and filled them with white.  If I wanted to, I could have also specified precisely how thick I wanted the circles to be drawn, but the default thickness looked just fine to me.

Notice the use of “node” and “\node” throughout.  In line 9, for example, the “3” is centered at coordinates (3, -0.5).  Also note the placement of nodes at the end of line segments, as shown in lines 7 and 8.  Again, it is significant that you can include any text you can create in LaTeX in your diagram.

I hope this is enough to give you the feel of using TikZ.  As I mentioned in the last installment, I also use TikZ to create slideshow presentations since there is so much you can do.  Remember, there are over 1000 pages of examples of things you can do in TikZ in the manual.

I would like to mention one caveat, however.  I do sometimes use Mathematica to create images with mathematically intensive equations and calculations.  TikZ is closer to a markup language in its usage, as I see it — so any image that requires significant coding to produce is a bit too cumbersome syntactically.  Here is an example of an image I used Mathematica to create.


But another nice TikZ feature is that you can import images into your environment — so I can draw complex images in Mathematica, include them in my TikZ picture, and then overlay LaTeX symbols on top of the image.  With this capability, the possibilities are quite literally endless.

A final comment:  TikZ and LaTeX are both open source, so if you’re interested, you can just download them and start experimenting!  The learning curve is a little steep, admittedly, but once you’ve climbed up, you’ll be able to create astonishingly beautiful graphical images for any purpose you have in mind.  Try it!


On Coding IX: Computer Graphics I

It has been some time since an On Coding installment, and I thought it finally time to discuss computer graphics.  Of course I’ve done that a lot already, as far as several applications go.  For this post, I asked myself something different:  what do I use computer graphics for?


I had never really taken a step back to look at the larger picture, but that’s one of the purposes of this thread.  I came up with seven major uses, in roughly chronological order from when I started using graphics in each way:

  1. Creating fractals.
  2. Graphic design.
  3. Rendering polyhedra in three dimensions.
  4. Mathematical illustration.
  5. Web design.
  6. Mathematical art.
  7. Research.

Today, I’ll give a brief overview, and follow up in future posts with more details about the various platforms I’ve used.

I don’t need to say a lot about the first two uses, since I’ve discussed them in some detail in my posts on Postscript and iterated function systems.  My interest in fractals has of course continued, especially given my passion for Koch curves and binary trees.  I work less with graphic design now — I used to design stationery and business cards for myself and friends, but now that communication is so largely electronic, there is less of a need.  But I do still occasionally design business cards using my art logo, print them onto cardstock, and cut them myself when I need to.


I also spend quite a bit of time designing title and separator slides for presentations.  (I frankly admit to never having created a PowerPoint presentation in my entire life.  Yuck.)  I now exclusively use TikZ in LaTeX since you have complete control over the graphics environment.


I haven’t mentioned polyhedra extensively on my blog so far, but my interest in three-dimensional geometry goes back to my undergraduate days.  When I started teaching college for the first time, I designed (and eventually wrote a textbook for) a course on polyhedra based on spherical trigonometry.

The main tool I used early on was Mathematica, and when I redid all my graphics for my textbook about five years ago, I used Mathematica.  The image you see above was rendered using POV-Ray, a ray-tracing package which allows the user to specify a wide range of parameters to create realistic effects.  You can see shadows and a reflection as if the polyhedron were sitting on a shiny, black surface.  And while the images generated by POV-Ray are quite a bit nicer than those created with Mathematica, they take more time and effort to create.

Mathematical illustration covers a wide range of uses.  Drawing figures for a mathematical paper perhaps first comes to mind.  I used a package called PSTricks for quite a while (since the “PS” stands for Postscript), but once I learned about TikZ, I changed over fairly quickly.  This means I needed to re-render many older graphics (especially in my textbook) — but since for both packages you need precise coordinates, I already had all the mathematics worked out for the PSTricks function calls.  So converting to TikZ wasn’t all that problematic.  I will be talking in more detail about TikZ in a future post.


Of course there are also geometrical puzzles and problems, as I’ve discussed before on my blog.  Nicely formatted graphics go a long way in making a puzzle appealing to the reader.

Web design is especially important, since I rely so much on my website for everything.  I have a web page for my artwork, for my publications, talks, and anything I do professionally.  I strive for functionality and aesthetics.  I’m also a minimalist as far as design goes — “less is more.”

Also important is ease of use for me.  It’s not hard to add something to my homepage.  I don’t have the time (or interest) in redesigning my homepage every I want to add a new link.  I’m not a fan of hiding everything in dropdown menus — I want the user to glance at my site, and immediately click on the relevant link without having to pore through menus.

Mathematical art has actually been a fairly recent use of computer graphics for me — I only really started getting into it about four years ago.  I don’t feel I have to say a lot about it right here, since it is a common thread throughout so many of my posts.  You can visit my art website, or look at my Twitter, where I try to update daily (as much as I can) with new and interesting pieces of mathematical art.

Finally, I’d like to say a word about the last use of computer graphics:  research.   I think this is extremely important, especially with the exploding world of data visualization.  Really, this has been perhaps Nick’s and my most important tool when it comes to studying binary trees.


Without going into too much detail about this image, is consists of six scaled and rotated copies of one tree (the ones in color) and a related dual tree (in white).  Now count the number of leaves (ends of paths) in common with the colorful trees — and you’ll count 1, 5, 10, 10, 5, and 1.  These are, of course, binomial coefficients:  row 5 of Pascal’s triangle.

Why is this the case?  And is there some general result to be proved?  The point I’m making is that when Nick and I create routines to display different trees or combinations of trees, we look at lots of examples, and seek recurring themes.

We learn a lot by doing this, and the direction of our research is heavily influenced by what we observe.  This might not be so surprising, since after all, fractal trees are such geometrical objects.  I can honestly say the pace of our progress in making conjectures is directly linked to our ability to produce large numbers of trees and knowing what to look for.

So that’s what I use computer graphics for!  In future posts, I’ll discuss the various software packages I use, and try to give some idea of the advantages and disadvantages of each.  I’ll give special emphasis to those that are open-source — there is so much out there that is free to download, anyone interesting in computer graphics will have no difficulty finding something interesting to experiment with!

On Coding VIII: LaTeX II

Today, I’ll conclude my remarks about my passion for using LaTeX.  As I was writing the last installment of On Coding, I realized that I had more to say than would fit in just one post.

Yet another wonderful thing about LaTeX is how many mathematicians and scientists use it — and therefore write packages for it.  You can go to the Comprehensive TeX Archive Network and download packages which make Feynman diagrams for physics, molecular structures for chemistry, musical scores, and even crossword puzzles or chessboards!  There are literally thousands of packages available.  And like LaTeX, it’s all open source.  That is a feature which cannot be overstated.  Arguably the world’s best and most comprehensive computer typesetting platform is absolutely free.

The package I use most often is TikZ — it’s a really amazing graphics package written by Till Tantau.  You can do absolutely anything in TikZ, really.  One extremely important feature is that you can easily put mathematical symbols in any graphic.


This is nice because any labels in your diagram will be in the same font as your text.  I always find it jarring when I’m reading a mathematics paper or book, and the diagrams are labelled in some other font.

There is so much more to say about TikZ.  I plan to talk about it in more detail in a future installment about computer graphics, so I’ll stop here and leave you with one more graphic made with TikZ.


Another package I use fairly often is the hyperref package.  This is especially useful when you’re creating some type of report which relies on information found on the web.  For example, when I request funding for a conference, I need to include a copy of the conference announcement.  So I create a hyperlink (in blue, though you can customize this) in the document which takes you to the announcement online when you click on it.

These hyperlinks can also be linked to other documents in the cloud, so you can have a “master” document which links to all the documents you need.  Now that I’m approaching 100 blog entries, I plan on making an index this way.  I’ll create a pdf (using LaTeX, of course) which lists posts by topic with brief descriptions as well as hyperlinks to the relevant blog posts.

On to the next LaTeX feature!  I learned about this one from a colleague (thanks, Noah!) when I was writing some notes on Taylor series for calculus.  I used it as a text when I taught calculus; the notes are about 100 pages long.

I wanted to share these notes with others, and the style of the notes was such that the exercises weren’t at the end of the sections, but interwoven with the text.  Students are supposed to do the exercises as they encounter them.

But for other calculus teachers, it was helpful to include solutions to the exercises.  The problem in creating a solutions manual was that if I ever edited the notes, I’d have to also edit the solutions manual in parallel.  I knew this was going to happen, since when I gave exams on this material, I added those problems as supplementary exercises to the text.

Enter the ifthen package in LaTeX.  I created an exercise environment, so that every time I included an exercise, I had a block which looked like this:


{….the exercise….}

{….the solution….}


Think of this as an exercise function with two arguments:  the text of the exercise, and the text of the solution.

Then I created a boolean variable called teacheredition.  If this variable was true, the exercise function printed the solutions with each exercise.  If false, the solutions were omitted.  This control structure was made easy by some functions in the ifthen package.

And that’s all there was to it!  So every time I created an exercise, I added the solution right after it.  Of course the exercises were automatically numbered as well.  No separate solutions manual.  Everything was all in one place.  If you have ever had to deal with this type of issue before, you’ll immediately recognize how unbelievably useful the ability to do this is!

While not really features of LaTeX itself, there are now places in the cloud where you can work on LaTeX documents with others.  I’d like to talk about the one Nick and I are currently using, called ShareLaTeX.   This is an environment where you can create a project, and then share it with others so they can work on it, too.

So when Nick and I work on a paper together, we do it in ShareLaTeX.  It’s extremely convenient.  We can edit the paper on our own, but most often, we use ShareLaTeX when we’re working together.  Usually, we’re working on different parts of the paper — but when one of us has something we want the other to see, it’s easy to just scroll down (or up) in the document and look at what’s been done.

Also nice is that it’s easy to copy projects — so as we’re about to make a big change (like use different notation, or alter a fundamental definition), our protocol is to make a copy of the current project to work on, and then download the older version of the project (just in case the internet dies).

It’s wonderful to use.  And it actually really came in handy when Nick was working on his Bridges paper for last year.  His computer hard drive seriously crashed.  But since we were working on ShareLaTeX, the draft of his paper was unharmed.

I hope this is enough to convince you that it might be worthwhile to learn a little LaTeX!  I seriously don’t know what I’d do without it.  And — as it bears repeating — it’s all open source, available to anyone.  So, really, why isn’t the whole world using LaTeX?  That’s a mystery for another day….

On Coding VII: LaTeX I

I’ll talk about LaTeX in this installment of On Coding — and my next one, too.  There is so much to say, I realized I couldn’t say it all in just one blog post.

LaTeX is a markup language, like HTML, but its purpose is completely different.  TeX was invented when its creator, Donald Knuth, thought the galley proofs for one of his computer science textbooks looked so awful, he thought that something should be done about it.  This was in the late 70’s.  TeX was initially released in 1978; in 1985, Leslie Lamport released LaTeX, which is a more user-friendly version of TeX.  This Wikipedia article has a more complete history if you’re interested.

Basically, LaTeX makes math look great.  Here’s a formula taken from the paper Nick and I submitted to Bridges 2017 recently.


It’s perfectly formatted, all the symbols and spacing nicely balanced.  Without mentioning any names, try producing that same formula in some other well-known word-processing environment, and you’ll find out it doesn’t even come close to looking that good.

Before I go into more detail about all my favorite LaTeX features, I’d like to explain how it works.  Typically, you download some TeX GUI — I use TeXworks at home.  The environment looks like this:


On the left-hand side is the LaTeX markup, and on the right-hand side is a previewer which shows you how your compiled text would look as a pdf document.  Just type in your text, compile, view, repeat.  Much like HTML.

There are many things I like about LaTeX, and it’s hard to rank them in any particular order.  Although first — and foremost — mathematical formulas look fantastic.

A close second is the fact that it’s fast.  By that, I mean that because a markup language it text-based, there’s no mouse involved.  I’m a very fast typist, which means I can type LaTeX markup almost as fast as I can type ordinary text.  If you’ve ever hard to typeset a formula by means of drop-down menus, you know exactly what I mean.

The third feature is closely related to the second:  it’s intuitive.  For example, to get the trigonometric formula


you would type


All commands in LaTeX are preceded by a backslash (“\”), so you can always distinguish them from text.  And if you look at the text, you can almost figure out the formula just from reading the commands.  It maps perfectly.

Most of LaTeX is that way — the commands describe what they do.  For example,

x\rightarrow y

is created using

$$x\rightarrow y$$.

Now you might be thinking that’s a lot to type for a simple formula — surely there must be a shorter way!  First, there is.  You can just define your own macro by saying


so you could just type

$$x\ra y$$.

This might be a good thing to do if you use a right arrow all the time.  But secondly, if you just use it occasionally, it’s really quite easy to remember.  When you want a right arrow, you just type “\rightarrow”.  If you want a longer arrow which points in both directions, like

x\longleftrightarrow y,

you just type

$$x\longleftrightarrow y$$.

Once you understand how the commands are named, it’s often easy to guess which one you’ll need just by thinking about it.

Next up, LaTeX makes your life a lot easier, especially when you’re working on big projects.  There are a lot of ways this is done, so I’ll just mention one of my favorites — the “\label” command.

\displaystyle\bigcup_{j\in{\mathbb Z}}{\bf R}^{2j}_{\theta}\,C_{r,\theta}^n={\bf R}^{n\,\rm{mod}\,2}_{\theta}\bigcup_{j\in{\mathbb Z}}{\bf R}^{2j}_{\theta}\,C_{1/r,\theta}^n\qquad(5)

This equation (again from the Bridges paper) is typeset using the commands (broken up for reference):

  1. \begin{equation}
  2. \bigcup_{j\in{\mathbb Z}}{\bf R}^{2j}_{\theta}\,C_{r,\theta}^n={\bf R}^{n\,\rm{mod}\,2}_{\theta}\bigcup_{j\in{\mathbb Z}}{\bf R}^{2j}_{\theta}\,C_{1/r,\theta}^n
  3. \label{theorem1}
  4. \end{equation}

The equation (described by (2)) is sandwiched between a begin/end block ((1) and (4)).  But the key command is the “\label” command on line (3).  When you want to refer to this equation in LaTeX, you don’t use text like “equation (5)”, you say “equation (\ref{theorem1})”.

The \label command assigns the number of the equation — in this case, 5 — to the label “theorem1”.  So when you use the “\ref” command (stands for “reference,” naturally), LaTeX will look for the number assigned to “theorem1”.

This might not seem like a big deal at first.  But as you work on a paper, you’re always deleting equations, adding them, or moving them around.  By assigning them labels, any references you make to equations in your text are automatically updated when you make changes.

And while we’re on the subject of equations — of course an extremely important topic when thinking about writing mathematics — there is also the “\nonumber” command, as well.  Before you end the equation, you migh add a \nonumber tag, as in


Why would you label an equation for easy reference, and then not even put the number next to the equation?  It is good mathematical style to only number equations that are referenced in the text.  If you just show them once and don’t refer to them later, they don’t need a number.

But as you rewrite a proof, for example, you might find you no longer need to reference a particular equation, and so you don’t need the number any more.  So rather than having to format it as not an equation (deleting the begin/end block), you just add the \nonumber tag.  It’s a lot easier.

So what I do is label every equation as I write, and then when I have a final draft, I just go through and unnumber all those equations which I never end up referencing.  It’s so nice.

I know I went on a bit about equations, but similar conveniences are available for figures, tables, article sections, book chapters, bibliographic entries, etc.  You never have to remember a number.  Ever.

And yes, there’s more….  Stay tuned for the next On Coding installment, where I’ll give you more reasons for wanting to learn LaTeX!