Solving the Ny Times "pips" Game with F#

Hey Brian, I really enjoyed reading your work on the Pips game! I found myself applying a similar backtracking algorithm to my Pythonic solution (https://github.com/ematth/pips). I focused on finding a single solution for each puzzle as opposed to all possible solutions. For hard puzzles with longer run times, I found that running multiple processes, each with the domino list shuffled, gets the solve time down to <15 seconds.

  Last updated 2025-10-27.
  [...]

  The puzzles with the most solutions are:


  • 2025-09-15 hard: 2,764,800 solutions
  • 2025-10-05 hard: 344 solutions
  • 2025-09-30 hard: 110 solutions
  • 2025-09-04 hard: 86 solutions
  • 2025-08-23 hard: 80 solutions

I really enjoy the Pips game, but it doesn't appear on the games page in my (Android) NY Times app. I'm a subscriber, and the app is up to date. I can get to it by searching for the article announcing it a few months back, and then clicking through from there, and it works just fine.

Presumably it's there in the separate NYT Games app, but I'd rather not install a separate app.

Does anyone know why they exclude it from the regular games section? I realize this is the silliest of all first-world problems, but still: Why?

Looks like quite a few people who have written Pips solvers are here. I too have one (a dumb as a rock brute force solver in C).

How are you all getting the puzzles into your solvers? I just found out that the puzzles are available in JSON at https://www.nytimes.com/svc/pips/v1/YYYY-MM-DD.json

where YYYY-MM-DD is the date for the puzzle. They have past puzzles and even some future puzzles. At the moment they through 2025-11-25.

Right now I'm using a hand written text input that for example looks like this:

  ..-.
  -ABB
  .AAC

  A 3
  B 3
  C 3

  10 11 00 33

for the 2025-09-09 easy puzzle which looked like this:

                  ┌───────┐
                  │       │
                  │       │
                  │       │
  ┌───────────────────────────────┐
  │       │       │               │
  │       │       │               │
  │       │       │              3│
  └───────│       └───────────────│
          │               │       │
          │               │       │
          │              3│      3│
          └───────────────└───────┘

Those JSON downloads are going to make things so much more convenient!

This is great, and serendipitous timing for me.

After spending an embarrassing amount of time on today's hard before I went to bed I was wondering what kind of metrics could go into analysing the difficulty of any Pips game (and which ones NYT Games uses) and whether it would be worth writing a solver to do this analysis. I was also considering an SMT or CP approach instead of backtracking as an alternative.

Edit: And after looking through the solve times in more detail, I feel vindicated that the hard for today (01/11/2025) was both a single solution and took the solver over 8x as long to find the solution. It took me longer than 8x my average, but that's besides the point...

Mr. Righto's (Ken Shirriff) approach using a constraint solver (MiniZinc)

https://www.righto.com/2025/10/solve-nyt-pips-with-constrain...

I quite like this game but it does feel a little like I'm a human SAT solver.

Pretty cool! I used backtracking for a very similar layout problem: generating word searches. I used C# for that.

I see that a few of the people who have written solvers have posted in their repositories counts of the number of solutions for some of the puzzles, such as the infamous 2025-09-15 hard, which had 2 764 800 solutions.

That's how many my dumb brute force solver counted for that one too, so it looks like we are all counting solutions the same way.

This raises a question.

Here's one solution to that particular puzzle

6/5(15,16) 1/2(23,22) 4/5(0,4) 1/5(2,1) 5/3(5,6) 2/5(7,8) 4/4(9,3) 0/0(17,10) 4/2(19,18) 3/3(12,11) 3/4(21,20) 5/5(14,13)

where the notation P/Q(A,B) means the tile that has P pips on one half and Q pips on the other have is placed so the P half is on square A (counting the leftmost square on the first row as 0, and then going left to right, top to bottom) and the Q half is on square B. The order the halves of a tile are given is the order they are in the puzzle specification, and the order the tiles are listed is the order from the puzzle specification.

My solver considers two solutions different if they do not produce identical strings when the solution is written in the aforementioned format.

I'm reasonably sure that this counts some solutions as different that most humans would count as the same.

For example supposed there is a 2/3 tile this is entirely inside a region that has to sum to 10. Another solution that is identical except that tile is rotated 180 degrees would probably be counted as the same solution by a human but as different by my solver.

Similarly, if there is also a 1/1 tile entirely inside that region, the 1/1 tile and the 2/3 tile could be swapped and my solver would say that is a different solution, but I think most humans would not.

How far does this go? Would a human tend to think of all permutations and orientations of a set of tiles that are all contained in the same constraint region as identical solutions?