## 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.

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:

\begin{exercise}

{….the exercise….}

{….the solution….}

\end{exercise}

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

$\tan\dfrac{\theta}{2}=\dfrac{\sin\theta}{1+\cos\theta},$

you would type

$$\tan\frac{\theta}{2}=\frac{\sin\theta}{1+\cos\theta}$$.

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

\def\ra{\rightarrow}

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. \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
2. \label{theorem1}

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

$$<stuff>\label{eq1}\nonumber$$.

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!

## On Coding VI: HTML

In the last installment of On Coding, I talked about my love for Postscript.  In the next few installments, I’ll talk about my favorite markup languages, HTML (which stands for Hypertext Markup Language) and LaTeX.

Technically speaking, using a markup language isn’t really coding.  There isn’t any sort of algorithmic thinking going on when you type

<b>make this text bold!</b>

to make text bold in HTML.  But it is easy to use coding constructs in both HTML and LaTeX, for example when embedding JavaScript in HTML or by writing macros or using the graphics package TikZ in LaTeX.

I do think, though, having students learn a markup language is a great introduction to programming.  It gets students in the mindset that a particular set of instructions has a predictable, well-defined effect.  Perhaps more importantly, getting the syntax correct when using a markup language is just as important as it is when coding.

I started using HTML in the early 90’s, when I made my first web pages.  I don’t have those older designs any more — but they were still based on geometry, like my current website.  I do have a copy of the version just before this, though.

Of course I have always loved pentominoes, polyominoes, and puzzles.  But one reason I went with this theme was I could essentially build my home page by using a table in HTML.

Tables are currently out of fashion, though — the thought is that with all the new capabilities in CSS (cascading style sheets), tables shouldn’t be used for layout purposes.  That may be so.  But it took some effort to get everything to work initially, and creating new pages with similar functionality is easy now that I have a template created.  So I am content to be out of fasion….

Being a programmer, though, made be decide to use HTML itself, rather than some web-designing software.  The reason is simple.  If I write my own HTML, I can do whatever I want.  If I use some canned software, I can only do what the software lets me.  And since I’m pretty particular about what my web pages look like, I don’t want to be in the position of having a design idea in my mind, but not being able to implement it because of the limitations of the software.

One of my favorite designs was a website I created when I did some educational consulting in Thailand.

The polyomino theme is pretty clear — in this case, I used all 35 hexominoes plus six 1 x 1 squares.  If you look closely, you’ll see the six places where a square of the tiled background peeps through.  I included these six squares so I could tile a 12 x 18 rectangle.

And why did I want to be so specific?  Actually, the flag of Thailand has proportions of 2 : 3.  Moreover, the stripes alternate red, white, blue, white, and red, with the blue stripe twice a wide as the others.

So I decided to design a web page for my trip based precisely on the dimensions of the Thai flag.

It was difficult.  What made it so hard was that I wanted each hexomino to be a different color — but all the squares in any given hexomino had to be the same color.  And I had to make the five colored stripes.

So I actually cut out the 35 hexominoes and set down to work — but was constrained by the fact that I basically had to use all the pieces lengthwise since the stripes needed to be horizontal.  If you want a real polyomino challenge, try it yourself!  You’ll see it isn’t all that easy.

Two overriding principles guide my use of HTML:  functionality and minimalism.  My websites are essentially a professional portfolio.  So they have to be easy to navigate.  The polyomino theme allows me to include all important links on one page — and they’re all easily visible.  Moreover, it’s easy to add or take away a link without disturbing the overall design.  Here’s a snapshot of my current homepage.

I also use websites when I teach, rather than an online platform like Moodle, for example.  This is because I can archive them — and again, I have complete control over content.  Further, when teaching a course like my Mathematics and Digital Art course, I can share all my course content with colleagues, who otherwise wouldn’t have access to it on a school content management platform.

Within each course web page, I also strive for ease of use.  For example, links are always in bold face, so they’re easy to spot.  I find that making them a different color is too distracting, so I alter the typeface instead.  And I use an anchor

<a name=”currentweek”>

when I update course content — so when a student clicks on the course website, they don’t have to scroll down the page to find the new stuff.  It’s automatically at the top.  Students have commented that they like this feature of my course web pages.

I’m a minimalist when it comes to design.  The difficulty with web design is because you can do so much, some web designers think they should.  The challenge is to select design elements that work together, achieve the web pages’ purpose, and have a strong aesthetic appeal.  Less is often more, to use a cliche.

I feel especially strongly about this when it comes to using color.  Yes, you typically have 16,777,216 possible color choices when designing web pages.  But that doesn’t mean you have to use them all!  When I look at some sites, I get the feeling that the web designers were trying to….

In fact, another favorite design — my digital art website — is entirely in gray scale.

I use a bold, black-and-white variant of the yin-yang symbol to attract attention.  No need to splash countless colors indiscriminately across the page….

I have enjoyed designing my own web pages, and I’ll continue to do so — every so many years, I get tired of the existing design and need to create a new one.  And if you already code, it’s easy to pick up a markup language like HTML.  You can always view the source code of any website, and you can just look up anything else you need online.  Give it a try!

