Optimization

Currently, the implementation is not very efficient. That's OK: the goal was correctness, first, and we're still working on that.

However, I noticed that already the inefficiency can cause some possibly unacceptable limitations: the amount of memory consumed means that the colours and slots combinations available cannot go very high before the program simply won't run.

Tools

First, I'm interested in finding tools that will tell me the exact amount of memory that is taken up by various JavaScript data structures, under both NodeJS (for analysis) and under Firefox (for interactive play.)

Ideas

Code representation:

1. Codes could be represented by an integer data type, which is then converted as needed to a base-(colour count here) number. This may be slower but will certainly take less memory. This would place a certain limit on the total code possibility space corresponding to the integer bounds. I would have to look into whether this might still be 32 bits even in a 64-bit runtime environment.
2. Alternatively, they could be represented as a string, which would still need conversion, but be more human-readable. This would limit the colour count to how many different characters we deem acceptable for representation. E.g. if we went with 0-9 and A-Z then we could have a maximum of 36 colours.

Possibility space representation:

1. We could switch to a hash map for faster lookups. Then, instead of having both possibleCodes and allPossibleCodes, we could keep track of whether a particular code is still possible by mapping it to either true or false.

General code cleanup / style:

1. Get rid of the singleton pattern.
2. Make the whole AI object purely functional / without side effects.