Week One Done

Next I may endeavor to improve this algorithm to prevent erratic spikes in timing or simply move on to the rebuilding algorithm. Of course, that will start with small dimensions. 

I managed to apply a simple recursive backtracking algorithm to this off the grid problem. Writing in Java, I have a script to generate Latin squares; it also can use these to hash a password. There may be a better approach to the recursive approach to rectifying the square cell collisions. When the "problem cell" was set long ago, many other combinations have to be tested in vain. This may be solved by using an actual stack as opposed to the functional stack and scanning backwards until the problem cell is found. However, precisely how we define this actual "problem cell" is unknown to me.

The axes on the below graph are: vertically, average millisecond generation duration; horizontally, square dimensions. Clearly up until 20x20 squares, generation is somewhat trivial. When increasing the iteration count from 20 to 50 and 1000, we numerically see the evidence for the occasional spike in duration. A sample pool of showed a surprise issue with 23x23, for example. One consideration is completely wiping out the row and column of a particular cell when there are no valid choices for the cell. This would take care of figuring out what the true "problem cell" would be, though it may complicate the recursive approach. 

Repeated latin square generation iterations show unreliability