Posted on

That time I wrote a Go server

My crossword puzzle web app grew up somewhat: now it is (optionally) backed by a database.

How we ended up here: I started this project from a completely different, and still mostly unexplored, direction: I wanted to be able to construct crosswords while on the go, since I occasionally find myself with some downtime and no keyboard. Just having a grid to type into is really enough for that — paper grids will do in a pinch, but who wants to kill trees and carry around a pencil and paper all the time.

Once I had a grid component, as a test, I built out a puzzle-solving application using 100% client-side code. That is, the JS can parse the puzzle files, render UI, save state locally, handle all the interaction without talking to a web server other than for the initial download. Then, naturally, creeping featurism took over and it became my daily solving app for NYT puzzles.

Doing everything client-side is nice because you never need the internet. Having a database backend provides some upsides though: you can more easily track progress (“how fast am I solving puzzles?”), and you can sync state across multiple devices: start on the desktop and move to phone later. Once you have syncing, you can also do collaborative puzzle solving, which is nice as the wife and I like to do the Sundays together. So if you go to this site, you can upload a puzzle, copy and share the resulting URL (randomized hash-path id indicates the ‘solution in progress’), and do an actual “crosswords with friends” unlike the branded game of the same name which is only solo play. I reserve the right to delete any data or break this feature at any time: it mostly exists for my current fickle amusement.

While the frontend is being written in a language I mostly don’t care for and don’t really know that well (ReactJS), I decided I might as well try learning yet another language on the backend. My first golang foray and a worse-is-better development paradigm led to this terrible non-idiomatic code on my github (here is the JS frontend). PRs welcome.

I’m not yet sure how I feel about Go. On the one hand, the “having types” and “lack of 2to3 transition disaster” features put it somewhat ahead of Python, and it is not as crusty as Java. On the other hand, those are fairly low bars and Go feels like a 90s language with a few minor changes. I haven’t spent enough time with it to get a feel either way about performance.

The ACPT online tournament, it turns out, uses a Java applet for the client, and it’s getting harder to find browsers that support that (I had to use an ESR Firefox release, which felt like going back in time 10 years even to this Debian-stable user). I am hoping that by next year they will have some similar kind of JS UI in place.

As far as the ACPT itself: it was a lot of fun. Out of the seven puzzles, I finished four with time to spare, my best time being just over ten minutes on puzzle number four. My worst puzzle was the first in which I completed only 50/76 answers. Overall I ended up (as of last time I checked) in 87th place out of 141, so, firmly on the left side of the curve. Oh well, plenty of room to improve.

Posted on

ACPT

The American Crossword Puzzle Tournament starts tomorrow. I’ve paid the entrance fee for the online “bragging rights only” track, so I’m looking forward to seeing some interesting puzzles and to get an idea of how my solving skills stack up. Considering that competitive solvers often finish well under five minutes on a Monday and my best is in the ten minute range, probably not that great, but we shall see.

I recently started a couple of the London Times cryptic crossword books; these are hard. As in NYT Saturdays are a cakewalk by comparison. Partly, because I’m not terribly knowledgeable of British geography and slang, partly because I haven’t learned to recognize the various clue forms, and partly because they are just tough. Example clue: [Notice boy going round vehicle after parking]. Answer: PLACARD. Because “PLACARD” is a notice, and in that word “LAD” (boy) is literally going around “CAR” (vehicle), which both come after “P” which you just have to know is an abbreviation of parking. So yeah, tricky.

Posted on

React reaction

An embarrassing admission to make: I wrote something in javascript.[1]

Actually, I wrote it in React, because I still think of javascript as that awful language that works differently in every browser, and so, you know, to stay relevant, I decided to learn the framework that web developers everywhere have already cast into yesterday’s wastebin for the new shiny. This, pretty much.[2]

Anyway, I replaced the third-party crossword app on my website with my own NIH version and made it somewhat responsive [3] so that it works on my phone. Also there are two new-ish puzzles since the last time I posted, dated 2016-11-25 and 2016-12-30. Each of them has its own set of problems, but I think I am at least learning where I need to improve.

To this neophyte, my impression is that using React (and ES6) is much nicer than that terrible language that they compile down to. On the other hand, the pattern of moving state up the object hierarchy away from an object’s view feels backwards and not very OO-like. Perhaps if I also used Flux then I might get enlightened on this point, but that is for another day.

