On Sat, 06 Jul 2013 03:05:30 +, Steven D'Aprano wrote:
> That doesn't explain how you time it, only that you have a loop executing
> 100 times. Are you using time.time, or time.clock? (I trust you're not
> measuring times by hand with a stop watch.)
>
> I expect you're probably doing someth
On Fri, 05 Jul 2013 18:39:15 +, Helmut Jarausch wrote:
> On Fri, 05 Jul 2013 16:50:41 +, Steven D'Aprano wrote:
>
>> On Fri, 05 Jul 2013 16:07:03 +, Helmut Jarausch wrote:
>>
>>> The solution above take 0.79 seconds (mean of 100 calls) while the
>>> following version take 1.05 second
On 5 July 2013 17:25, MRAB wrote:
> For comparison, here's my solution:
Unfortunately, there are some sudokus that require guessing - your
algorithm will not solve those. A combination algorithm would be best,
AFAIK.
-
FWIW, this is my interpretation of the original algorithm:
from collec
On Fri, 05 Jul 2013 17:25:54 +0100, MRAB wrote:
> For comparison, here's my solution:
Your solution is very fast, indeed.
It takes 0.04 seconds (mean of 1000 runs) restoring "grid"
in between.
But that's a different algorithm which is IMHO more difficult to understand.
Many thanks,
Helmut
>
>
On Fri, 05 Jul 2013 16:50:41 +, Steven D'Aprano wrote:
> On Fri, 05 Jul 2013 16:07:03 +, Helmut Jarausch wrote:
>
>> The solution above take 0.79 seconds (mean of 100 calls) while the
>> following version take 1.05 seconds (mean of 100 calls):
>
> 1) How are you timing the calls?
I've p
On Fri, 05 Jul 2013 15:47:45 +, Helmut Jarausch wrote:
> > for r, row_lst in enumerate(Grid):
> > for c, val in enumerate(row_lst):
>
> I assume the creation of the temporary lists "row_list" is a bit
> expensive.
No temporary list is being created. The pre-existing list is just being
gr
On Fri, 05 Jul 2013 16:07:03 +, Helmut Jarausch wrote:
> The solution above take 0.79 seconds (mean of 100 calls) while the
> following version take 1.05 seconds (mean of 100 calls):
1) How are you timing the calls?
2) Don't use the mean, that's the wrong statistic when you are measuring
so
On 05/07/2013 16:17, Helmut Jarausch wrote:
On Fri, 05 Jul 2013 15:45:25 +0100, Oscar Benjamin wrote:
Presumably then you're now down to the innermost loop as a bottle-neck:
Possibilities= 0
for d in range(1,10) :
if Row_Digits[r,d] or Col_Digits[c,d] or Sqr_Digits[Sq_No,d]
On Fri, 05 Jul 2013 14:54:26 +, Helmut Jarausch wrote:
> On Fri, 05 Jul 2013 13:44:57 +0100, Fábio Santos wrote: May I suggest
> you avoid range and use enumerate(the_array) instead? It might be
> faster.
>
> How does this work?
>
> Given
>
> Grid= [[0 for j in range(9)] for i in range(9)]
On Fri, 05 Jul 2013 16:38:43 +0100, Oscar Benjamin wrote:
> On 5 July 2013 16:17, Helmut Jarausch wrote:
>>
>> I've tried the following version
>>
>> def find_good_cell() :
>> Best= None
>> minPoss= 10
>> for r,c in Grid :
>> if Grid[(r,c)] > 0 : continue
>
> Sorry, I think what I mea
On Fri, 05 Jul 2013 16:18:41 +0100, Fábio Santos wrote:
> On 5 Jul 2013 15:59, "Helmut Jarausch" wrote:
>>
>> On Fri, 05 Jul 2013 13:44:57 +0100, Fábio Santos wrote:
>> May I suggest you avoid range and use enumerate(the_array) instead? It
>> might be faster.
>>
>> How does this work?
>>
>> Given
On 5 July 2013 16:17, Helmut Jarausch wrote:
>
> I've tried the following version
>
> def find_good_cell() :
> Best= None
> minPoss= 10
> for r,c in Grid :
> if Grid[(r,c)] > 0 : continue
Sorry, I think what I meant was that you should have a structure
called e.g. Remaining which is th
On 5 July 2013 15:48, Helmut Jarausch wrote:
> On Fri, 05 Jul 2013 12:02:21 +, Steven D'Aprano wrote:
>
>> On Fri, 05 Jul 2013 10:53:35 +, Helmut Jarausch wrote:
>>
>>> Since I don't do any numerical stuff with the arrays, Numpy doesn't seem
>>> to be a good choice. I think this is an argu
On Fri, 05 Jul 2013 15:45:25 +0100, Oscar Benjamin wrote:
> Presumably then you're now down to the innermost loop as a bottle-neck:
>
> Possibilities= 0
> for d in range(1,10) :
> if Row_Digits[r,d] or Col_Digits[c,d] or Sqr_Digits[Sq_No,d] :
> continue
> Possibilitie
On 5 Jul 2013 15:59, "Helmut Jarausch" wrote:
>
> On Fri, 05 Jul 2013 13:44:57 +0100, Fábio Santos wrote:
> May I suggest you avoid range and use enumerate(the_array) instead? It
> might be faster.
>
> How does this work?
>
> Given
>
> Grid= [[0 for j in range(9)] for i in range(9)]
>
> for (r,c,v
On Fri, 05 Jul 2013 13:44:57 +0100, Fábio Santos wrote:
May I suggest you avoid range and use enumerate(the_array) instead? It
might be faster.
How does this work?
Given
Grid= [[0 for j in range(9)] for i in range(9)]
for (r,c,val) in (Grid) :
Helmut
--
http://mail.python.org/mailman/lis
On Fri, 05 Jul 2013 12:02:21 +, Steven D'Aprano wrote:
> On Fri, 05 Jul 2013 10:53:35 +, Helmut Jarausch wrote:
>
>> Since I don't do any numerical stuff with the arrays, Numpy doesn't seem
>> to be a good choice. I think this is an argument to add real arrays to
>> Python.
>
> Guido's t
On 5 July 2013 15:28, Helmut Jarausch wrote:
> On Fri, 05 Jul 2013 14:41:23 +0100, Oscar Benjamin wrote:
>
>> On 5 July 2013 11:53, Helmut Jarausch wrote:
>>> I even tried to use dictionaries instead of Numpy arrays. This version is a
>>> bit
>>> slower then the lists of lists version (7.2 secon
On Fri, 05 Jul 2013 14:41:23 +0100, Oscar Benjamin wrote:
> On 5 July 2013 11:53, Helmut Jarausch wrote:
>> I even tried to use dictionaries instead of Numpy arrays. This version is a
>> bit
>> slower then the lists of lists version (7.2 seconds instead of 6 second) but
>> still
>> much faster
On 5 July 2013 11:53, Helmut Jarausch wrote:
> I even tried to use dictionaries instead of Numpy arrays. This version is a
> bit
> slower then the lists of lists version (7.2 seconds instead of 6 second) but
> still
> much faster than the Numpy array solution.
When you switched to dictionaries
On 5 Jul 2013 11:58, "Helmut Jarausch" wrote:
>
> On Fri, 05 Jul 2013 11:13:33 +0100, Oscar Benjamin wrote:
>
> > My one comment is that you're not really making the most out of numpy
> > arrays. Numpy's ndarrays are efficient when each line of Python code
> > is triggering a large number of numer
On Fri, 05 Jul 2013 10:53:35 +, Helmut Jarausch wrote:
> Since I don't do any numerical stuff with the arrays, Numpy doesn't seem
> to be a good choice. I think this is an argument to add real arrays to
> Python.
Guido's time machine strikes again:
import array
By the way, I'm not exactly
On Fri, 05 Jul 2013 11:13:33 +0100, Oscar Benjamin wrote:
> My one comment is that you're not really making the most out of numpy
> arrays. Numpy's ndarrays are efficient when each line of Python code
> is triggering a large number of numerical computations performed over
> the array. Because of t
On 5 July 2013 09:22, Helmut Jarausch wrote:
> Hi,
>
> I have coded a simple algorithm to solve a Sudoku (probably not the first
> one).
> Unfortunately, it takes 13 seconds for a difficult problem which is more than
> 75 times slower
> than the same algorithm coded in C++.
> Is this to be expec
On Fri, 05 Jul 2013 10:38:35 +0100, Fábio Santos wrote:
> [Skipping to bottleneck]
>
>> def find_good_cell() :
>
> In this function you are accessing global variables a lot of times. Since
> accessing globals takes much more time than accessing locals, I advise you
> to assign them to local name
On 5 Jul 2013 09:29, "Helmut Jarausch" wrote:
>
> Hi,
>
> I have coded a simple algorithm to solve a Sudoku (probably not the first
one).
> Unfortunately, it takes 13 seconds for a difficult problem which is more
than 75 times slower
> than the same algorithm coded in C++.
> Is this to be expected
Hi,
I have coded a simple algorithm to solve a Sudoku (probably not the first one).
Unfortunately, it takes 13 seconds for a difficult problem which is more than
75 times slower
than the same algorithm coded in C++.
Is this to be expected or could I have made my Python version faster ***
without
27 matches
Mail list logo
