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