[1] Here’s a nickel, kid. Buy yourself a real language.
[2] The day that my relevance depends on knowing the latest JS framework is the day that I will take up a completely different career.
[3] Anything worth doing is worth doing somewhat.

Posted on

On placing letters

Work continues on my fork of the QXW crossword filler, which by now is about 50% rewritten by me and ultimately will end up looking nothing like its predecessor. Already it is a command-line, monte carlo automatic filler instead of a user-directed GTK program. Both have their uses, I think.

In a previous post, I wished that QXW supported scored dictionaries. It turns out that it does, though in my tests it gave unexpected results in many cases. I’ve reworked most of that code and am pretty happy with the results I get now. Just to cherry-pick a before-and-after example:

input:

...#...
...#...
.......
##.X.##
.......
...#...
...#...

before:

SBA#STA
BJS#AIX
WASHMEN
##AXA##
ICGARDS
IUE#AWK
PFS#HHM

after:

THE#BHE
FOR#EAT
COUNCIL
##PXA##
LETTUCE
ARE#SEE
DID#EAR

The latter grid looks a lot more like actual words, though it does still have some garbage entries.

QXW’s algorithm could be roughly stated as “find the hardest to fill cell, then fill it with the highest scoring letter, repeat.” It is a naturally recursive algorithm (implemented iteratively with stacks) that either terminates when the grid is filled, or unwinds and tries the next best letter.

I have some issues with this approach, the main one being that maximizing letter score seems unlikely to maximize score of whole words. I’ve been thinking about this problem some, including the form of optimality that I would like to achieve: maximize the sum of the scores of every word.

A simple brute force algorithm implementing this could be “fill each entry with a word, compute the score, and repeat until all words in all entries have been tried, taking the grid with maximum score.” It’s fairly easy to realize this exponential algorithm though you may be waiting a looooooooooong time for it to finish.

What I have now is something like this greedy algorithm:

  1. Base case (no more entries):
    1. if grid is filled, return the grid
    2. return None
  2. Choose the longest unfilled entry crossing a “critical” cell
  3. Fill with the next highest ranked word for that entry
  4. Recurse. Repeat step 2 until grid is filled or no more words

In practice, with a large enough dictionary, this usually terminates without searching forever but you get some junk like PXA. I have added an arbitrary upper limit at which point I just give up the search.

An important thing to note is that the problem does not exhibit optimal substructure, so dynamic programming is not applicable. For example, take this template:

    ..E
    IPA
    PAT

We can fill it any number of ways. My algorithm will fill it like this:

    THE
    IPA
    PAT

…which is terrible (HPA — [Millibar alt.?]). Much better would be:

    SEE
    IPA
    PAT

…which is what you get if you fill the child “EPA” first.

There are a couple of things at work here: first, I pick the longest entry so .IP and .PA don’t even get a chance. Does this make sense? Should I instead pick shortest entry? Entry with fewest completions? Any of these might make better puzzles or at least move the junk around.

Second, THE is really really really common. The commonest three letter word ever. The previous sentence had one and so does this one. That’s a lot of THEs. Also it is a terrible word for crosswords. [Well, looking back through my NYT database, it has been used over a hundred times: {It’s definite} or {Genuine article?} being decent clues.] Unfortunately, THE is so very common and so highly ranked that practically every high scoring puzzle will have one. So, my optimality metric may be sub-optimal in that respect. Flattening the word probability curve somewhat could partially address this issue.

It is clear that we could pick worse words at some levels to get a better overall result. So I implemented a very simple monte carlo search that looks like this:

  1. Run the greedy algorithm, saving decision stack
  2. Pick a random location in the stack, and from there, pick a random word (instead of best word). Re-start algorithm from there.
  3. Repeat this zillions of times, keeping track of best N grids as seeds for future iterations

Lots of variations on the above remain to be explored. Also, this approach opens the door for taking a completed grid, manufacturing a search tree that generated it, and then optimizing it from there. Don’t like the fill in a published puzzle? Let the computer regenerate it for you.

Posted on

More boring crossword stuff

Since last post, I made two more puzzles, both standard newspaper size, and I appropriated and modified someone else’s javascript so that you can fill it in on that page. Both puzzles went through two drafts where I completely redid the fill after Angeline test-solved them and found some problems.

