Results are wrong

[ronniecross]

I updated Square.trySolve with a new algorithm which seems to work, however I'm not getting some bad results. It could be related to the changes to Square.trySolve, or having implementing these changes, an anomaly in another solve attempt may have surfaced.

[ronniecross]

Some odd behavior.... with simulation, square solve and single possible all enabled, although the results are wrong, the iteration completes. When disabling singlePossible (or defaulting it to false), I get an infinite loop. If I then disable either simulation or square solve and leave the other enabled, I don't get an infinite loop.

So, simulation & trysolve together seem to cause an infinite loop when singlePossible isn't in play???

[ronniecross]

When stepping through the code, I noticed the very first coordinate to be solved is row 1 col 5, which resolves to 4, however when using another sudoku checker, I see it should resolve to 9, so immediately it's wrong.

So, I checked where that was coming from, and could see it coming from Square.trySolve. I can now see that although coords.add(c) is being hit, and c is assigned at that point, after it has been hit, coords is empty, for some reason, like the 'add' never actually happened. So, that's my line of investigation right now.

[ronniecross]

The above comment is somewhat irrelivant (it was late :-)) but still leads to some other point of investigation.

Starting at 0, if(isUnique) { result = true; } in Square.trySolve(..) is hit on the third step. At this point, coords is empty, and the concerned coordinate is at r1, c5 with number 4.

coords is compiled in such a way that for each coordinate in a given row or column that is not the coordinate we are currently looking at, is unassigned, and shares the same square as the number we are looking at, then the coordinate is added to coords.

Inspecting the IDs of the assigned variables, I can see that in this case, gc (the container of interest) is the coordinate's row, so row 1. The concerned number is 4, and indeed, the other two rows in this square (rows 2 and 3) do contain the number 4, so this step at least, is valid.

However, there are three blank squares in row 1, square 2. Minus the blank square for coord r1,c5, this leaves two coordinates (r1,c4 and r1,c5) that should appear in the coords collection, but apparently do not.

Therefore it appears there may be a problem with either:

1. The process of adding coordinates to coords (more precisely, how to determine when a coordinate should be placed into coords)
2. The connection between what 'coord' is at the establishment of the coords collection and then again at the determination of whether a coordinate is unique (i.e. is the method up to this point working out if a different coordinate is unique?) or,
3. the type of container used to store a particular type.

[ronniecross]

I changed the placement of the break points, and inspected the coord coordinates. For the first 3 steps, (which never hit the contents of if(isUnique)), coord = r1,c1. On the 4th step, coord = r1,c5, and is just about to start adding coordinates to coords.

I stepped through until I reached r1,c6. Checks:

• c (r1,c6) !(c== coord) = true (perhaps I should change this to c != coord)
• c.number != null = false (wait.... shouldn't this be == null??)
• c.square == coord.square = true

OK.... there's a couple of anomalies here. Will review and return.

[ronniecross]

Having changed !(c == coord) to c != coord, and c.number != null to c.number == null, I reviewed the first three numbers added by square.trySolve, and it appears this is now solving correctly.