jkomoros / sudoku Goto Github PK

http://www.sadmansoftware.com/sudoku/solvingtechniques.htm is a good list

https://github.com/deiwin/interact

• Our current difficulty is only tuned for 'realistic' puzzles: puzzles that actually have a large number of cells filled.
  • We should include a lot of trivially easy puzzles in the difficulty training set (and really really hard ones, requiring tons of guesses) to make
    sure we're training for a broad range of puzzles. We should inject these in (optionally) after phase 1.

Perhaps make a new 'Experimental' bucket on komoroske.com/sudoku that people can opt in to solving.

... Right?

Setting this breaks a test in grid_test.go, but the test might be flawed.

... Or onlyLegalIn

to verify that we're getting good coverage and overlap from them.

• Make a decision about how to represent cell coordinates and row/col/block indexes when presented to user. now we're consistently 0 indexed (mostly), but shouldn't we be 1 indexed when presenting to the user?

Consider factoring out Rand methods to use a passthrough so we can test reasonably by setting a seed.

Instead of relying on Weka in the workflow

• Make it so NewGrid grabs a grid from grid cache if possible.
  • Actually call grid.Done() when we're done (we do in a lot of cases, but definitely not all)
  • We tried to do this but got CRAZY errors, which are hard to track down. Turns out that there is some possibility for slippage in grids, somehow. Need to solve that.
    • It's possible these come from some of the tests that dig deep into grids/cells and set things weird. Will have to audit.
      • hst_single_test looks like a good candidate.

Likely already covered by another technique, but this is one I find myself doing often so it might be worth including.

The technique where all of the 6 possibilities in a block are in the same column, therefore the 6 can't be elsewhere in that column

Create difficulties.go, auto-generated by a (simple!) python script based on a CSV.

Even for techniques that in practice should be VERY different as experienced by real people

A lot of techniques seem to duplicate a lot of work.

A way for technique finders to import the results of other techniques. For example, onlylegalnumber should import obviousincollection results and not duplicate those. And hiddensubset and nakedsubset should trade their results as input to the others. It's not clear if this additional layers of calculation is worth it or not...

... It shouldn't

Try one with 0 threads and no channels, just a basic recursive DFS

Investigate why using the finite queue isn't making a big dent in Fill() performance.

So it's not so much how many, but if there are any of a given step at all.

• Get rid of drawers
• Options drawer fixed pos at bottom. Shows timer, tapping to open to do new puzzle, etc
• marks and numbers in horizontal array of buttons always showing.
• swiping left/right/top/down selects cell
• Swiping with two fingers in the four directions selects next unfilled cell in that direction
• Below the two tranches of marks/numbers buttons are buttons tofill all, remove invalid, etc
• Switch to marks in regular position 9x9 grid
• Shortcuts show up in a hint at beginning of each new game
• Get rid of status bar
• manifest, sw
• hall of fame shows up in modal at end

• In a perfect world, NonFill steps that don't end up being necessary to actually place a cell in the future would not be included.
  • This may be a side effect of other techinques taking a "key" cell (the cells affected last move) to focus more intensely on. This mirrors human behavior more closely.
  • The way to do this, I think, is to mirror the guess branch logic in HumanSolve. Whenever we pick a nonfill stepp, we have to fill forward until we find the first fill step. Then we need to verify that the cell picked had its possibilities reduced by the interveining non fill steps.
    • This could get expensive.
    • This will be easier to do if we split the techniques up into the tranches and only dip into nonfill when no fills are available.
    • Presumably at each step after a nonfill we try ALL possible fill steps and see if any of them are one of the cells whose possibilties have been reduced since the "branch"

• Stored puzzles should go in a folder named with a hash of the difficultiesweights loaded up. That way, we won't vend puzzles generated with different weights.
  • Probably makes the most sense for the base library to expose a DifficultiesHash that it populates when we load the difficulties, and have dokugen use that.

They aren't used very often in Cell, might save memory

This is to address the fact that the puzzles generated only very, very rarely have low difficulties.

This assumes that as you remove cells puzzles get more and more difficult.

This could be extremely expensive.

• When generating grids, at every step check the difficulty. If it's above the target, go back to the most recent known good difficulty and return that.

• Does our use of the Rand convenience funcs in different go routines cause performance problems? (http://stackoverflow.com/questions/14298523/why-does-adding-concurrency-slow-down-this-golang-code)
  • In any case we want to be able to test randomness.
  • I tried it in Solve and was finding that generating a new r per thread was actually taking 110% of the time of just using the global one, oddly...

Move into another repo?

Just seems like it makes sense.