## On Coding V: Postscript

It has been a while since my last On Coding installment — I talked about Mathematica and functional programming.  Now its time to talk about one of my favorite programming languages:  Postscript!

Chronologically, we’re back in my undergraduate days, around sophomore year.  Recall that means no laptops, no slick user interfaces, no real windows environments like we know today.  This meant if you wanted to play around wtih computer graphics, you had to go to a computer lab and write code.  Postscript was the language of choice.

And get this.  The only way to see if you wrote your code correctly was to print out your graphics.  No fancy clicking your mouse and having the image rendered on your screen.  This meant debugging wasn’t so easy….

Two important features of Postscript are that it’s a stack-based language, and the notation is postfix — meaning the arguments come before the function call.  Just like my HP-15C programmable calculator, which is still functioning perfectly despite being over thirty years old.  It’s my go-to calculator when I want to make quick calculations.

I won’t go into detail here, since I discussed these two features at length in my Day037 blog post, Fractals VIII: PostScript Programming.  Feel free to go back and refresh your memory if you need to….

What I will discuss today are the two primary things I use Postscript for now:  iterated function systems and L-systems.

OK, I won’t really discuss iterated function systems as far as the algorithm is concerned…I’ve talked a lot about that before.  But what’s significant is that’s when I started getting hooked on fractals.  I had read about IFS in a paper by Michael Barnsley (before his famous Fractals Everywhere was written) just a few years after Mandelbrot’s The Fractal Geometry of Nature was first published.  Fractals weren’t so well-known at the time, but they were making quite a buzz in the mathematical community.

What was really neat was that I could make my own fractals in Postscript.  I was really struck by the wide variety of images you could make with just two affine transformations.  My favorite is still The Beetle.

Now this particular image didn’t get rendered in Postscript until much later (my files are dated 1998), but the seeds were well-planted.  And fortunately, by then, there were nice GUIs so I didn’t have to rely on printing each image to see what it looked like….  I still use my old Postscript code to teach IFS occasionally, as I did with Thomas.

The other significant use of Postscript is in modeling L-systems (I’ve talked about these before, here is a nice Wikipedia page on the subject).  In particular, I implemented basic turtle graphics routines so I could imitate many of the well-known algorithms for creating fractals like the Koch and dragon curves.

Of course these algorithms could be implemented in any programming language.  But I didn’t have access to Mathematica at the time, I loved Postscript, and it was open source.  So it was a natural choice for me.

For the graphics programmer, there are a few particularly useful functions in Postscript, gsave and grestore.  These functions save and restore (respectively) what is called the graphics state.  In other words, if you are creating a graphical object, and would like to create another and return where you left off, you would invoke gsave, go do your other bit, and then use grestore to return where you left off.  Like a stack for graphics.

What this does is save all the parameters which influence how graphics are drawn — the current origin, rotation of axes, line thickness, color, dash pattern for lines, etc.  And there are a lot of such parameters possible in Postscript.

And while you might not think this is a really interesting feature, it’s great for working with L-systems, especially bracketed L-systems.  You might recall that a very basic binary tree is represented by the bracketed L-system

$T(s)\rightarrow F(s)\, [\, +\, T (r s)] \, [ \,-\, T(r s)].$

Basically, this means that a tree T is drawn first by moving forward some length s.  Remember where you are (“[“), then, turn left some given angle, and then draw a tree whose beginning segment has length rs, where r is less than 1, so that the left branch is a self-similar version of the whole tree.  Finish that tree (“]”), and go back to where you were. Then repeat on the right-hand side.  Here is a simple example with a branching angle of 45 degrees, and a branching ratio of 0.58.

You might have guessed the punch line by now:  use gsave for “[” and grestore for “].”  Really nice!  There are a few other subtleties to take care of, like remembering the depth as you go along, but the gsave and grestore functions essentially make implementing bracketed L-systems fairly easy in Postscript.

While I now use Postscript primarily for IFS and L-systems today, I’ve had other adventures with Postscript over the years.  Before they were easily available online in other places, I used Postscript to create dozens of nets for making polyhedra, such as the net for the rhombic dodecahedron shown below.

I had taught a course on polyhedra and geodesic structures for many years, so it was convenient to be able to make nets for classroom use.

I also played with designing fonts for a while (though I think those files are gone forever), and enjoyed designing stationery as well.  Here was one of my favorites.

I just printed this motif on some nice paper, and used it to write letters — back in the day when people actually wrote letters!  It was fun experimenting with graphic design.

True, not many people program in Postscript now, since there are so many other options for producing graphics.  But I do always encourage students to dabble for a bit if they can.  Programming in Postscript gets you thinking in postfix and also thinking about stacks.  And while you may not use these concepts every day when programming, it’s good to have them in your coding arsenal.  Gives you more options.

In the next installment, I’ll talk about markup languages — $LaTeX$ and HTML.  Until then!

## On Coding IV: Mathematica

