I have added 'solve method F', aka X-wing, swordfish...
(www.sudokusolver.co.uk) to my solver, that reduced the number of puzzles
needing guesses to 5306, so I suppose that's it.
I haven't yet implemented it efficiently, so it was devastating for
performance - and solving thirteen puzzles more
I believe if you change the representation of puzzles from [(pos,range)]
to an Array, you'll get a significant speedup
yet because I only recently removed a logic bug that slowed down the
search instead of speading it up; ..). so the more interesting bit is
that our solvers disagree on which
Daniel Fischer wrote:
My IDE is kate/kwrite + ghci + hugs, if you know a better one (which doesn't
involve loading down a 99MB thing like eclipse), I'd be interested to try it
out.
(I already knew emacs, so using haskell-mode is my choice)
I changed the output format to a line per puzzle
Hello Daniel,
Tuesday, April 11, 2006, 3:26:06 AM, you wrote:
Today, I wrote a version using IOArray, hoping to get incredibly fast in-place
updating, and explicitly making copies via freeze and thaw when guessing is
required, but no luck (maybe I just don't know how to do it properly), spent
Mine's even faster now (at least on my computer, would you care to test it
on your's? If you don't want to get EnumSet, just change DiffArray to
Array, worked wonders for me), I'll dig into yours tomorrow to see what I
can get out of it to improve my algorithm.
Unforunately, no new inference
Moin Claus,
Am Montag, 10. April 2006 10:11 schrieben Sie:
Mine's even faster now (at least on my computer, would you care to test
it on your's? If you don't want to get EnumSet, just change DiffArray to
Array, worked wonders for me), I'll dig into yours tomorrow to see what
I can get out
I just ran a simple metric for the dancing-links solver.
The only real metric I could use was the number of coverOthers calls which
counts the number of selections made (there is no distinction between certainty
and guessing).
So the minimum # of selections is 81 (of which 17 are the free hints,
Am Samstag, 8. April 2006 10:21 schrieb Chris Kuklewicz:
Daniel Fischer wrote:
But, lo and behold, I also tried how plain Array fared in comparison to
DiffArray and ... reduced the running time to under ten minutes (a little
above for the list version), 5% GC time without -AxM, 1.2% with
Daniel Fischer wrote:
But, lo and behold, I also tried how plai Array fared in comparison to
DiffArray and ... reduced the running time to under ten minutes (a little
above for the list version), 5% GC time without -AxM, 1.2% with -A8M.
And I thought, DiffArrays were supposed to be fast!
Hello Daniel,
Saturday, April 8, 2006, 3:06:03 AM, you wrote:
And I thought, DiffArrays were supposed to be fast!
1. your arrays are too small (8 elements only)
2. DiffArray use internally MVars. with IORefs they will be a lot
faster
--
Best regards,
Bulat
Hello Chris,
Saturday, April 8, 2006, 12:21:07 PM, you wrote:
backtracking. And I can use STRef's to build it, instead of MVars.
may be it's better to use unboxed arrays/references?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
I have finished my cleanup of the dancing links based solver for Sudoku.
I don't have time to compare performance with the other programs that have been
posted recently, or to do more profiling of my code.
For those who will say It is ugly, imperative, and ugly! please remember this
is a
Am Samstag, 8. April 2006 02:20 schrieb Daniel Fischer:
Am Freitag, 7. April 2006 17:33 schrieben Sie:
Just out of curiosity, speed was not the objective when I wrote my
solver, I wanted to avoid guesswork (as much as possible), but in
comparison with Cale Gibbard's and Alson Kemp's
Am Samstag, 8. April 2006 20:28 schrieb Chris Kuklewicz:
I have finished my cleanup of the dancing links based solver for Sudoku.
I don't have time to compare performance with the other programs that have
been posted recently, or to do more profiling of my code.
Your dancing links:
ckSud
Hello Daniel,
Friday, April 7, 2006, 2:05:03 AM, you wrote:
I've cleaned up my solver, removed a lot of redundant inference steps and made
the board a DiffArray (is that really faster?).
btw, DiffArray implementation can be made significantly faster by
using IORefs instead of MVars
--
Best
Just out of curiosity, speed was not the objective when I wrote my solver, I
wanted to avoid guesswork (as much as possible), but in comparison with Cale
Gibbard's and Alson Kemp's solvers (which are much more beautifully coded),
it turned out that mine is blazingly fast, so are there faster
Am Freitag, 7. April 2006 01:50 schrieben Sie:
On Apr 6, 2006, at 6:05 PM, Daniel Fischer wrote:
I've also written a version using David F. Place's EnumSet instead
of [Int],
that takes less MUT time, but more GC time, so is slower on the
36,628 test,
but faster for a single puzzle.
Am Freitag, 7. April 2006 17:33 schrieben Sie:
Just out of curiosity, speed was not the objective when I wrote my
solver, I wanted to avoid guesswork (as much as possible), but in
comparison with Cale Gibbard's and Alson Kemp's solvers (which are much
more beautifully coded), it turned out
Curry does not have a constraint solver of its own. It
simply delegates all constraints to the FD solver of SICStus Prolog.
or that of SWI Prolog (which prompted my attempt to install Curry).
which was implemented by..hi, again!-) (*)
The all_different constraint subsumes the rules that
On Thu, 6 Apr 2006, Claus Reinke wrote:
Curry does not have a constraint solver of its own. It simply delegates all
constraints to the FD solver of SICStus Prolog.
or that of SWI Prolog (which prompted my attempt to install Curry).
which was implemented by..hi, again!-) (*)
The
Am Mittwoch, 5. April 2006 15:09 schrieb Chris Kuklewicz:
Henning Thielemann wrote:
On Mon, 3 Apr 2006, Jared Updike wrote:
or ambiguously) with your Sudoku solver? A rough mesaure of the
difficulty of the unsolved puzzle could be how long the solver took to
solve it (number of steps)
On Apr 6, 2006, at 6:05 PM, Daniel Fischer wrote:I've also written a version using David F. Place's EnumSet instead of [Int], that takes less MUT time, but more GC time, so is slower on the 36,628 test, but faster for a single puzzle. That's a curious result. Did you compile with optimization?
On Mon, 3 Apr 2006, Jared Updike wrote:
or ambiguously) with your Sudoku solver? A rough mesaure of the
difficulty of the unsolved puzzle could be how long the solver took to
solve it (number of steps) (and the number of possible solutions)? Are
puzzles with multiple solutions usually
Henning Thielemann wrote:
On Mon, 3 Apr 2006, Jared Updike wrote:
or ambiguously) with your Sudoku solver? A rough mesaure of the
difficulty of the unsolved puzzle could be how long the solver took to
solve it (number of steps) (and the number of possible solutions)? Are
puzzles with
On 4/3/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
It would also be nice to see some example sudoku solvers posted
on an `Idioms' page on haskell.org:
http://www.haskell.org/haskellwiki/Category:Idioms
someone could just create a new page 'Sudoku' and add the phrase
It solves sudoku puzzles. (What pleasure do people get by doing
these in their heads?!?)
probably the same you get from writing programs?-) figuring out the
rules, not getting lost in complexity, making something difficult work..
They are probably asking the same question: why take hours
Claus Reinke wrote:
It solves sudoku puzzles. (What pleasure do people get by doing
these in their heads?!?)
probably the same you get from writing programs?-) figuring out the
rules, not getting lost in complexity, making something difficult work..
From a human standpoint, there are
Chris wrote:
You need more than 5 examples. The truly evil puzzles are rarer than that.
Go
get the set of minimal puzzles and see how far your logic takes you.
Chris elucidated some of my questions before I finished writing my email...
Claus wrote:
(*) actually, that was a bit
since I haven't factored out the constraint propagation into a
general module, the core of my code is a lot longer than the Curry version
(about 60 additional lines, though I'm sure one could reduce that;-). the
only negative point I can find about the Curry example is that it isn't
obvious
Jared Updike wrote:
Chris wrote:
You need more than 5 examples. The truly evil puzzles are rarer than that.
Go
get the set of minimal puzzles and see how far your logic takes you.
Chris elucidated some of my questions before I finished writing my email...
Claus wrote:
(*) actually,
Hello
it seems that sudoku solver may be a good candidate for nofib suite /
language comparison shootout
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
bulat.ziganshin:
Hello
it seems that sudoku solver may be a good candidate for nofib suite /
language comparison shootout
It would also be nice to see some example sudoku solvers posted
on an `Idioms' page on haskell.org:
http://www.haskell.org/haskellwiki/Category:Idioms
someone could
Am Montag, 3. April 2006 18:52 schrieb Chris Kuklewicz:
Claus Reinke wrote:
It solves sudoku puzzles. (What pleasure do people get by doing
these in their heads?!?)
probably the same you get from writing programs?-) figuring out the
rules, not getting lost in complexity, making
Jared Updike wrote:
On 3/22/06, David F. Place [EMAIL PROTECTED] wrote:
...
It solves
sudoku puzzles. (What pleasure do people get by doing these in their
heads?!?)
They are probably asking the same question: why take hours to write a
program to do it when with my mad sudoku solving
Thanks for your helpful suggestions. I took them to heart and
incorporated many of them in a new version.
sudoku.hs
Description: Binary data
David F. Place
mailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing
Hi All,
I really appreciate all the help I received when I asked you to
critique my PrefixMap module a few weeks ago. I think I am making
good progress in correcting the lisp in my Haskell programming.
I'll be very grateful to anyone who can take a glance at the attached
short program
On 3/22/06, David F. Place [EMAIL PROTECTED] wrote:
Hi All,
I really appreciate all the help I received when I asked you to
critique my PrefixMap module a few weeks ago. I think I am making
good progress in correcting the lisp in my Haskell programming.
I'll be very grateful to anyone who
On Mar 22, 2006, at 2:16 PM, David F. Place wrote:
Hi All,
I really appreciate all the help I received when I asked you to
critique my PrefixMap module a few weeks ago. I think I am making
good progress in correcting the lisp in my Haskell programming.
I'll be very grateful to anyone
Robert Dockins wrote:
On Mar 22, 2006, at 2:16 PM, David F. Place wrote:
Hi All,
I really appreciate all the help I received when I asked you to
critique my PrefixMap module a few weeks ago. I think I am making
good progress in correcting the lisp in my Haskell programming.
The style
39 matches
Mail list logo
