The New Sudoku Players' Forum

[civiliza]

My Puzzle Generator is displaying some strange anomlies wrt Sudoku Explainer.

The Generator relies on taking away squares from a completed puzzle and assigning each square a SE Rating based on the hardest technique needed to "put the square back". It then stacks up all these ratings for the whole puzzle.

This technique has a definite weakness towards sharing a single high rating technique's score amoungst several undeserving squares because all replacement routes funnel through a common high rating square. So far, so fair enough.

Here's the issue - I've recently added code to remember the top five square ratings for a puzzle. Theoretically the very highest square should equal the Sudoku Explainer rating. BUT IT DOESN'T.

QUESTION - Is it possible to reduce the Sudoku Rating of an unoptimised puzzle (one in which there are still redundant squares) by removing these squares?

As an example, the puzzle:

Code: Select all

000060100
080750000
009000000
020000000
610870005
053000060
042000000
000023008
030010400

Puzzle Rating = 1313
Top 5 square ratings are: 50 50 50 54 54

Has (presumably) identified at least two different squares that require a Quad to replace (One Naked Quad and one Hidden Quad). When plugged into Sudoku Explainer though, the highest rated technique is a Naked Triplet.

Do I have to accept that there is a serious error in my technique spotting code or is it possible that by taking away more squares, the Hidden Quad has (possibly by allowing a number of mid-ranged techniques) been reduced to a Naked Triplet?

EDIT - Because my code evaluates all twins at a given level at the same time, it is possible that the Hidden Quad was actually a Naked Quad. Even so, it was still a Quad.

[civiliza]

While splitting out Naked Twins from Hidden Twins, I discovered a Logic Error that allowed Quad's to claim credit for Triplets etc.

A historical leftover from when all twins were processed at the same time.

Also discovered a left over from when "perfect" twins (22, 333, 4444) were processed seperately from degraded twins (223, 233 etc). Since the degraded twins needed a minimum of three digits, I had a leftover piece of code that wasn't processing pairs at all - probably the cause of the false Quad.

I'll have another look at this issue once I've finished splitting out the Naked and Hidden Twins.

[civiliza]

I was away longer than I thought, I split out the hidden and naked twins easy enough, then forgot to archive that version before a major overhaul.

Previously I had a lot of disparate array[81] variables, and I have a long term goal to transfer those over into a single array of a common cell class with arrays of row, column and block pointers into the single array.

Anyhoo, after splitting the twins, I went on to transfer my cellValueKnown[81] variable into the new class. and broke my subGroupAnalysis (pointing and claiming) routine. (The extra coding needed to access the new class added a valid coding shortcut that I bodged when implementing it).

Before identifying what I had broken, I discovered and corrected several unrelated errors in my early routines that I had been building on unchecked for the best part of the last year.

Finished this about a fortnight ago, then had a brainwave today. I have discovered "run-on" in which the analysis code would prefer to run-on to the next high ranking technique after making a change rather than return to Hidden Single checking. With hindsight all the clues were there - when I was mis-diagnosing a Quad, the previous technique was Triplet checking. After "unbreaking" the code, I was getting mis-diagnosed Quads following a previous technique of UR's.

Here's hoping today's changes sort this issue out (only performed four test runs so far, none of which have even detected a UR as yet).

If it does work, I can then (MUST ARCHIVE, MUST ARCHIVE) return to the ongoing mission of converting arrays into my new class.

[civiliza]

D'oh. Just discovered that I corrected run-on as part of the unbreaking process, but I was getting fall through from my UR tests into my Naked Quad test on a stillUnique flag. Right idea (previous test running on / falling through to Quad check(s)), just wrong reason.

[civiliza]

Famous last words, but hopefully I've finally solved it.

As various other bugs were solved, I was getting to the point where I was consistently detecting false Naked Quads in the same column as an undetected Hidden Pair or Hidden Triplet.

After "boot and bracing" some dubious code avoiding Hidden Twins with internal subsets, I was still stuck until I discovered a glaring error in the "Hidden Twin in Column" code that has been there as long as I have kept records.

My Hidden Twin logic involves starting with an unknown cell's true value, then looking for all the cells in the region that can still hold it, then looking for all the cells's that can hold the added cell''s true values and so on. This relied on two arrays: int twinnedValue[] and bool cellTwinned[] both indexed by a twinnedCount.

I have been using logic similar to this consistely throughout both Naked Twins and Hidden Twins (2 twin tyoes x 3 regions = 6 tests). I got it right for 5 of the cases, but in the case of Hidden Twins in Column, I had left out the line to increment twinnedCount when a new twin was discovered.

Maybe now I can clear out all the debugging statements that helped me isolate the problem down to a single routine.