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

## On Coding III: LISP to Mathematica

The last installment of my coding autobiography was an introduction to LISP.  I’d like to continue that discussion today as a segue to talking about Mathematica, because the way I program in Mathematica is heavily influenced by my experience with LISP.

This week I’ll focus on what are typically referred to as aspects of functional programming.  Rather than try to explain by using a definition (you can always google it), I’d like to show how I’d perform a simple calculation, like adding the sum of the squares of the first n integers.

Here’s a simple snippet of code which performs this task in Python:

Of course you could embed the square function in the loop, but for more complicated functions, this is not usually done.  In any case, I’m using this approach to illustrate a point.

Now in Mathematica, I would write:

You might think that there’s no way the code could be shrunk that much, but it really is possible.  Let’s see why.

We’ll look at the “# * # &” piece first.  This is usually called a pure function, and is essentially a function with no name.  It’s like defining f(#) to be # * #, and then invoking f.  But with the “#” as the argument to the function, this syntax allows you to avoid naming the function altogether.

Why might you want to do this?  One reason is it makes your code less cluttered if you need to define a relatively simple function and use it just once.  I actually use pure functions a lot.  Once you start thinking about programming with them in mind, it really does help streamline your code.  You find you can’t live without them, and when you use a language which doesn’t allow them, you really miss ’em….

What about the “/@”?  This is a map, and is the alternative to iteration in LISP.  What it says is this:  “Here is a function, and here is a list of arguments.  Apply the function to each of the elements of the list in order, and collect the results in a new list.”  So

# * # & /@ {1,2,3}

would return the list {1,4,9}.

In languages like LISP and Mathematica, the use of maps is built in to the heart of the compilers, so that maps are often much faster than iterating.  In fact, to add the squares of the first 1,000,000 integers, it’s about 40 times faster in Mathematica to use a map than to use a loop. I can remember a time I was using iteration to create fractals in Mathematica, and it was taking around 10 minutes to generate each one.  For fun, I thought I’d try using maps, and the run time decreased to less than 30 seconds!  It can really make a difference.

There are more complicated ways to use maps which involve functions of more than one argument, and assembling arguments from lists in different ways.  But the example above illustrates the basic idea.

Of course the use of Range[n] is familiar to Python users, and returns a list of the first n integers, starting with 1 — unlike Python, though, where the list begins at 0.  Personally, for much of what I do, I much prefer the list to begin at 1.  I tend to use “i+1” a lot when I use range(n) in Python.

Finally, what about the “@@”?  This is like the apply function in LISP I described in my last post.  Essentially, it means take this function, Plus, and apply it to this list of numbers, in this case the squares of the first n integers.  It saves having to write a loop which successively adds each next number to a running total.  As an example, it is easy to write a factorial function in Mathematica:

Times @@ Range[n].

So that’s how to sum the squares of the first n integers in just a half line of code!  Now these ideas can all be implemented in LISP and Python as well, and other languages which include more functional apsects.  But for simplicity of syntax, I prefer Mathematica over the others.

The point of using Mathematica code for this example is to show how my style of programming in Mathematica is really very LISP-like.  In fact, I’ve had the experience of showing code like this to some Mathematica programmers, and needing to explain it just like I did for you here.  This is because if you learned a language like PASCAL, C, or some other procedural language, you can code in Mathematica exactly the same way, without ever knowing anything about the functional aspects.

Back to a little history….  I did all my undergraduate and graduate work at Carnegie Mellon, and beginning with my sophomore year as an undergrad, was working a lot with LISP while teaching with the PGSS.  Mathematica was first released during my second year of graduate school, and CMU being the type of school it was, Mathematica was readily available.  I can recall working with it on a NeXT computer.  (Google it!)

So I was introduced to Mathematica while I was heavily into LISP — and found that I was really excited that I could do so many LISP-like things in Mathematica!  More about Mathematica in my next installment of On Coding….

Frankly, I rarely use LISP now.  I do recall creating an address book in LISP — having a list of addresses and phone numbers in a long list, and using LISP to output LaTeX code which I could then run and print out a nicely formatted array of addresses.  But other than that, little else comes to mind.

But although I don’t use the language itself, learning to program in LISP has definitely influenced my programming style more than any other coding experience.  I always encourage my students to study it as a result — although functional programming ideas are now incorporated into many other languages, it’s easy to learn the concepts elsewhere.

For me, I’ll always  have a special place in my hacker heart for all those idiotic stupid parentheses….

## On Coding II: LISP

During my sophomore year of college at Carnegie Mellon, I got a job in the psychology department as an assistant programmer for a professor working on neural nets.  The language being used was LISP, and the first order of business was to learn it.  I even got paid while I was learning, which I thought was pretty amazing at the time!

