Roadmap - Tomboyo/mastermind GitHub Wiki
Roadmap!
The objectives of mastermind are:
- Be digestible by a human being. This is a complicated enough concept without being obtuse to read, so every whit of code should be as simple and immediately understandable as possible. The interactions between objects might be complex by their nature, but hopefully good naming conventions and design/review processes can ease this.
- Be extensible where valuable. For this program to be valuable, it needs to allow the user to customize its operation and extend its decision-making capabilities.
Areas of Concern
Parallelization
The algorithm will inevitably need to fan out across cores across processors, especially using the enumerative approach. This problem space quickly gets too large to solve in a restricted area by any means.
- [DONE] The algorithm should be multi-threaded
- The algorithm should be multi-processed
Work-saving
Avoid doing work that has already been done to decrease processing time.
- identify isomorphisms. It's pretty clear that certain trees are equivalent even if their representations differ. Create logic to identify these. (1.1 Provide/find a proof that this is the case, as well.)
- Remember solutions. With isomorphisms in mind, this will have to be a mapping from a family of input to an output template.
- Reuse solutions (Memoize). The algorithm should cache the mapping from input to output on load so that sections of processing can be skipped as they are encountered. (3.1. Investigate what the cache looks like, as well. We may need to configure just how much information is allowed in the cache. When the algorithm becomes multi-processed, we may want this functionality to be serviced from one process instead of being replicated across all of them.)
Extensibility
- [DONE: Tree comparators] The "optimal" strategy tree selected for by the algorithm can be arbitrarily defined
- [DONE: Code Providers] The "optimal" sequence of guesses to consider when generating a strategy tree can be arbitrarily defined
- Any arbitrary information about a tree can be captured as the tree is created, allowing tree comparators to discard "inferior" trees as they are constructed, saving memory. (Initial research suggests this will create a family of related types that interact to record desirable metrics.)
Heuristics
- [DONE: GreedyAllCodesProviderFactory] Recreate the well-known heuristic that was used in the original draft. This will let the program be used at the capacity of its predecessor until it evolves beyond the original's capabilities. Note, however, that the extension points mentioned above should avoid the need for an extensive library of heuristics; presumably these will be created on an as-needed basis and submitted to the central repo.