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

## Imagifractalous! 3: Fractal Binary Trees

I’ve taken a break from Koch-like curves and p-adic sequences for an arboreal interlude….  Yes, there’s a story about why — I needed to work with Nick on a paper he was writing for Bridges — but that story isn’t quite finished yet.  When it is, I’ll tell it.  But for now, I thought I’d share some of the fascinating images we created along the way.

Let’s start with a few examples of simple binary trees.  If you want to see more, just do a quick online search — there are lots of fractal trees out there on the web!  The construction is pretty straightforward.  Start by drawing a vertical trunk of length 1.  Then, move left and right some specified angle, and draw a branch of some length r < 1.  Recursively repeat from where you left off, always adding two more smaller branches at the tip of each branch you’ve already drawn.

If you look at these two examples for a moment, you’ll get the idea.  Here, the angle used is 40 degrees, and the ratio is 5/8.  On the left, there are 5 iterations of the recursive drawing, and there are 6 iterations on the right.

Here’s another example with a lot more interaction among the branches.

This type of fractal binary tree has been studied quite a bit.  There is a well-known paper by Mandelbrot and Frame which discusses these trees, but it’s not available without paying for it.  So here is a paper by Pons which addresses the same issues, but is available online.  It’s an interesting read, but be forewarned that there’s a lot of mathematics in it!

In trying to understand various properties of these fractal trees, it’s natural to write code which creates them.  But here’s the interesting thing about writing programs like that — once they’re written, you can input anything you like!  Who says that r has to be less than 1?  The tree above is a nice example of a fractal tree with r = 1.  All the branches are of the same length, and there is a lot of overlap.  This helps create an interesting texture.

But here’s the catch.  The more iterations you go, the bigger the tree gets.  In a mathematical sense, the iterations are said to be unbounded.  But when Mathematica outputs a graphic, it is automatically scaled to fit your viewing window.  So in practice, you don’t really care how large the tree gets, since it will automatically be scaled down so the entire tree is visible.

It is important to note that when r < 1, the trees are bounded, so they are easier to study mathematically.  The paper Nick and I are working on scales unbounded trees so they are more accessible, but as I said, I’ll talk more about this in a later post.

Here are a few examples with r > 1.  Notice that as there are more and more iterations, the branches keep getting larger.  This creates a very different type of binary tree, and again, a tree which keeps getting bigger (and unbounded) as the number of iterations increases.  But as mentioned earlier, Mathematica will automatically scale an image, so these trees are easy to generate and look at.

Nick created the following image using copies of binary trees with r approximately equal to 1.04.  The ever-expanding branches allow for the creation of interesting textures you really can’t achieve when r < 1.

Another of my favorites is the following tree, created with r = 1.  The angle used, though, is 90.9 degrees.  Making the angle just slightly larger than a right angle creates an interesting visual effect.

But the exploration didn’t stop with just varying r so it could take on values 1 or greater.  I started thinking about other ways to alter the parameters used to create fractal binary trees.

For example, why does r have to stay the same at each iteration?  Well, it doesn’t!  The following image was created using values of r which alternate between iterations.

And the values of r can vary in other ways from iteration to iteration.  There is a lot more to investigate, such as generating a binary tree from any sequence of r values.  But studying these mathematically may be somewhat more difficult….

Now in a typical binary tree, the angle you branch to the left is the same as the angle you branch to the right.  Of course these two angles don’t have to be the same.  What happens if the branching angle to the left is different from the branching angle to the right?  Below is one possibility.

And for another possibility?  What if you choose two different angles, but have the computer randomly decide which is used to branch left/right at each iteration?  What then?

Here is one example, where the branching angles are 45 and 90 degrees, but which is left or right is chosen randomly (with equal probability) at each iteration.  Gives the fractal tree a funky feel….

You might have noticed that none of these images are in color.  One very practial reason is that for writing Bridges papers, you need to make sure your images look OK printed in black-and-white, since the book of conference papers is not printed in color.

But there’s another reason I didn’t include color images in this post.  Yes, I’ve got plenty…and I will share them with you later.  What I want to communicate is the amazing variety of textures available by using a simple algorithm to create binary trees.  Nick and I never imagined there would be such a fantastic range of images we could create.  But there are.  You’ve just seen them.

Once the Bridges paper is submitted, accepted (hopefully!), and revised, I’ll continue the story of our arboreal adventure.  There is a lot more to share, and it will certainly be worth the wait!

## What is a Geometry?

This might sound like an odd question — most students seem to think so when I ask it.

The reason it sounds a little strange is that most students — even when I taught at a magnet STEM high school — think there’s just one type of geometry:  Euclidean geometry.  This isn’t surprising given the typical K-12 mathematics curriculum, and it’s not necessarily problematic, either.  But by the time students graduate from high school, they really should be aware that Euclidean geometry is just one among many different possible geometries.

Why should students be aware of other geometries?  Most will never need to use any geometry other than Euclidean in their day-to-day lives.  In my opinion, one compelling reason is that  you can get at a really big idea (the concept of a geometry) with very little effort, really.

