Solving Sudoku With dpkg
Reader Otter points out in his journal a very neat use for the logic contained in Debian's package dependency resolver: solving sudoku puzzles. To me at least, this is much more interesting than the sudoku puzzles themselves. Update: 08/24 02:51 GMT by T : Hackaday just ran a story that might tickle the same parts of your brain on a game played entirely with MySQL database queries.
1. Computers can generate Sudokus
2. Computers can solve Sudokus
3. Skynet determines that humans are useless. It then creates what is called "virtual worlds" in a campaign to exterminate the global human population birth rate.
Because cheats impress babes. left-right-left-right-a-b-start! left-right-left-right-a-b-start! I think I feel tingley.
Once you start despising the jerks, you become one.
Sudoku isn't a math puzzle, it's a logic puzzle - just one where you're filling in digits instead of the man in the blue house smoking Pall Malls and having a goldfish.
The digits 1-9 in Sudoku could be replaced with any 9 other symbols without changing the underlying rules. So yeah, logic can be used to solve it.
Village idiot in some extremely smart villages.
Because cheats impress babes. left-right-left-right-a-b-start! left-right-left-right-a-b-start! I think I feel tingley.
Please hand in your geek card immediately.
Jesus Christ. If you're going to mention the greatest cheat code ever, get it right:
Up-Up-Down-Down-Left-Right-Left-Right-B-A-(Select)-(Start)
Amateur.
First, it's not "cheat codes".
Second, I, and I'm sure I'm not alone on this, would rather write a program to solve sudoku than actually play sudoku. Some people love sudoku; I found it boring. Now writing software to solve a puzzle, that's interesting.
Maybe not
Sodokus are typically solved by using logic and identifying relationships, but the article describes a clumsy brute force method. I will admit that I'm splitting 'mathematical' hairs here, and that it is an amusing thought to readapt Debian's simple dependency resolver, but crude solving functions, that simply guess at every possible solution, are fairly boring when compared to clever logic with elegant methods, that can solve sudokus in a fraction of time.
I just feel sorry for geeks living in Soviet Russia. I've heard horror stories that suggest that over there, the geek cards hand in the geeks. Can you imagine the betrayal of your geek card giving you up like that?
And he didn't even use Super Cow Powers to do it!
RTFA. I know, I know, what am I suggesting, it's Slashdot.
Here's the quick version: Russell Coker remarked that "a package management system that can solve Sudoku based on package dependency rules is not something that I think would be useful or worth having."
Daniel Burrows realized that apt could, in fact, currently be used to solve Sudoku puzzles, and wrote a Python script to automate the process of creating the packages required to do such a thing. That's the linked article, and it gives the background I'm repeating here.
I, personally, think it's pretty damned cool. Useless, but cool.
And, as the article points out, there exist better Sudoku solving algorithms. apt is a rather poor Sudoku solver, mainly because it's designed to come up with the "best" dependency resolution rather than solve Sudoku. It's not to "cheat" at Sudoku, but rather to demonstrate the power of the apt dependency resolver.
You are in a maze of twisty little relative jumps, all alike.
It isn't about beating sudoku. It's about taking one tool, and using it to do something that its creators never imagined.
It's the same reason people use laser cutters to slice their pizza or try to create the shortest possible quine in their language of choice. This guy might not even give a shit about sudoku; he just wanted to see if he was clever enough to solve sudoku using dpkg.
Exactly. This guy doesn't care about the sudoku puzzle, he cares about the programming puzzle.
Sudoku doesn't have clever logic and elegant methods.
Check out the various strategies listed on this Sudoku Solver.
Don't mod me down if you disagree. If you disagree, consider writing a retort instead.
You must be new here. Only posters that take the time to back up conclusions with reasoned responses are moderated down. Conversely, those that write short, unsupported attacks are moderated up... because in reality most people can only be trusted with 2 tags - I agree or I disagree.
Sudoku doesn't have clever logic and elegant methods. There is only one method for solving sudoku puzzles, and it strongly resembles a computer doing brute force.
Sure, there are brute force methods. They are often techniques that dive into deep "consequence" trees to find contradictions. Those are, by their very nature, annoying for people to do and thus attractive for computer solutions. Nishio, tables, all of those just make sudoko boring and feel like you're executing a computer program in your limited-RAM brain.
But those aren't the "clever" or "elegant" methods. Sudoku techniques that I would consider elegant are things like sashimi x-wings, XYZ-wings, the various type of unique rectangles, and such. I enjoy trying to discover patterns like these in really tricky sudoku problems. I expect I'm not the only one, given the popularity of the puzzle over the last few years.
If you want to get really deep, you can use sudoku puzzles to explore mathematical group theory.
All of this (and what you said in your post) are true for other puzzles such as the Rubik's cube. Perfectly suitable for machine automation, but still fun for some of us us lowly humans as well.
Ultimately this approach simply encodes the rules of sudoku, and the state of an unsolved sudoku puzzle in logic statements, and then passes it off to a reasonably general logic solver, namely the dependency/conflict resolver in apt-get/aptitude. That's not really brute force at all.
Whether or not the solution is "brute force" depends on the manner in which debian's dependency/conflict resolver operates. There's many approaches to solving this problem, from gross brute force to reasonably complex machine learning approaches.
The insight in this approach (although it's not an especially new insight to people playing with this sort of idea), is the relationship between puzzles and other day-to-day computing problems purely as constraint satisfaction problems, which essentially means that we describe the problem abstractly without all the trappings of how humans interpret the problem, and let a computer with little to no "general purpose" knowledge or "common sense" come up with the solution on its own (and of course, of us being able to read out the solution once the computer nails it)
"You know, Hobbes, some days even my lucky rocketship underpants don't help" -- Calvin
Let's seem yum do THAT!
I kid I kid.
Also, if you're going to write a Sudoku puzzle generator, you have to write a Sudoku solver first. New puzzles are created by coming up with a random valid solved Sudoku puzzle, removing a bunch of numbers, checking to see if it's still solvable, and then removing some more...rinse, wash, repeat...
ZuluPad, the wiki notepad on crack
This is very cool! Kind of like implementing the Towers of Hanoi in vim or something. I'm going to test it against some puzzles from this here handy dandy Sudoku book. Now if only someone would make a Chess solver out of dpkg. You choose any out of the huge number of possible mate layouts and it will compute the dependencies from the start of the game to that mate layout! Implementing this should be so obvious that only a total fool won't immediately see how to do it, so it is left as an exercise for the reader.
McCain/Palin '08. Now THAT's hope and change!
Hey now, there's a reason why they're called "joysticks."
It's probably less costly to take a square away at a time and check to see if it's still solvable than to populate a random start and see if it's possible to solve it. And probably less complicated as well.
Isn't that pretty much exactly what I said? Create a random valid solved puzzle, then start removing squares...
ZuluPad, the wiki notepad on crack
Interesting? Writing a SAT program to solve sudoku takes less than five minutes. This is not an interesting puzzle for a computer.
Probably also could be done using Make, which is really an expert system in disguise. Ant-heads won't know what I'm talking about. (Mod to +5 Flamebait.)
Since Sudoku is NP complete, doesn't this mean Dpkg is NP complete?!
Oh, the humanity! I'm just waiting for an evil set of dependencies to crop up that makes it go exponential.
You don't need a full solver to create a solved puzzle, I should think. Just start with the most basic puzzle and make legal permutations of it:
123|456|789
456|789|123
789|123|456
---+---+---
231|564|897
564|897|231
897|231|564
---+---+---
312|645|978
645|978|312
978|312|645
For example, you should be able to swap any two numbers everywhere.
Comment removed based on user account deletion
The article is really a nerd article, and now we all have a challenge!
What is YOUR software solution to solve Soduku puzzles? Think outside the box, or go for the classic brute force method.
I would think about using languages like Erlang or Prolog to solve the problem, but classic languages with iterating over the alternatives will do also. Pick your poison!
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
That's the 2-player code.
Up-Up-Down-Down-Left-Right-Left-Right-A-B-(Start) is single player contra.
Not a sentence!
Here's my attempt at a solver / generator (Java backend, with a console frontend, a graphical frontend, and a j2me frontend):
http://cons.org.nz/~gringer/
I don't actually find sudoku puzzle *solvers* all that interesting, because they are able to do the solution by brute-force. Sudoku puzzle *generators*, on the other hand, tend to be more difficult, because one requirement for the traditional puzzles is that the puzzle must only have one solution. For puzzle generators that rely on brute-force for their solvers, this "only one solution" requirement is difficult to enforce.
Just to demonstrate this, see the following bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351043
Ask me about repetitive DNA
I guess I'm just annoyed by these people who think that they are thinking, and am trying to burst their bubble.
I already learned all the chords on the guitar,
:-)
--and I'm just annoyed by these people who think that practicing will make me any better.
I already learned how to swim,
--and I'm just annoyed by these people who think that practicing will help me win an Olympic Medal.
Steven Hawking was simply born as a fully formed genius,
--and I'm just annoyed by these people who think that his thinking everyday has helped him achieve anything... but bursting your bubble.
Allow me to clarify parent and grand-parent for those of you who don't read articles:
As a proof-of-concept, I have written a hacky Python script, named debsudoku.py, that can convert ksudoku saved games into Packages files suitable for use with apt-get or aptitude.
(Source: TFA, at http://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/)
Emphasis added. Note that dpkg doesn't solve the dependency puzzle, but apt-get, aptitude and other package managers do (including synaptic and gnome-app-install [the "Add/Remove" thing]). Hence the suggested badtitle (which I agree with).
The 'aptitude --help' bit and the super cow powers: if you run 'apt-get moo', you'll get a cowsay output (that is, an ascii-art cow saying "Have you mooed today"). Running 'aptitude moo' gets you "There are no Easter Eggs in this program". Running 'apt$GETITUDE --help' gives you "this apt[itude] does [not] have Super Cow Powers".
Just FYI ;)
Let me get that straight, if you can't solve a problem it's a bad problem ?
How would you feel then if someone else did solve the problem that you could not solve ? Is it still a poor puzzle then ?
I read what you are saying as 'I like sudoku, but only the simple ones because I'm not clever enough to hold more than a few permutations of it in my head'...
MP3 Search Engine
I suppose nothing will beat Prolog with constraint logic programming to concisely solve Sudoku.
Actually, let me put the whole code here from the above blog post:
sudoku(P) :-
fd_domain(P,1,9),
Xs = [1,2,3,4,5,6,7,8,9],
row(P,Xs),
col(P,Xs),
unit(P,Xs),
fd_labeling(P).
row(_,[]). :-
row(P,[X|Xs])
setof(V,[C,I]^(for(C,1,9),I is (X-1)*9+C,nth(I,P,V)),L1),
fd_all_different(L1),
row(P,Xs).
col(_,[]). :-
col(P,[X|Xs])
setof(V,[R,I]^(for(R,1,9),I is (R-1)*9+X,nth(I,P,V)),L2),
fd_all_different(L2),
col(P,Xs).unit(_,[]).
unit(P,[U|Us]) :- // 3)*3+1, Re is Rs+2,
Cs is ((U-1) mod 3)*3+1, Ce is Cs+2,
Rs is ((U-1)
setof(V,[R,C,I]^(for(R,Rs,Re),for(C,Cs,Ce),I is (R-1)*9+C,nth(I,P,V)),L),
fd_all_different(L),
unit(P,Us).
WRONG!
You inverted the A and B.
Yes! That's another geek card today. Only 2 more until my geek upgrade.
I just pooped your party.
Sudoku, in the way that it's being solved here and how most people think of it (with 9 digits and 3x3 boxes), is not NP-complete. Its board size is finite, so there are a bounded number of possibilities to try (fewer than (9!)^9), so there exists a constant-time algorithm (trying every one of the possibilities, of which there must be less than 9!^9). But if you want to generalize to nxn boards, that changes things considerably.