I would say working with LISP over the next several years had a huge impact on my life as a programmer — moreso than working with any other language.  So I’d like to devote today’s post to the wonderful world of LISP….

LISP (which stands for LISt Processing) is an example of a functional programming language. I talked a little about procedural programming languages earlier, so today I’ll describe some functional aspects of LISP.  Of course there is no substitute for just diving in and learning it yourself….

Why did I spend so many years programming in LISP?  I worked a few hours a week as a math tutor, so my interest in teaching was already blossoming.  In the Spring of my sophomore year, my roommate heard about a summer program for talented math and science students, and suggested I look into it.  Computer science was one of the courses, and the language being taught was — you guessed it — LISP.  I could hardly believe it!

So I spent ten summers teaching LISP at the Pennsylvania Governor’s School for the Sciences.  I started as a teaching assistant, but eventually became the instructor for the lab course and director of student projects in computer science when I was in graduate school at CMU.

The reason LISP was the language taught, incidentally, was because the students were a particularly bright bunch — only the top two students from each county in the state were accepted.  Many of them already had programming experience — but BASIC and PASCAL were the popular languages at the time for high school students.  It was thought that LISP would level the playing field, as it were.  I can’t recall that any student ever had experience with LISP before.

What makes LISP so different?  Certainly its structure — everything is a list.   Even function calls!  So to add two numbers, you’d write

(plus 3 4).

The first element of this list is the function name, then the arguments follow later.

How do you distinguish lists from function calls?   Consider the function call

(append ‘(1 2 3) ‘(4 5 6))

This does what you’d expect — concatenates two lists together.  The single quote indicates the list represents a pure data structure; you aren’t applying the function “1” with arguments “2” and “3.”  The quote suspends evaluation of the list.

So data structures and function calls look the same.  But here’s what’s neat.  You can write commands like

(eval ‘(plus 3 4)).

The function eval evaluates the list as a function call.  So this is equivalent to (plus 3 4).  Now think about this for a moment.  It’s like taking a string like “3+4” in a language like C and saying “interpret this string as an arithmetic expression.”  Nope, can’t do it.  You’d need to write a parser to do that — and writing a parser isn’t a simple undertaking.

This means you can build function calls as lists and evaluate them, as in

(eval (cons ‘plus ‘(3 4))),

where cons is the constructor function which inserts an element into the front of the list.  (And as you read through the examples, you’ll understand the joke that LISP stands for “Lots of Idiotic Stupid Parentheses.”)

One reason this is even possible is that LISP is not a typed language.  In other words, what the ‘plus means depends on how it’s used — it has no predefined type.  Of course if you use it the wrong way, you’ll get an error — or perhaps not.  LISP will try its best to evaluate what you give it, and may find a way, but it may not be what you intended….

So there are lots of predicates in LISP, like listp, which tells you if something is a list or not.  For example, (listp ‘(1 2 3)) would be true, while (listp 2) would be false.  Some languages are so heavily typed that all variables must be given a type when they’re declared.

I think the ability to construct function calls and evaluate them is one of the major differences between a functional programming language like LISP and other languages.  It might not seem such a big deal at first, but really understanding this idea has definitely impacted the way I think about programming.

Another aspect of the course I TAed which made an impact was the avoidance of loops and variable assignments.  Yes, there are loops and variable assignments in LISP, but the style of the course was to avoid them — in other words, it got students (and me!) to think outside the procedural programming box.

This style of programming is not inherent in functional programming, but it was so significant in my learning, it deserves a few words.

The natural alternative to loops is recursion.  You can write recursive functions in any programming language, but when it’s your only option, you often have to get creative.  So I had to think recursively about everything, not just arithmetic operations, such as in recursively defining the factorial or the Fibonacci numbers.  I got pretty good at recursion.

So much so, that when I submitted a multi-procedure program in one of my CS courses at CMU — where I implemented every loop recursively — I was penalized.  Why?  Because in most languages, recursion has more overhead and is less efficient.  Moreover, there is usually a limit imposed to the depth of recursive calls, so in some languages, you can only use recursion up to a point.  There are pros and cons to using recursion.

Avoiding variable assignments forces you to think about function parameters.  If I wanted to add the sum of the squares of the numbers from 1 to n recursively and avoiding variable assignments, here is what I would do in Python:

So you would have to call sumsquares with an additional argument, as in

sumsquares(10, 0).

This essentially initializes the result to 0 before it’s incremented.

Wow, I didn’t know I had so much to say about LISP!  So stay tuned for the next installment of On Coding, where I continue to describe how working with LISP expanded my programming mind in so many different directions….