Let’s look at a simple example for a moment:  spherical geometry.  Let’s define Point and Line in this geometrical framework, where I use capital letters to distinguish from the ideas of points and lines in our usual Euclidean geometry.

Imagine confining our attention to the surface of a sphere, and say that a “Point” is a pair of opposite points on a sphere (like the North pole and South pole), and that a “Line” is a great circle on the sphere, like the Equator or a line of longitude.  (Note how we use the term “line of longitude,” even though this line is in fact a circle!)

With these definitions, we offer our first Thereom of spherical geometry:  Any two Lines intersect in exactly one Point.  Now if you’ve got a globe in your room, this is easy to demonstrate.  Any two Lines of longitude intersect in one Point (consisting of the North and South poles), and it is also easy to see that the Equator intersects any Line of longitude in exactly one Point.

But, you might object, you just defined Points and Lines in some arbitrary way!  How can you just do that?  The simple answer is that this is precisely how you define a geometry.  The concepts of “point” and “line” depend on the geometrical context.  And since we’re looking at the surface of a sphere, a “line” just can’t mean the same thing as it does in Euclidean geometry.

OK, you might respond, but what about your definition of “Point”?  Surely that’s a bit off!  How can a “Point” be two “points”?  And why are your Lines only great circles?  What about other circles on a sphere, like lines of latitude?  Why don’t you include these as well?

This is a valid objection, and there is nothing preventing it.  But when you try to actually study the geometry defined in this way, it’s hard to make progress.  For example, two lines defined in this way could intersect in 0, 1, or 2 points.  And given any two points, there would be infinitely many lines passing through these points.

But with the definition of Point and Line as given earlier, we have two very nice results:  Any two Lines intersect in exactly one Point, and there is exactly one Line passing through any two distinct Points.  No ambiguity here — 0, 1, 2, or infinity.  All we need is 1.

So while in a technical sense, you can define basic ideas like “Point” and “Line” any way you like, in a practical, mathematical sense, your definitions should be useful.

Yes, useful.  We usually don’t think of definitions in this way, but mathematically, it really is necessary.  With your definitions and axioms, you want to prove interesting theorems.  If your definition of lines allows two distinct lines to intersect in any number of points, well, you haven’t really said very much.  Your definitions don’t get you anywhwere.

So what makes a definition useful?  Though perhaps stating the obvious, a definition is useful if other people actually use it.  Do other mathematicians think your construct allows for interesting results?  Can it be applied in other ways as an aid to learning about other areas of mathematics?  Are others interested enough in your mathematical system that they want to see what results they can come up with?

In a real sense, anyone can write down a few definitions and maybe state a simple theorem or two.  But you’ve got to convince others to care about what you’ve created.

So what has this got to do with Points and Lines?  These definitions are just the beginning of spherical geometry, which leads to spherical trigonometry and other areas as well.

And why do we care?  Among applications in studying spherical triangles and polyhedra, we think of spherical geometry when we ask a practical question such as, “What is the shortest flight path between two cities?”  It turns out the that shortest flight path is along a Line on the sphere, just as the shortest distance between two points is along a line in the Euclidean plane.

If you’ve been paying attention, you will also have noticed one important consequence of the theorem that any two Lines intersect in exactly one Point:  there are no parallel Lines on a sphere.  Simply put, any two lines intersect.

This means that spherical geometry is in some fundamental way different from Euclidean geometry, where it is possible for two lines to avoid intersecting.  In other words, we’ve created an entire world of Points and Lines distinct from the one we are familiar with, together with many interesting properties — some of which are just like those in the Euclidean world, while others are quite different.  We’ve created a new geometry.

What I’ll be doing in the posts in this series is gradually introducing you to different non-Euclidean geometries.  In this way, I hope you’ll develop an intuition for what a geometry is.  How concepts like point, line, angle, and circle seem fairly natural in various contexts, even though they may not be exactly like what you’re familiar with in Euclidean geometry.  But why, nonetheless, we still call these systems geometries.

Now the question has been thoroughly asked:  What is a geometry?   Hopefully, by the end of the series, you’ll be able to formulate your own answer to this new question — one you may never have asked yourself before.  But one question that is well worth answering.

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

## The Ravioli Equation

I was in The Hill in St. Louis recently — that’s the really amazing Italian neighborhood in the city.  Had lunch there twice, actually, and it brought back memories of my trip to Florence.

I then remembered that I started working on a post a while back, but never quite finished.  An equation for ravioli.  Here it is:

$\left(r-\dfrac1{(\cos^6\theta+\sin^6\theta)^{1/6}}-0.03 \arccos(\cos(24\theta))\right)\times$

$\hbox{ } \qquad\qquad\qquad\qquad\left(r-\dfrac{0.7}{(\cos^6\theta+\sin^6\theta)^{1/6}}\right)=0.$

Looks a little complicated, but here is what you get when you graph it:

Yep, ravioli!  So I thought I’d talk about how I came up with The Ravioli Equation.  Not very deep, but there are a few interesting mathematical tidbits hiding in it.

