Regular expressions crossword

On, a crossword puzzle you solve by interpreting regular expressions.

PDF download


  1. The following could be viewed as a very minor spoiler, but might also avoid a great deal of frustration by solvers: Gur ragevrf ner fvzcyl abafrafr fgevatf bs punenpgref, abg jbeqf. Lbh fubhyq guvax bs guvf nf n ybtvp chmmyr, yvxr n infgyl avsgvre Fbqhxh, abg n pebffjbeq. [ROT13]

    1. This puzzle, in particular, makes me cry a little. This Mystery Hunt, in particular, made me cry a little. It is a difficult relationship to love the Mystery Hunt so much sometimes. :)

  2. As Scott has pointed out, this was a puzzle from MIT’s annual Mystery Hunt. This year’s was infamous in that it was the longest on record. It ran over 70 hours, and that’s with them giving a free puzzle solution every hour, and cutting out 1/6th of the entire puzzle by the end of the hunt.

  3. So, I assume these are meant to match the whole line, from the start, and not just some part of it, otherwise this is all but unsolvable.  Would have been nice if they’d included a ‘^’ to be explicit.

    1. Unless specifically indicated otherwise, that is how regular expressions are supposed to always work. The expression defines a regular language, and then you check and see if the string matches that language. If you want any part of the string that matches the language to match, add .* to the beginning and the end (which several of these regexes do). 

      1. I cannot think of a single regular expression system where implicit anchoring is the default behavior.
        Typically, they require anchors to match a line beginning or end. So, to take an example from the puzzle,
        (di|ns|th|om)* would normally match any line which contained even one of those two-character particles, such as “xxxdiomyythy”, (the engine would reach the “di”, greedily match the “om” as well, then return without ever finding the later “th”). I suspect in this puzzle there are implied anchors, working like ^(di|ns|th|om)*$ and only matching strings which were composed entirely of the specified 2-character particles, like “omdithnsdidi”
        This guess is based only on the leading/trailing .* that you also noted: these would be pointless without implicit anchors.

        1. Java’s Matcher class has matches and lookingAt methods with implicit anchoring (on both ends for matches, just at the start for lookingAt). It also has a find method that works “normally” (i.e. only anchored if the expression contains anchors), so implicit anchoring isn’t really the default, but it is available.

      2. Depends on implementation though – a number of implementations will return substring matches unless anchors are included…

  4. It’s not so bad.  It’s just Minefield gone wild.  I took a hack at it for an hour and realized I needed to print out the puzzle several more times as my eraser marks are a serious detriment.  I’m also creating a “.” notation to denote letter orientation and if the char has been cross verified among other things.  It’s just a combination lock from hell…GIT HACKIN!

    1. It’s not that bad.  Look at the “gimme” characters and write them down first.  I think there are 4 or 5.  Then just cycle through the three dimensions (it’s 6 sided, but it’s really three dimensions) checking the RegEx facts three ways as you go.  It’s a bit tedious and I threw a lot of paper away.  But, overall I have to say it’s really fun.  

          1. It looks like Disqus yanked them all and put them in the spam bin after they had already been up for awhile. Based on past behavior, I wouldn’t be too surprised if it happens again.

Comments are closed.