prb's comments

I did write the spec first — data model, algorithm, etc. That may have helped the agents get traction.

It's getting crowded down here in the rabbithole... One more to peek at: https://github.com/prb/pips-solver/blob/main/README.md

Just for grins, I ran stats on most (but not all of the puzzles):

• Solution Counts Overview

  - Processed all 183 stored puzzles (61 dates × 3 difficulties) via target/
    release/count_solutions, saving raw results to gpt_5_codex/output/
    solution_counts.csv.
  - 131 puzzles (≈72%) have exactly one solution: easy 50, medium 44, hard 37.
  - Remaining puzzles show small clusters of alternatives except for a handful of
    hard cases with large branching factors.

  Most Multi-Solution Puzzles

  - 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 only asked for the top five.)

> My guess is that if I changed the way the solve functions picks the square to start with it could greatly change the time. Right now it just takes the first open square found scanning right to left and top to bottom. Maybe something like giving priority to squares in small constraint groups would be more effective.

Your guess is correct. Take a look at my backtracking solver linked from another comment; one of the optimizations I added after the fact was to select a square with the "smallest" constraint for the next placement, with the motivation of avoiding a rathole. (The 2025-09-15 puzzle with the =63 constraint is a good test case, FWIW.)

My Rust solver running on an M3 Max Macbook Pro is often under a second and never more than about 30 seconds. (I did pull down all of the past puzzles using an observation from Evan Matthews in his solver: https://github.com/ematth/pips)

So much fun. I'm not sure if the game is more fun or writing a solver for the game is more fun... Here's my entry written in Rust from a spec in Markdown — executed as an initial AI coding experiment with Gemini, Claude, and Codex working individually and then assessing each other's work:

https://github.com/prb/pips-solver/blob/main/README.md

When I did experiments with RoR versus Haskell via FCGI, Haskell had around a two orders of magnitude performance advantage under load and only required a single OS process.

How about "dbNG" for next-generation database?