The introduction of a generic solver simplified the deep solvers materially. However, a few new errors have emerged (undetected for now) when running strict mypy. The engine must declare the generics associated with the solver.

Solution: make the solver covariant and fix the factory type annotations

• [x] Expand the benchmarker to return more information
• [x] Update the Doddle facade to allow for benchmarking
• [x] Consider creating a HTML repr of the benchmark result object
• [x] Add a convenience method for creating a directed graph
• [x] Update packaging to allow for optional dependency on GraphViz
• [x] Update documentation on how to install GraphViz
• [x] Update Notebook to show how to benchmark
• [x] Save SVG in images

• Create a SharedMemory buffer to ensure that the large ScoreMatrix class can be shared across processes with copying.
• Increase chunk size to reduce the overhead of creating new processes

The wordlebot leaderboard has a csv txt format for uploading your scores.

1. Ensure that Doddle can write the required format
2. Ensure Doddle can read the required format and generate a decision tree

The naming here is not good. is_common_word is used throughout the code as an indication that the word is one of the the two thousand words that could ever be a solution.

However, the meaning within the code has changed over time and now indicates whether a word is still a potential solution. I.e. is it part of a list of words that shrinks with every iteration.

Proposal - at all but the highest levels, rename to is_potential_soln.

Currently, the implementation of DeepMinimax returns the best depth1 guess associated with worst depth 2 outcome. However, this will not work for depths of 3+. Suppose that at depth 3+, the solver realises it is essential to return some guess, Guess A, at depth 2 in order to avoid major problems. The depth 1 solver would have no idea that it needs to play Guess A because the knowledge learnt at depth three is not being conveyed back up the chain.

Deep entropy doesn't have this problem because it modifies the guess. This is probably an acceptable workaround although an alternative is that deep guesses have a list (of length n) corresponding to the worst outcome at each depth n.

Adding a few methods to simplify search operations. The basic Minimax solver is now a two-liner 🎉.

• Adding a few operations to simplify the process of finding the best / finding the worst / sorting guesses.
• Dependency injecting the solver into the DeepMinimaxSolver. This allows for recursive searches of arbitrary depth which is currently controlled in factory.py

One design decision I thought made sense was to drop the dictionary from the Guess class. The memory footprint is quite large with it as thousands of guesses get generated each holding thousands of words. It also allows for easy structural equality checks which is v useful / required to simplify a few things.

I copy pasted the DeeperMinimax class and added incorporated the upgrades but removing the dictionary broke version 1. I hope that's ok as v2 started life from v1 but it's tricky to keep backwards compatability. V1 has a couple of optimsations in it that v2 does not have so those still need to be included.

Returning guess as a class is a dubious design decision on my part as there is a degree of coupling to the minimax philosophy. My feeling is that this will need to change or be abstracted behind a base class of some sort. A protocol is probably the more appropriate abstraction than an ABC here but TBD.

Code could benefit from some tidying, but if you want to take a look...

Look for the top ~5 guesses and evaluate the worst case bucket count for the next guess. Choose the guess with the smallest worst case in the next iteration.

I can't find a case where this approach follows a different path to the existing solver. Unless there is an issue in the logic I've implemented, potentially the heuristic currently implemented is very good.

Much slower than the existing approach for two reasons:

1. Has to solve the next iteration
2. Has to solve for several potential solutions when looking at the next iteration

So we can build different concrete solver instances and re-use the rest of the framework.

I was going to use this branch to have a go at a minimax solver that looks at a second round of guesses, but the structural changes are probably useful to share early.

Because max(...) is not enough when there is only a histogram of ones. Need to choose the histogram bucket that doesn't hold the guess!

RAISE BLUDY CHUMP CHUCK

Currently the solve CLI is a litttle... sad.

All the analytics are there, so let's make the UX a bit more fun. Provide more words, associated metrics and the remaining list of potential solutions.

Hint: sorted(solver.all_guesses()) gives what we need.