Found here. The recursion makes it a little hard to read/understand. Also iteration might be better memory-wise.

As of an email I sent to Louis on Jan 29, 2023, 4:41 PM, the code ran (and passed all tests) in ~16.02s on average (loosely), but as of 8112ac7, the code ran in ~18.56s on average (again, loosely).

^ Title

• Test hooks (little x or checkmark, passing/failing icons, the works)
• Lint and only enforce on master branch?
• Publish results to commit SHA -> artifact repo (as in, don't include in git commits)

There has been some discussion of where the zero_forcing_set() and zero_forcing_number() functions should live. Pull request #7 would add those to the metagraph module, and this might even make sense, since that particular metagraph implementation is specific to ordinary zero forcing. But for the sake of computing other forcing variants in the (hopefully near) future, we should probably move the dijkstra() function into its own module. We could then – if we want – move zero_forcing_set() and zero_forcing_number() into that module as well. I'm not sure what we should call it. Maybe just zeroforcing? Or perhaps zero_forcing_tools? Presumably, we'd want this to be the one module that end users actually import.

Having the Dockerfile have the git repo itself as a dependency is weird. It can lead to issues where you have to commit and push things before you can even test them. The Dockerfile should perform tasks on the code it can see right before its digital eyes.

I think we should have a Makefile to more easily track command dependencies. For example, to test, I don't want to run the command to install test dependencies, THEN the command to run the test. I just want 1 command that wraps both.