Message #1734

From: Melinda Green <>
Subject: Re: [MC4D] puzzle avalanche continues
Date: Sun, 22 May 2011 01:57:50 -0700

On 5/21/2011 10:46 PM, Roice Nelson wrote:
> The ultraparallel lines are indeed beautiful. Can the edges be
> adjusted so that those lines are straight rather than bumping along?
> Can you send me an image of the bumping you are seeing? I uploaded a
> pic of a {5,4}
> <,4%7D.png> as it is
> rendering for me, and all the ultra-parallel lines of cell boundaries
> appear as nice, smooth arcs.

Now I’m not sure which puzzle I was commenting on. Looking again, the 6
color {5,5} is the only "petals" puzzle that look bumpy. All the rest
are smooth arcs.

> Still haven’t figured out the 8-color {5,5}. I don’t know how
> pretty or interesting it may turn out to be but it is definitely
> close to my heart, topologically at least.
> I think I’ll play with this some. I’ve since realized a puzzle based
> on this coloring may still be possible… if the twisting circles are
> smaller than the circumcircle for a face, we can keep them from
> intersecting.
> I would like to name your 9-color edge turning {4,4} to be the
> "Harlequin" tiling.
> Done, and uploaded
> <> :)
> Naming is something I wish I was more creative with, so if anybody
> else is struck by names they like, please let me know!
> I probably should wait longer before mentioning this (until things are
> more stable), but if anyone would like to try to make their own
> puzzles, you can copy some of the existing puzzles in the
> config/puzzles directory to the config/user directory to use as a
> template, then edit them. They will then show up in the menu, and if
> you create any good ones, you can send them to me to include in the
> standard list of puzzles. The display name is just one of the xml
> nodes, so you can be free to give your creations any unique name you’d
> like. Strange configurations can easily make the program puke, which
> is why this suggestion is probably premature. I’ll plan to do a round
> to make failures in this area more robust, but will throw caution to
> the wind in the mean time. Just be warned :)
> Regarding calculating genus, it is not difficult though you do
> have to be extremely cautious in your counting. You need to count
> the number of *unique* vertices, edges and faces in a single
> minimal repeat unit and plug those values into the Euler formula
> F-E+V = 2-2g and solve for g. Just go super slow so that you don’t
> skip any unique elements or count any more than once. For
> instance, a simple toroidal {4,4} repeat unit is a simple open
> cylinder with exactly 4 vertices, 4 horizontal and 4 vertical
> edges, and 4 faces. Plugging into the Euler formula you get 4 - 8
> + 4 = 2 - 2g. Solving for g we get g = (0- 2)/-2 = 1 which is
> what we would expect for any torus. See here
> <> for the
> complete description with diagrams.
> Awesome, thanks! The great thing about this is that with the "show
> only fundamental" setting, counting these elements is greatly
> simplified. In fact, with your description, I may very well be able
> to automate the genus calculation in code :)

Yea! I’m just glad that I had something mathematical to contribute.

Having the software do the arithmetic is a great idea because it is *so*
easy to mess up when attempting it by hand. Before I got the above right
I made the classic mistake of dropping a minus sign and ended up asking
myself for about the hundredth time whether a surface with a negative
genus makes any sense. (It doesn’t)

Another possible way to screw up is to choose a repeat unit that is not
minimal. Sometimes it’s easier to build a tiled surface from some
multiple of minimal repeat units, but you can’t use them to compute the
genus of the surface. So it’s very possible for someone builds a puzzle
that way causing your code to produce the wrong genus. I guess that any
way you do it you still need to be very careful. Be warned indeed! :-)