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 <maechler@stat.math.ethz.ch> 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 <detlef.steuer@hsu-hamburg.de>
> >>>>>     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> <David.Brahm@geodecapital.com> 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 (brahm@alum.mit.edu)
>
> ______________________________________________
> 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]]


