As far as generating a sudoku, it can't be too hard because I have a program on my cell phone that does it with a size less than 325K. I don't know the best way to generate these, but one way I was thinking of was starting with a filled up one then randomize the columns and rows. Then make some of them blank. The cell-phone version often generates puzzles that have non-unique solutions. Though I admit this is sometimes annoying, it also can make the puzzle harder.
Thanks, Roger On 1/9/06, Martin Maechler <[EMAIL PROTECTED]> wrote: > > First, "thanks a lot!" to David Brahms for finally tackling this > important problem, and keeping the R language "major league" ! > ;-) :-) {but the "thanks!" is meant seriously!} > > >>>>> "Detlef" == Detlef Steuer <[EMAIL PROTECTED]> > >>>>> on Sun, 8 Jan 2006 12:21:52 +0100 writes: > > Detlef> Hey, you spoiled my course! :-) > > Detlef> I planned using this as an excersise. Alternative > Detlef> ideas anyone ... > > Well, you could *add* to it: > > 1) When I have been thinking about doing this myself (occasionally > in the past weeks), I had always thought that finding *ALL* > solutions was a very important property of the algorithm I would > want to design. > (since this is slightly more general and useful than proofing > uniqueness which the current algorithm does not yet do anyway). > > 2) The current sudoku() prints the result itself and returns a > matrix; improved, it should return an object of class "sudoku", > with a print() and a plot() method; > 3) The plot() method should of course also work for unfinished > "sudoku" objects, and in fact, the *input* to sudoku() should > also be allowed to be a (typically unfinished) "sudoku" object. > > 4) Then you could have your students use "grid" and > grid.locator() for GUI *input* of a sudoku; i.e. you'd have > another function which returns a (typically unfinished) > "sudoku" object. > > 5) You could start looking at *solving* the more general sudokus > where the blocks are not 3x3 squares anymore, but more > general rectangular polygons of 9 squares each. > > 6) Now you need to refine the GUI from "4)" because your users > need to be able to *draw* the block shapes for the > generalized sudokus. > > 7) Given "1)" is solved, the problem of *generating* sudokus, > that David already mentioned in his announcement, becomes > more relevant: You want to be sure that the sudokus you > generate have exactly one solution. And your generating > algorithm could start with a very full sudoku (that has > exactly 1 solution) and "erases" squares as much as possible, > always checking that no other solution becomes possible. > > You see, there's lot of interesting exercises left for your > course. (;-) > > Martin > > Detlef> On Fri, 6 Jan 2006 11:43:44 -0500 "Brahm, David" > Detlef> <[EMAIL PROTECTED]> wrote: > > >> Any doubts about R's big-league status should be put to > >> rest, now that we have a Sudoku Puzzle Solver. Take > >> that, SAS! See package "sudoku" on CRAN. > >> > >> The package could really use a puzzle generator -- > >> contributors are welcome! > >> > >> -- David Brahm ([EMAIL PROTECTED]) > > ______________________________________________ > R-help@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide! > http://www.R-project.org/posting-guide.html > [[alternative HTML version deleted]] ______________________________________________ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html