Continuing Backwards

This week I've been taking a closer look at solving for these squares. One of the tests involves waiting for "leaf squares" -- where the square only has one solution -- and checking it against the existing data. I stumbled across a peculiar loophole where once the dimensions of the square grew larger than my traditional four or five in depth, the potential solution counter would enumerate what quite obviously is a large number of potential squares. All for the purpose of simply checking if there was one or more than one. Needless to say that was nipped in the bud.

In preparation for presentations and recording a video, I also set up a simple text interface to actually allow for run-time configuration. It does the simple tasks of demonstrating a few of the features completed and the feature that tries its best.

I may have touched on this last week but I imagine that future steps for this algorithm is checking against flipped relations. However, before I tackle that, I've been reviewing the existing code as my understanding is that this approach of checking forward and backward in all positions should find all four valid squares. As such, my progress in that regard has slowed. Once I figure out the oversight there, I should be able to focus more on optimizing the approach.

Operating the brute force approach somewhat shows its incremental nature. I picture it essentially as adding numbers in a system, especially with respect to changing bases. Each time you loop through the ones place, the tens place increments and the ones start over. It is the same case with these moving character groupings but more apparent with larger squares.

Ultimately, if nothing else, I hope to solve this problem, potentially accepting inefficiency as a side effect. Currently, 4x4 squares can be completely enumerated with the data set but will not return a valid square. 6x6 and onward tends to become bogged down in calculation. 5x5 is a mixture with the added bonus of a mystery runtime exception that is eluding me.