around a million times slower.
>
>Just try it. The example had a minimum of clues (drop one clue and
>you'll get multiple solutions).
>
>http://www.telegraph.co.uk/news/science/science-news/9359579/W
>orlds-harde
Just look at the contrived PyPy benchmarks, for a very tuned selected
sample you can be almost twice as fast as C - for a random algorithm
like the Sudoku solver, not specifically tuned, C is 30x faster. It
still boils down to the classic rules: static unboxed types and static
or preallocated m
mr.smit...@gmail.com:
> You say "neater implementation"
> I'll send you to the code-golf site:
> http://codegolf.stackexchange.com/a/446/38632 this is brute force.
> There are some really good implementations in other languages that
> arent brute force.
It ain't neater if it don't fit in your pos
it's impossible for a puzzle solution to
> be symmetric), and the wording made it sound like he was describing a
> property specific to the puzzle that I posted.
Thing is, if you are not careful in your comparisons, you might easily
get a good-looking time from one implementation and a lousy time from
another implementation because of a different traversal order.
That is why brute-force sudoku might not be as good for benchmark
testing as BertC was hoping.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Mar 30, 2015 at 7:57 PM, Ian Kelly wrote:
> On Mon, Mar 30, 2015 at 2:16 AM, Dave Angel wrote:
>> The relationship between row, column and box can be rearranged. Some of
>> these are already covered by the rotations proposed earlier, where for a 90
>> degree rotate, row becomes column an
On Mon, Mar 30, 2015 at 2:16 AM, Dave Angel wrote:
> The relationship between row, column and box can be rearranged. Some of
> these are already covered by the rotations proposed earlier, where for a 90
> degree rotate, row becomes column and column becomes row. But in a similar
> way each box c
On 03/30/2015 03:29 AM, Ian Kelly wrote:
On Mon, Mar 30, 2015 at 1:13 AM, Christian Gollwitzer wrote:
Am 30.03.15 um 08:50 schrieb Ian Kelly:
On Sun, Mar 29, 2015 at 12:03 PM, Marko Rauhamaa wrote:
Be careful with the benchmark comparisons. Ian's example can be solved
with the identical al
On Mon, Mar 30, 2015 at 1:13 AM, Christian Gollwitzer wrote:
> Am 30.03.15 um 08:50 schrieb Ian Kelly:
>>
>> On Sun, Mar 29, 2015 at 12:03 PM, Marko Rauhamaa wrote:
>>>
>>> Be careful with the benchmark comparisons. Ian's example can be solved
>>> with the identical algorithm in eight different w
Am 30.03.15 um 08:50 schrieb Ian Kelly:
On Sun, Mar 29, 2015 at 12:03 PM, Marko Rauhamaa wrote:
Be careful with the benchmark comparisons. Ian's example can be solved
with the identical algorithm in eight different ways (four corners, left
or right). I ran the example with my recent Python solv
On Sun, Mar 29, 2015 at 12:03 PM, Marko Rauhamaa wrote:
> BartC :
>
>> As Chris mentioned, when I say 'faster than C', I mean X running my
>> algorithm was faster then C running Marko's algoritim (on Ian's data).
>> This was just an illustration of algorithm being more important than
>> language.
Python 3.1: 1700 seconds (normal Python interpreter)
>>> PyPy: 93 seconds
>>> C unoptimised: 17 seconds (gcc -O0 32-bit)
>>> C optimised:3.3 seconds (gcc -O3 32-bit)
>
>> https://attractivechaos.wordpress.com/2011/06/19/an-incomple
On Wednesday, March 25, 2015 at 4:39:40 AM UTC-7, Marko Rauhamaa wrote:
> A lot of discussion was generated by the good, old fibonacci sequence. I
> have yet to find practical use for fibonacci numbers. However, the
> technique behind a sudoku solver come up every now and again in
&g
: 17 seconds (gcc -O0 32-bit)
C optimised:3.3 seconds (gcc -O3 32-bit)
https://attractivechaos.wordpress.com/2011/06/19/an-incomplete-review-of-sudoku-solver-implementations/
"The fastest Sudoku solver can solve even the hardest Sudoku in about 1
millisecond and solve most oth
On 29/03/2015 22:19, Mark Lawrence wrote:
On 29/03/2015 21:59, BartC wrote:
On 29/03/2015 00:12, Chris Angelico wrote:
On Sun, Mar 29, 2015 at 10:50 AM, BartC wrote:
Using the OP's algorithm, and testing with the 'hard' puzzle posted
by Ian
Kelly, I got these approximate results:
Python 3.1:
aster than C!
However it doesn't matter that the OP's algorithm is not great, as it
makes an interesting new benchmark.)
https://attractivechaos.wordpress.com/2011/06/19/an-incomplete-review-of-sudoku-solver-implementations/
--
My fellow Pythonistas, ask not what our language can do f
On 29/03/2015 21:59, BartC wrote:
On 29/03/2015 00:12, Chris Angelico wrote:
On Sun, Mar 29, 2015 at 10:50 AM, BartC wrote:
Using the OP's algorithm, and testing with the 'hard' puzzle posted
by Ian
Kelly, I got these approximate results:
Python 3.1: 1700 seconds (normal Python interp
On 29/03/2015 19:03, Marko Rauhamaa wrote:
BartC :
As Chris mentioned, when I say 'faster than C', I mean X running my
algorithm was faster then C running Marko's algoritim (on Ian's data).
This was just an illustration of algorithm being more important than
language.
Be careful with the benc
On 29/03/2015 00:12, Chris Angelico wrote:
On Sun, Mar 29, 2015 at 10:50 AM, BartC wrote:
Using the OP's algorithm, and testing with the 'hard' puzzle posted by Ian
Kelly, I got these approximate results:
Python 3.1: 1700 seconds (normal Python interpreter)
PyPy: 93 seconds
C
Mark Lawrence :
> One thing I have come to rely on over the years is never, ever trust
> your gut instincts about Python performance, you're almost inevitably
> wrong. When I first came across the Norvig solver I made a change,
> purely for fun, to replace two calls to len() with a single call and
On 29/03/2015 19:03, Marko Rauhamaa wrote:
BartC :
As Chris mentioned, when I say 'faster than C', I mean X running my
algorithm was faster then C running Marko's algoritim (on Ian's data).
This was just an illustration of algorithm being more important than
language.
Be careful with the benc
BartC :
> As Chris mentioned, when I say 'faster than C', I mean X running my
> algorithm was faster then C running Marko's algoritim (on Ian's data).
> This was just an illustration of algorithm being more important than
> language.
Be careful with the benchmark comparisons. Ian's example can be
of any interest, this non-Python code is here:
http://pastebin.com/5cXd2Pef )
I've managed to create a Python version of my 'brute force' sudoku solver:
http://pastebin.com/CKmHmBKm
It was hard going as I don't normally write Python. But it worked
practically first ti
On 29/03/2015 11:35, Steven D'Aprano wrote:
That's why I can't help but feel that, *given the description we've seen*,
perhaps Bart's brute force code doesn't actually solve the problem, and
that's why it is so fast. I'm reminded of the recent thread where somebody
claimed to have a significant
On 29/03/2015 04:06, Steven D'Aprano wrote:
On Sun, 29 Mar 2015 10:50 am, BartC wrote:
But using X *and* my own brute-force algorithm, the same puzzle took 2
seconds to solve - faster than C!
But, when you tell me that your very own personal interpreted language,
which I assume nobody else
On Sun, Mar 29, 2015 at 9:35 PM, Steven D'Aprano
wrote:
> Anyway, we don't really know where the confusion lies. Perhaps the
> description is misleading, or I'm just confused, or Bart's idea of brute
> force is not the same as my idea of brute force, or perhaps he really is a
> super-genius who ha
On Sun, 29 Mar 2015 03:10 pm, Chris Angelico wrote:
> On Sun, Mar 29, 2015 at 2:06 PM, Steven D'Aprano
> wrote:
>> On Sun, 29 Mar 2015 10:50 am, BartC wrote:
>>
>>> (X is my own interpreted language, which is where my interest in this
>>> is. This had been generally faster than Python until PyPy
C do not exist.
Just look at the contrived PyPy benchmarks, for a very tuned selected
sample you can be almost twice as fast as C - for a random algorithm
like the Sudoku solver, not specifically tuned, C is 30x faster. It
still boils down to the classic rules: static unboxed types and static
On Sun, Mar 29, 2015 at 2:06 PM, Steven D'Aprano
wrote:
> On Sun, 29 Mar 2015 10:50 am, BartC wrote:
>
>> (X is my own interpreted language, which is where my interest in this
>> is. This had been generally faster than Python until PyPy came along. It
>> does however use a pure byte-code interpret
On Sun, 29 Mar 2015 10:50 am, BartC wrote:
> (X is my own interpreted language, which is where my interest in this
> is. This had been generally faster than Python until PyPy came along. It
> does however use a pure byte-code interpreter, so the result is not too
> bad.
>
> But using X *and* my
On Sun, Mar 29, 2015 at 10:50 AM, BartC wrote:
> Using the OP's algorithm, and testing with the 'hard' puzzle posted by Ian
> Kelly, I got these approximate results:
>
> Python 3.1: 1700 seconds (normal Python interpreter)
> PyPy: 93 seconds
> C unoptimised: 17 seconds (gc
On 28/03/2015 03:39, Sayth wrote:
Good test for pypy to see where it's speed sits between C and Python.
I've spent the last hour or so doing such tests.
Using the OP's algorithm, and testing with the 'hard' puzzle posted by
Ian Kelly, I got these approximate results:
Python 3.1: 1700 se
If you are interested, I have written a python (wxPython GUI) for solving Sudoku
problems. It even has a "hint" mode that can be used to lead you to a solution.
I have tested it on the world's hardest Sudoku (published by a Finish
mathematician) and it solves it very fast. I ha
he context-sensitive languages.
> So it's an open question as to whether or not you could prove a Sudoku grid
> solvable using a Perl regex. Python regexes are less powerful than Perl's,
> so if you can't do it in Perl, you can't do it in Python.
As somebody else in the
Good test for pypy to see where it's speed sits between C and Python.
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, 28 Mar 2015 05:18 am, sohcahto...@gmail.com wrote:
> On Friday, March 27, 2015 at 7:10:54 AM UTC-7, Dave Angel wrote:
>> I know, let's use "regular expressions"
>>
>>
>> --
>> DaveA
>
> You jest, but...
>
> http://www.perlmonks.org/?node_id=471168
I'm not a Perl expert, but I call
On Sat, 28 Mar 2015 01:19 am, Chris Angelico wrote:
> Part of me is quaking in fear... the other part looking on in morbid
> fascination. Can you build a regexp that proves a Sudoku grid
> solvable?
Perl's regular expressions can run arbitrary code using ?{...} which
technica
Chris Angelico wrote:
Part of me is quaking in fear... the other part looking on in morbid
fascination. Can you build a regexp that proves a Sudoku grid
solvable?
Well, it's *theoretically* possible, since there are a finite
number of possible sudoku puzzles, so if nothing else you
could
On 03/27/2015 07:09 AM, Dave Angel wrote:
[snip]
I know, let's use "regular expressions"
This is totally OT, but...
There was a recent (2015-03-23) item on The Daily WTF web site concerning
regular expressions.
Take a look at http://thedailywtf.com/articles/regularly-expressing-hate
On 26/03/2015 00:07, Ian Kelly wrote:
On Wed, Mar 25, 2015 at 2:31 PM, Marko Rauhamaa wrote:
It takes about 2 seconds for my Python program to find the answer but it
spends a total of 110 seconds to exhaust the problem space.
The analogous C program finished the whole thing in 200 millisecon
On Friday, March 27, 2015 at 7:10:54 AM UTC-7, Dave Angel wrote:
> On 03/27/2015 09:56 AM, Marko Rauhamaa wrote:
> > "Frank Millman" :
> >
> >> So what I am talking about is called a "satisfactory" puzzle, which is
> >> a subset of a "proper" puzzle.
> >
> > That is impossible to define, though, be
On 27/03/2015 14:09, Dave Angel wrote:
On 03/27/2015 09:56 AM, Marko Rauhamaa wrote:
"Frank Millman" :
So what I am talking about is called a "satisfactory" puzzle, which is
a subset of a "proper" puzzle.
That is impossible to define, though, because some people are mental
acrobats and can d
ory" patterns can involve a truckload of
>> trial and error.
>>
>
> I know, let's use "regular expressions"
Part of me is quaking in fear... the other part looking on in morbid
fascination. Can you build a regexp that proves a Sudoku grid
solvable?
OW
On 03/27/2015 09:56 AM, Marko Rauhamaa wrote:
"Frank Millman" :
So what I am talking about is called a "satisfactory" puzzle, which is
a subset of a "proper" puzzle.
That is impossible to define, though, because some people are mental
acrobats and can do a lot of deep analysis in their heads.
On Sat, Mar 28, 2015 at 12:56 AM, Marko Rauhamaa wrote:
> "Frank Millman" :
>
>> So what I am talking about is called a "satisfactory" puzzle, which is
>> a subset of a "proper" puzzle.
>
> That is impossible to define, though, because some people are mental
> acrobats and can do a lot of deep ana
On Sat, Mar 28, 2015 at 12:48 AM, Dave Angel wrote:
> On the other hand, I play some "games" which I can only solve with the aid
> of a computer. Is that "cheating"? Not for some games. I have some
> challenges for which I need/prefer to use a wrench, or a screwdriver, or a
> lawnmower. That d
"Frank Millman" :
> So what I am talking about is called a "satisfactory" puzzle, which is
> a subset of a "proper" puzzle.
That is impossible to define, though, because some people are mental
acrobats and can do a lot of deep analysis in their heads. What's
satisfactory to you may not be satisfa
On 03/27/2015 09:35 AM, Frank Millman wrote:
"Dave Angel" wrote in message
news:551557b3.5090...@davea.name...
But now I have to disagree about "true Sudoku puzzle." As we said
earlier, it might make sense to say that puzzles that cannot be solved
that way are not reaso
On 03/27/2015 09:25 AM, Chris Angelico wrote:
On Sat, Mar 28, 2015 at 12:14 AM, Dave Angel wrote:
But now I have to disagree about "true Sudoku puzzle." As we said earlier,
it might make sense to say that puzzles that cannot be solved that way are
not reasonable ones to put in a hu
"Dave Angel" wrote in message
news:551557b3.5090...@davea.name...
>
> But now I have to disagree about "true Sudoku puzzle." As we said
> earlier, it might make sense to say that puzzles that cannot be solved
> that way are not reasonable ones to put in a huma
On Sat, Mar 28, 2015 at 12:14 AM, Dave Angel wrote:
> But now I have to disagree about "true Sudoku puzzle." As we said earlier,
> it might make sense to say that puzzles that cannot be solved that way are
> not reasonable ones to put in a human Sudoku book. But why isn&#x
inues until the
contents of all cells have been identified."
Any puzzle that cannot be solved by this method does not qualify as a true
Sudoku puzzle.
That's reasonable wording. Another way to differentiate between the
"trial and error" that we're objecting to and the &quo
l the
> contents of all cells have been identified."
>
> Any puzzle that cannot be solved by this method does not qualify as a true
> Sudoku puzzle.
That's reasonable wording. Another way to differentiate between the
"trial and error" that we're objecting to and the &
"Marko Rauhamaa" wrote in message
news:87fv8sndw1@elektro.pacujo.net...
> "Frank Millman" :
>
>> Here is another python-based sudoku solver -
>>
>> http://www.ics.uci.edu/~eppstein/PADS/Sudoku.py
>>
>>>From its docstring -
>&g
Am 26.03.15 um 00:04 schrieb Mark Lawrence:
On 25/03/2015 22:50, Steven D'Aprano wrote:
On Wed, 25 Mar 2015 10:39 pm, Marko Rauhamaa wrote:
I have yet to find practical use for fibonacci numbers.
Many people have failed to find practical uses for many things from
mathematics. Doesn't mean th
Here's my Python sudoku solver which I wrote about 10 years ago.
http://petef.22web.org/sudoku/
It works by applying the solving techniques I came up with. No trial and
error or backtracking is used, so it is not up to cracking the very
hardest puzzles. Run time is 15 ms to 45 ms on a
tracking engine and logic variables of that language.
>>
>> http://en.wikipedia.org/wiki/Lean_theorem_prover>
>
> Sure, but what has this to do with the statement that *sudoku* should
> not require trial and error to solve?
Trial-and-error was presented in opposition to log
fact, the "trial-and-error" technique is used in automated theorem
> proving:
>
> Lean provers are generally implemented in Prolog, and make proficient
> use of the backtracking engine and logic variables of that language.
>
> http://en.wikipedia.org/wiki/Lean_theorem
Ian Kelly :
> On Thu, Mar 26, 2015 at 8:23 AM, Marko Rauhamaa wrote:
>> That's trial and error, aka, reductio ad absurdum.
>
> Okay, I've probably used single-lookahead trial and error in my
> reasoning at some point. But the example you give is equivalent to the
> deductive process "That can't b
Dave Angel :
> When in a playful mood, I wonder if all the Sudoku puzzles out there
> are just permutations of a few hundred written by Will Shortz.
A sudoku solver can be trivially turned into a puzzle gen
On Fri, Mar 27, 2015 at 2:03 AM, Dave Angel wrote:
> On 03/26/2015 10:41 AM, Chris Angelico wrote:
> that's already been proven. So, that's why I would avoid guessing.
>>
>>
>> I've written a lot of solvers for various puzzles. Minesweeper,
>> Sud
On Thu, Mar 26, 2015 at 8:23 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> I don't think that I have used trial and error, in my head or
>> otherwise, in any sudoku I have ever solved.
>
> Of course you have. "This here can't be a 2 because if it were a 2, t
On 03/26/2015 10:41 AM, Chris Angelico wrote:
that's already been proven. So, that's why I would avoid guessing.
I've written a lot of solvers for various puzzles. Minesweeper,
Sudoku, a binary Sudoku-like puzzle that I don't really have a good
name for, several others. Ev
On Fri, Mar 27, 2015 at 1:14 AM, Dave Angel wrote:
> On 03/26/2015 08:37 AM, Chris Angelico wrote:
>> Nothing. And solving a Sudoku puzzle - or any other puzzle - should
>> require no guessing. It should be possible to solve purely by logic.
>> Same goes for every other kin
Ian Kelly :
> I don't think that I have used trial and error, in my head or
> otherwise, in any sudoku I have ever solved.
Of course you have. "This here can't be a 2 because if it were a 2, that
there would have to be a 5, which is impossible. Thus, the only
remaining a
Marko Rauhamaa :
> I have optimized my solution slightly:
>
> 1. precalculated integer division operations (big savings)
>
> 2. interned integers (little savings)
>
> The example above now finishes in 41 minutes on my computer. (The C
> version finishes in 13 seconds).
Any considered harmfull
On 03/26/2015 08:37 AM, Chris Angelico wrote:
On Thu, Mar 26, 2015 at 11:26 PM, Marko Rauhamaa wrote:
"Frank Millman" :
Here is another python-based sudoku solver -
http://www.ics.uci.edu/~eppstein/PADS/Sudoku.py
>From its docstring -
"A proper Sudoku puzzle must have
On Mar 26, 2015 6:31 AM, "Marko Rauhamaa" wrote:
>
> "Frank Millman" :
>
> > Here is another python-based sudoku solver -
> >
> > http://www.ics.uci.edu/~eppstein/PADS/Sudoku.py
> >
> >>From its docstring -
> >
> > "A
On Thu, Mar 26, 2015 at 11:26 PM, Marko Rauhamaa wrote:
> "Frank Millman" :
>
>> Here is another python-based sudoku solver -
>>
>> http://www.ics.uci.edu/~eppstein/PADS/Sudoku.py
>>
>>>From its docstring -
>>
>> "A proper Sudoku p
"Frank Millman" :
> Here is another python-based sudoku solver -
>
> http://www.ics.uci.edu/~eppstein/PADS/Sudoku.py
>
>>From its docstring -
>
> "A proper Sudoku puzzle must have a unique solution, and it should be
> possible to reach that solution by
Abhiram R :
> On Thu, Mar 26, 2015 at 8:54 AM, Ian Kelly wrote:
>> On Wed, Mar 25, 2015 at 8:56 PM, Abhiram R wrote:
>>> On Mar 26, 2015 5:39 AM, "Ian Kelly" wrote:
$ cat sudoku2.dat
. . . 7 . . . . .
1 . . . . . . . .
. . . 4 3 . 2 . .
. . . . . . . . 6
. . . 5 .
"Marko Rauhamaa" wrote in message
news:87r3sdnw5t@elektro.pacujo.net...
>
>
> I post below a sudoku solver. I eagerly await neater implementations (as
> well as bug reports).
>
Here is another python-based sudoku solver -
http://www.ics.uci.edu/~eppstein/
On Thu, Mar 26, 2015 at 8:54 AM, Ian Kelly wrote:
> On Wed, Mar 25, 2015 at 8:56 PM, Abhiram R wrote:
>>
>> On Mar 26, 2015 5:39 AM, "Ian Kelly" wrote:
>>>
>>
>>> "Hard" for a human doesn't necessarily mean "hard" for a programmatic
>>> solver in this case. Try your solver on this one:
>>>
>>> $
On Wed, Mar 25, 2015 at 8:56 PM, Abhiram R wrote:
>
> On Mar 26, 2015 5:39 AM, "Ian Kelly" wrote:
>>
>
>> "Hard" for a human doesn't necessarily mean "hard" for a programmatic
>> solver in this case. Try your solver on this one:
>>
>> $ cat sudoku2.dat
>> . . . 7 . . . . .
>> 1 . . . . . . . .
>>
On Mar 26, 2015 5:39 AM, "Ian Kelly" wrote:
>
> "Hard" for a human doesn't necessarily mean "hard" for a programmatic
> solver in this case. Try your solver on this one:
>
> $ cat sudoku2.dat
> . . . 7 . . . . .
> 1 . . . . . . . .
> . . . 4 3 . 2 . .
> . . . . . . . . 6
> . . . 5 . 9 . . .
> . .
slower.
>
> Just try it. The example had a minimum of clues (drop one clue and
> you'll get multiple solutions).
>
> http://www.telegraph.co.uk/news/science/science-news/9359579/W
> orlds-hardest-sud
On 25/03/2015 22:50, Steven D'Aprano wrote:
On Wed, 25 Mar 2015 10:39 pm, Marko Rauhamaa wrote:
I have yet to find practical use for fibonacci numbers.
Many people have failed to find practical uses for many things from
mathematics. Doesn't mean they don't exist:
http://en.wikipedia.org/wiki
On Wed, 25 Mar 2015 10:39 pm, Marko Rauhamaa wrote:
> I have yet to find practical use for fibonacci numbers.
Many people have failed to find practical uses for many things from
mathematics. Doesn't mean they don't exist:
http://en.wikipedia.org/wiki/Fibonacci_number#Applications
--
Steven
On Thu, Mar 26, 2015 at 7:31 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> The test puzzle that you posted has 23 values already filled in. How
>> does it perform on harder puzzles with only 17 clues (the proven
>> minimum)? One would expect it to be around a million times slower.
>
> Just try it.
ou'll get multiple solutions).
http://www.telegraph.co.uk/news/science/science-news/9359579/W
orlds-hardest-sudoku-can-you-crack-it.html> mentions this puzzle:
8 . . . . . . . .
. . 3 6 . . . . .
. 7 . . 9 .
On Wed, Mar 25, 2015 at 1:37 PM, Marko Rauhamaa wrote:
> John Ladasky :
>
>> On Wednesday, March 25, 2015 at 4:39:40 AM UTC-7, Marko Rauhamaa wrote:
>>
>>> I post below a sudoku solver. I eagerly await neater implementations (as
>>> well as bug reports).
>
John Ladasky :
> On Wednesday, March 25, 2015 at 4:39:40 AM UTC-7, Marko Rauhamaa wrote:
>
>> I post below a sudoku solver. I eagerly await neater implementations (as
>> well as bug reports).
>
> So, it's a brute-force, recursive solver? The code is nice and short
On Wed, Mar 25, 2015 at 12:44 PM, John Ladasky
wrote:
> On Wednesday, March 25, 2015 at 4:39:40 AM UTC-7, Marko Rauhamaa wrote:
>
>> I post below a sudoku solver. I eagerly await neater implementations (as
>> well as bug reports).
>
> So, it's a brute-force, recurs
On Wednesday, March 25, 2015 at 4:39:40 AM UTC-7, Marko Rauhamaa wrote:
> I post below a sudoku solver. I eagerly await neater implementations (as
> well as bug reports).
So, it's a brute-force, recursive solver? The code is nice and short. But I
bet it takes a long time to ru
A lot of discussion was generated by the good, old fibonacci sequence. I
have yet to find practical use for fibonacci numbers. However, the
technique behind a sudoku solver come up every now and again in
practical situations.
I post below a sudoku solver. I eagerly await neater implementations
Sorry.
Won't happen again.
signing off this topic.
Eric.
--
http://mail.python.org/mailman/listinfo/python-list
On 31 March 2013 23:34, Dave Angel wrote:
>[...] With my Python
> 2.7.2, exit(something) with something being a string prints the string and
> then exits. Nowhere have I seen that documented, and I thought it either
> took an int or nothing.
It is documented, just not exactly where you'd expect
On Mon, Apr 1, 2013 at 9:27 AM, Eric Parry wrote:
> [ chomp 128 lines of quoted text ]
>
> I tried all those things. The program keeps running after the solution in
> every case. Never mind. It won't do that in VBA when I finish it.
> Eric.
You have just spammed us with, and I counted them, one
On 03/31/2013 06:03 PM, Eric Parry wrote:
I think in the original it was exit(a). That did not work either.
There you go again. "Did not work" tells us very little. With my
Python 2.7.2, exit(something) with something being a string prints the
string and then exits. Nowhere have I s
On Monday, April 1, 2013 8:33:47 AM UTC+10:30, Eric Parry wrote:
> On Sunday, March 31, 2013 9:45:36 AM UTC+10:30, Dave Angel wrote:
>
> > On 03/30/2013 06:06 PM, Eric Parry wrote:
>
> >
>
> > > On Saturday, March 30, 2013 8:41:08 AM UTC+10:30, Dave Angel wrote:
>
> >
>
> > >> On 03/29/2013
On Sunday, March 31, 2013 9:45:36 AM UTC+10:30, Dave Angel wrote:
> On 03/30/2013 06:06 PM, Eric Parry wrote:
>
> > On Saturday, March 30, 2013 8:41:08 AM UTC+10:30, Dave Angel wrote:
>
> >> On 03/29/2013 05:47 PM, Eric Parry wrote:
>
> >>
>
> >>>
>
> >>
>
> >> Sometimes a bug in such a fun
On 03/30/2013 06:06 PM, Eric Parry wrote:
On Saturday, March 30, 2013 8:41:08 AM UTC+10:30, Dave Angel wrote:
On 03/29/2013 05:47 PM, Eric Parry wrote:
Sometimes a bug in such a function will cause it to run indefinitely,
and/or to overflow the stack. I don't see such a bug in this funct
On Saturday, March 30, 2013 8:41:08 AM UTC+10:30, Dave Angel wrote:
> On 03/29/2013 05:47 PM, Eric Parry wrote:
>
> >
>
> >>
>
> >>
>
> > That explains why the program keeps running after a solution is found.
>
>
>
> A recursive function can be designed to find all solutions, in which
>
On 03/29/2013 05:47 PM, Eric Parry wrote:
That explains why the program keeps running after a solution is found.
A recursive function can be designed to find all solutions, in which
case it would (as you say) keep running.
The function you posted in the first place uses exit() to avoi
On Friday, March 29, 2013 9:15:36 AM UTC+10:30, Chris Angelico wrote:
> On Fri, Mar 29, 2013 at 9:11 AM, Eric Parry wrote:
>
> > Thank you for that explanation.
>
> > No, I do not understand recursion. It is missing from my Python manual. I
> > would be pleased to receive further explanation fr
On Fri, Mar 29, 2013 at 9:11 AM, Eric Parry wrote:
> Thank you for that explanation.
> No, I do not understand recursion. It is missing from my Python manual. I
> would be pleased to receive further explanation from anyone.
If you already know what recursion is, just remember the answer.
Otherwi
On Friday, March 29, 2013 9:58:27 AM UTC+10:30, Dave Angel wrote:
> On 03/28/2013 06:11 PM, Eric Parry wrote:
>
> > On Thursday, March 28, 2013 3:06:02 PM UTC+10:30, Dave Angel wrote:
>
>
>
>
>
>
>
> >>
>
> >>
>
> >> Are you familiar with recursion? Notice the last line in the functi
On 03/28/2013 06:11 PM, Eric Parry wrote:
On Thursday, March 28, 2013 3:06:02 PM UTC+10:30, Dave Angel wrote:
Are you familiar with recursion? Notice the last line in the function
r() calls the function r() inside a for loop.
So when r() returns, you're back inside the next level up o
On Thursday, March 28, 2013 3:06:02 PM UTC+10:30, Dave Angel wrote:
> On 03/27/2013 11:00 PM, Eric Parry wrote:
>
> > On Wednesday, March 27, 2013 6:28:01 PM UTC+10:30, Ulrich Eckhardt wrote:
>
> >>
>
>
> http://wiki.python.org/moin/GoogleGroupsPython >
>
> >
>
> > Thank you for your e
On 03/27/2013 11:00 PM, Eric Parry wrote:
On Wednesday, March 27, 2013 6:28:01 PM UTC+10:30, Ulrich Eckhardt wrote:
http://wiki.python.org/moin/GoogleGroupsPython >
Thank you for your explanation.
I noticed that in this particular puzzle when it ran out of candidates in a
particular cyc
On Wednesday, March 27, 2013 6:28:01 PM UTC+10:30, Ulrich Eckhardt wrote:
> Am 27.03.2013 06:44, schrieb Eric Parry:
>
> > I downloaded the following program from somewhere using a link from
>
> > Wikipedia and inserted the “most difficult Sudoku puzzle ever” string
>
&g
1 - 100 of 156 matches
Mail list logo
