As I’ve mentioned, the actual coding is slightly ahead of the blog pages, because I’ve spent ages trying to configure the blog and the online Tonnta Store. All this while supervising two recalcitrant daughters for zoom school during covid lockdown.
I generally write code in chunks, testing each section and building in more detail. Well, I havn’t coded anything in 20+ years, so maybe I shouldn’t generalise ! The first code hardcodes the first piece, an “L” shape and runs a loop around a 5×5 box to fit in the second piece. Arrays are used to store both the solution and each piece with a trial being produced by adding the arrays together. There is code to check that the piece doesn’t fall outside of the array of the solution (in this case 5×5. I’m still thinking I might pad the solution area to avoid these checks, but then that would give me a much bigger search box which could be wasteful. I also wrote a text printing subroutine for debugging purposes since it would be quicker than the graphics shown earlier. The code cycles through possible solutions printing various diagnostic information together with the current position of the pieces. I used the wooden blocks that I bought to help visualise and check the various solutions that the code produced. In the above diagram the two pieces overlap (1+1)=2 so this would be rejected.
The next modification was a routine to check for isolated holes and thereby reject possible solutions. It searches around the potential hole (in this case top left) and if the hole is completely isolated then the potential solution is rejected. This is the first stage in “high grading” the possible piece positions. I’ve yet to decide whether this type, or further position grading will be required. It may be that too many checks will slow everything down – such a solution will be “found out” soon enough because the last pieces will ultimately not fit and the code will have to go back to the beginning anyway !
By the way, you can subscribe to this blog using the link to the right of the posts.