Let’s look at the central mound — the curve which outlines all the deliciously stuffed goodness in the ravioli.  I note that the ravioli in the picture above has a sauce of nuts and sage in butter, but I don’t capture that in the equation….

This is an example of a superellipse, which is a generalization of the ellipse.  It has equation

$\left|\dfrac xa\right|^n+\left|\dfrac yb\right|^n=1,$

where a and b are positive numbers.  Of course when $n=2,$ you get an ordinary ellipse, but for different n, you get other curves.

The parameters a and b are called semi-diameters of the superellipse, much like the semi-axes of an ellipse.  Because ravioli are basically square, I set $a=b,$ so that the superellipse equation looks like

$|x|^n+|y|^n=a^n.$

Below are a few examples with a = 1 and n being 1/2, 2, and 4 (from left to right).

So you can see that the larger n gets, the more the superellipse looks like a square.  I thought that a value of n = 6 looked just about right for ravioli.

Because I wanted the outer edge of the ravioli to have a radius of approximately 1, I used a value of a = 0.7 for the inner mound.

I should say a few words about using polar coordinates.  Since superellipses are easily described with Cartesian coordinates, why bother to convert to polar?  Well, I needed to get the scalloped ravioli edge.  To show a simple example, consider a plot of the polar function

$r=1+0.1\cos(12 \theta),\qquad 0\le\theta<2\pi.$

Here’s what it looks like:

Notice how adding the additional cosine term to r makes the circle “oscillate” as $\theta$ moves around the circle.  Also notice how the coefficient of $\theta$ tells you how many scallops there are around the edge.

This is a fairly simple way to produce something that looks like the edges of ravioli, so I decided to use polar coordinates for everything.  Of course you remember the conversion, based on the definition of sine and cosine:

$x=r\cos\theta,\quad y=r\sin\theta.$

Substituting into the superellipse equation gives

$|r\cos\theta|^n+|r\sin\theta|^n=a^n,$

and solving for r results in

$r=\dfrac{a}{(|\cos\theta|^n+|\sin\theta|^n)^{1/n}}.$

And of course when n is even, the absolute value signs aren’t necessary.  So this gives the equation for the inner mound as

$r=\dfrac{0.7}{(\cos^6\theta+\sin^6\theta)^{1/6}}.$

Now let’s move on to the outer, scalloped edge of the ravioli.  Let’s first look at the following polar function, which is basically a superellipse with some scalloping:

$r=\dfrac{1}{(\cos^6\theta+\sin^6\theta)^{1/6}}+0.03\cos(24\theta).$

It looks like this (graphed together with the inner mound):

You can see the way the scalloping is modified when using a superellipse rather than a circle.  But in my mind, ravioli edges are a bit more “crinkly” than this.  The outer edges of the ravioli were just too smooth.

But there’s a nice fix.  It comes from the fact that the arccos (I prefer this notation for the inverse cosine function, since an exponent of -1 can be ambiguous) function is really not an inverse of the cosine function, since the graph of the cosine function fails the horizontal line test.  So we consider the domain of the arccos function to be $[-1,1]$ and the range to be $[0,\pi].$  In this case, the graph

$y=\arccos(\cos x)$

looks like the line $y=x$ on the interval $[0,\pi].$ But on the interval $[0,4\pi],$ the function $y=\arccos(\cos x)$ looks like

Now it should be clear that this function must be periodic with period $2\pi.$  But what is happening on the interval $[\pi,2\pi]$?  In this case, x is in quadrants III and IV.  Since the range of $\arccos x$ is $[0,\pi],$ we’ve got to flip x over the x-axis — in other words,

$\arccos(\cos x)=2\pi-x.$

You can see that this is the correct equation for the graph on the interval $[\pi,2\pi].$  Add in the periodicity, and there you have it!

Using this new function adds the crinkliness to the ravioli edge.  Delicious!

And for the final equation, we note that if we would like to simultaneously graph $r=f_1(\theta)$ and $r=f_2(\theta),$ we simply graph the equation

$(r-f_1(\theta))\times(r-f_2(\theta))=0.$

So there it is — The Ravioli Equation!  Of course you can change the parameters around to suit your particular taste in pasta.  And you can even fiddle with how the corners of your ravioli look.  Using sine rather than cosine, the equation

$\left(r-\dfrac1{(\cos^6\theta+\sin^6\theta)^{1/6}}-0.03 \arcsin(\sin(24\theta))\right)\times$

$\hbox{ } \qquad\qquad\qquad\qquad\left(r-\dfrac{0.7}{(\cos^6\theta+\sin^6\theta)^{1/6}}\right)=0$

produces the ravioli below.

Does it look tastier than the cosine version?  Hard to decide….

I hope you’ve enjoyed this introduction to the art of mathematical pasta making!  It’s a fun activity, and definitely stimulates the appetite….  If you need some practice, here’s another fabulous dish of ravioli I had in Florence.  Make it!  Mathematically, of course…

Buon appetito!