I’m still using Qxw, now with a 130k+ entry dictionary I built from 10 years of NYT puzzles, which works OK. Still, I feel like it could help even more: for example, it could rank words by their commonality in the corpus so that you don’t use something hyper-obscure that happened to be in one Saturday puzzle when the editor was asleep; or, it could give partial fills even though it may not be able to complete the whole thing; or, it could give hints on places to place black squares to improve chances that a reasonable fill exists.

To get at the latter, I extracted the qxw filler into a command-line program that just fills templates passed to it on stdin, and, into that, piped a python script that generates random valid grids. This helped for the most recent puzzle where a few spots had only two or three words that would fit given the themers, and moving a couple of blocks around was the difference between no-fills and some-fills. A quick improvement there would be to score the resulting grids, and use a genetic algorithm to produce new templates based on their fitness.

Anyway, these various ugly hacks are now on my github.

Posted on

Another puzzle

As I wrote before, I recently tried my hand with crossword construction.

This new puzzle is my sophomore effort. This one, slightly bigger at 13×13, came together much more easily for some reason (luck?). This time I did not have resort to using any unknown words, and nothing is really obscure, with the possible exception of 17-across (a common crossword answer).

As before, I mostly let the theme clues dictate the layout, while I left in a few longer stretches this time. The top left and bottom right corners were sufficiently isolated that I did them by hand before bed, then the next day I filled the longer answers and finished the bottom within about 30 minutes. At this point 3/4 of the puzzle was filled manually. Then, Qxw woke up and was able to help fill the rest (including 18-across, a nice gift which I happily accepted) — still using the standard Linux dictionary file. I reworked some of its suggestions using some of my own, but it was quite a time-saver.

In all I’m happier with this puzzle than the previous one: there’s more wordplay, better theme, nothing too difficult (I think). Comments welcome.

I guess this means the next one will be full-size.

Posted on

Puzzle

I will admit to being an insufferable word nerd: the kind of person who will intentionally make a pun and then ruin it by acknowledgment. My wife is the sufferable sort who, presented with the same joke, groans outwardly and inwardly at the same time. Together, we have a shared appreciation for the crossword puzzle, and can be found on the porch filling out a grid on the rare occasion that a lazy summer afternoon presents itself. We can usually get through a Thursday or Sunday NYT puzzle, but we aren’t going to be entering any speed solving contests.

A few months ago, I heard about Qxw, a crossword construction software for Linux. As a puzzle solver, the art of creating the puzzle seemed mysterious and left to those far smarter than myself, but any old dumb person can run some software. I finally tried it out yesterday, and here’s the result.

This is an 11×11 puzzle; newspaper puzzles are usually 15×15 but this was my first try so wanted to keep it easy-ish and constructable in a few hours. For the uninitiated, there are a few rules that help guide one into picking a layout: generally there are a few (~3) longish answers that form a theme; the layout is diagonally symmetric; the smallest answers are 3 characters. Taken together, this means two of the theme answers are usually 3-4 rows from the top and bottom, of the same length and in the same relative location, while the third theme answer is in the middle. Additional black boxes are sprinkled about to break up extra-long words.

It turns out that Qxw didn’t actually help much besides automatically placing the mirrored black squares: once I filled in my theme answers and blacked off part of the grid, Qxw couldn’t fill any other spaces. I suspect expanding the dictionary beyond /usr/share/dict/words would help a lot in this respect. Instead I occasionally used egrep on the dictionary file with suitable regexes to find candidate words and resorted to some abbreviations and prefixes. I did cheat a few times by googling some combination of letters that I hoped would be a thing (1-down, 6-down, 35-down). I need to improve my 3-letter word vocab.

Things I did do that annoy me as a solver:

  • Fairly obscure names or characters (35-down, at least to me, a non-Trekkie)
  • Use of old stand-bys (10-, 14-across, I burned these quickly!)
  • Weak multi-word answers (9-down)
  • Foreign words (1-down)

Despite the flaws, Angeline solved it in about 10 minutes while watching TV; she also supplied a much better clue for 25-across which I have appropriated.

I’d say this effort gets a B-, but it was an interesting exercise to do the puzzle from the other side. 13×13 next.