In my last installment of “On Coding,” I talked more about functional proramming and how working with LISP so heavily influenced my coding in Mathematica.  To continue the thread, I’ll need to jump ahead on my timeline, since a lot of what I’ll say applies to my current use of Mathematica.  Then next time, I’ll need to jump back to my college days since I was also learning Postscript in parallel with LISP and Mathematica.

One nice feature of LISP and Mathematica interfaces is that they’re interpreters, meaning you interact directly with the kernel.  I can just type “3 + 2” and get a return value of 5, without needing to put the expression in a wrapper function.  This makes is easy to try out new functions.  And in Mathematica, there are thousands of functions — so lots to try out!

But aside from functional programming aspects, I think one fundamental advantage of using LISP or Mathematica is the fundamental data structure:  a list “(  )” in LISP, or “{  }” in Mathematica.  This is a fluid, untyped data structure, and is perhaps the most general way to store data.

In many languages, variables are typed.  That means if you want an array, you have to say what is in the array.  Is it an array of integers?  String?  Reals?  You can’t mix and match.

In Mathematica (and other languages as well, like Python), there are no restrictions as to what goes in a list.  So you can have a list like

{42, 3.1416, “Hello world!”, {0, 1, 2}},

and that would be no problem at all.

This is actually a very nice feature, but you do have to be careful.  If you try evaluating

Plus @@ {42, 3.1416, “Hello world!”, {0, 1, 2}},

you actually get

{45.1416 + “Hello World!”, 46.1416 + “Hello World!”, 47.1416 + “Hello World!”}!

The reason is that the “+” operator in Mathematica is overloaded, meaning it performs differently depending on what the arguments are.

The 42 + 3.1416 = 45.1416 is evaluated first.  Now a real can’t be added to a string, so Mathematics leaves the expression in an abstract form,

45.1416 + “Hello World!”,

without actually evaluating.  But when {0, 1, 2} is finally added, the “+” operator adds 45.1416 + “Hello World!” to each element of the list, and returns the resulting list.  Of course addition is commutative, so 0, 1, and 2 are added to the real part of the expression.

In a language like C++ or even Python, this would be unthinkable.  You’d get an error message right away.  But in Mathematica, all would be well — almost.  If you made a typo in your list of objects to add and Mathematica found a way to add them, you might get some rather bizarre behavior if that result were passed to some other function.  In other words, you’ve just got to be careful.

This fluidity makes creating graphics easy, in my opinion.  A graphics object is essentially a list of directives and objects, like

{Blue, Line[{{0,0}, {1,1}}], Red, Disk[{2,2}, 1]}.

Mathematica interprets this as follows.  First, make the stroke color Blue, and draw a line from (0,0) to (1,1).  Change the stroke color to Red, and then draw a disk of radius 1 centered at (2,2).

This loose structure makes creating graphics objects simple, as all you’re doing is building a list.  And that list contains a series of instructions about how to create an image.

There’s a slight drawback, for me at least.  I get frustrated sometimes when I program in a language like Python, where data structures enclosed in “[  ]” might be lists, tuples, or vectors, for example.  You often need to explicitly say what you want, as in using the function

vector([0, 1, 2]).

This is highly annoying to the Mathematica programmer, who thinks Python should be clever enough to figure it out….  So I find myself always looking up what type of argument is passed to a certain function to make sure I don’t get a runtime error.

Another advantage of using LISP and Mathematica, in my opinion, is that the return value of a function is the last statement executed.  This is a very nice feature — once you get used to it, you can’t image how you ever lived without it….

Let’s look at a simple example which takes advantage of this feature and uses some functional programming ideas.  Here’s the Python code:

Nothing complicated going on here, just add two variables based on whether one of them is positive or not.  Here is the Mathematica code:

Yes, it’s really just one line!  The If statement returns the function “Plus” if the variable x is positive, and the function “Times” otherwise.  This return value can be immediately applied to the list containing x and y in order to carry out the desired operation.

Unless you’ve worked with a functional programming language before, this type of coding construct might seem a little strange.  But once you get used to thinking this way, you really can code more efficiently.

I also like that the decision about what function to used is very clearly based on whether the variable x is positive or not, since the If statement returns the name of a function.  Of course it’s clear in the Python code since the example is so simple, but the Mathematica code really drives the point home.

The one drawback for me is forgetting the “return” statement in Python all the time.  I’m so used to this feature in Mathematica that it’s automatic in my thinking about code.

The list structure and how return values are handled, in additional to the functional programming aspects, are the two features which most directly impact the way I write code in Mathematica.  But I can’t end this discussion without saying a few words about graphics.

I enjoy the absolute control you have about every feature in Mathematica.  You essentially have a blank slate, and can put just about anything you want anywhere you want.  I’ve never used a user interface to create graphics, and never will.

The reason is that you are often constrained by the available options with a GUI.  Not so in Mathematica.  Essentially, if you can conceive it, you can implement it.  It may take some time and a lot of code, but it can be done….

So that briefly summarizes my relationship with Mathematica, which is ongoing.  Next time, Postscript!