Hello
The SQLite version is 3.8.4 by now and this is stil about the sudoku
solving. I studied Norvigs algorithm (Python) http://norvig.com/sudoku.html
. It is possible to achieve this method in SQL.
A very important difference between Norvigs programme and the SQLite
example is however
Hi Edzard,
I just reproduced your test.
Indeed :
- you probably blew-up everything running SQL sudoku on this planet :
. 'hardest1' in under 2 seconds on my machine,
. 'eastermonster1' in 43ms.
- with Norvig's method and available SQLite syntax.
Each of these feats is jaw-dropping.
Op 16 mrt 2014, om 16:45 heeft big stone het volgende geschreven:
Hi Edzard,
I just reproduced your test.
Indeed :
- you probably blew-up everything running SQL sudoku on this planet :
. 'hardest1' in under 2 seconds on my machine,
. 'eastermonster1' in 43ms.
- with Norvig's method and
Hi again,
I confess I have difficulties to diggest your code.
From your experience to reach this success, would you have some hints for
SQLite team that would allow the code to become more easy to read and stay
performant ?
Example :
- a non-performant implementation of 'this' required 'that'
Don't say postgresql is slower :
- I remember now I did then implement the norvig postgresql,
- and it manages a 20% win over your solution with today postgresql 9.3.2.3.
Anyway, it's indeed a less inefficient run for now between SQL motors.
It remains to be seen if improving SQLite in sudoku
Congratulations, *E.Pasma* !
You indeed won the brute force sudoku speed competition for sqlite 3.8.3
by a factor of x2.5 on my PC !
D. Richard Hipp is still tuning the CTE implementation, so competition may
be less slow with 3.8.4.
To get clother to python speed
Op 9 feb 2014, om 13:19 heeft big stone het volgende geschreven:
Congratulations, *E.Pasma* !
You indeed won the brute force sudoku speed competition for sqlite
3.8.3
by a factor of x2.5 on my PC !
D. Richard Hipp is still tuning the CTE implementation, so
competition may
be less slow
Hi,
You're right,' recommands' is not in the code, but was not run anymore
either.
The x table cte definition should be removed, as the final request use
only q.
Anyway, after all this algorithmic surgery, Postgresql was slower with the
'optimization' algorithm than with the brute force.
Op 9 feb 2014, om 20:50 heeft big stone het volgende geschreven:
Hi,
You're right,' recommands' is not in the code, but was not run anymore
either.
The x table cte definition should be removed, as the final
request use
only q.
Anyway, after all this algorithmic surgery, Postgresql was
Op 6 feb 2014, om 16:46 heeft Simon Slavin het volgende geschreven:
On 6 Feb 2014, at 7:15am, big stone stonebi...@gmail.com wrote:
If we wish to have SQLite + Python combination to become reference
choice
in education, I would think that priority list should be :
Just to remind you that
On 6 Feb 2014, at 7:15am, big stone stonebi...@gmail.com wrote:
If we wish to have SQLite + Python combination to become reference choice
in education, I would think that priority list should be :
Just to remind you that you're posting to the SQLite list. Most of those are
things that would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/14 23:15, big stone wrote:
APSW looks indeed great for specialised installations.
The intention behind APSW is a Python wrapper for SQLite3. It does
everything the SQLite way where applicable. It advances with SQLite
meaning new versions
Op 1 feb 2014, om 08:29 heeft big stone het volgende geschreven:
Maybe Chrismas will be in february this year :
http://bugs.python.org/issue20465
Whatever will be the answer from the python team, THANKS a lot Mr
Hipp, Mr
Kennedy, and Mr Mistachkin for making it possible !
Hello,
APSW looks indeed great for specialised installations.
If we wish to have SQLite + Python combination to become reference choice
in education, I would think that priority list should be :
- fixing true problems among those listed in http://bugs.python.org/; with
search the keyword SQLite
Maybe Chrismas will be in february this year :
http://bugs.python.org/issue20465
Whatever will be the answer from the python team, THANKS a lot Mr Hipp, Mr
Kennedy, and Mr Mistachkin for making it possible !
___
sqlite-users mailing list
On Sat, Jan 18, 2014 at 3:38 PM, big stone stonebi...@gmail.com wrote:
And :
- python3.4 is still in beta also, not a released product.
- sadly first RC candidate 1 is February 9, 2014, 2 days earlier.
Sqlite was so close now, *so close* to achieve this goal ...
Maybe you could get the
Hi Keith,
Indeed just removing the CTE creation of the DIGITS makes Dan's version up
to speed.
Would the wholenumber external SQLite module help :
- to make SQLite code cleaner ? (like generate_series of Postgresql, or
dual of Oracle)
- still provide the same speed-up ?
Portfolio of typical
: [sqlite] Solving the Sudoku with SQlite 3.8.3 trunk
Hi Keith,
Indeed just removing the CTE creation of the DIGITS makes Dan's version
up
to speed.
Would the wholenumber external SQLite module help :
- to make SQLite code cleaner ? (like generate_series of Postgresql, or
dual of Oracle)
- still
sudoku !
drop table if exists gen9;
create table gen9(z);
insert into gen9 values
('1'),('2'),('3'),('4'),('5'),('6'),('7'),('8'),('9');
drop table if exists initial;
create table initial ( s, ind) ;
insert into initial select sud, instr( sud, ' ') from
(SELECT '53 76 195986 8
Beaten by minutes!
/* The input suduko. */
WITH RECURSIVE input(sud) AS (
VALUES(
'53 76 195986 8 6 34 8 3 17 2 6 6 28
419 58 79'
)
),
/* A table filled with digits 1..9, inclusive. */
digits(z, lp) AS (
VALUES('1', 1)
UNION ALL SELECT
I have to say thats it been a long time since I sat back and was amazed by what
people can do.
My knowledge of SQL is limited, whilst I recognise it is a functional language,
I had no idea you could solve Sudoku in it.
I take my hat off to the real experts. The downside of this is I now
Let me try again. Some spaces were missing from the input
in the parent post:
/* The input suduko. */
WITH RECURSIVE input(sud) AS (
VALUES(
'53..76..195986.8...6...34..8.3..17...2...6.628419..58..79'
)
),
/* A table filled with digits 1..9, inclusive. */
digits(z,
Recursive CTE are really fun to :
- describe algorithms in sql,
- measure sql motor speed.
For the hardest sudoku at hand that I have:
'8..36..7..9.2...5...7...457.1...3...168..85...1..94..'
- my badly written sql takes about 3'40, (on my windows pc)
- your neater
I'm still making desesperate prayers to have this SQLite3.8.3 in Python3.4.
Python3.4 beta2 is using in SQLite3.8.1
SQL CTE motor inside ! could be a big incentive for Python2.X users to
switch to Python 3.4.
___
sqlite-users mailing list
On 18 Jan 2014, at 7:27pm, big stone stonebi...@gmail.com wrote:
I'm still making desesperate prayers to have this SQLite3.8.3 in Python3.4.
Python3.4 beta2 is using in SQLite3.8.1
Talk to the Python folks on the Python dev list as soon as possible:
On 18 Jan 2014, at 7:30pm, Simon Slavin slav...@bigfraud.org wrote:
On 18 Jan 2014, at 7:27pm, big stone stonebi...@gmail.com wrote:
I'm still making desesperate prayers to have this SQLite3.8.3 in Python3.4.
Python3.4 beta2 is using in SQLite3.8.1
Talk to the Python folks on the
On Sat, Jan 18, 2014 at 2:34 PM, Simon Slavin slav...@bigfraud.org wrote:
I'm sorry, I withdraw that. I just remembered that SQLite 3.8.3 is still
in beta. It would be a bad idea to include a beta library in a released
product. So whether it gets included or not depends on comparing the
And :
- python3.4 is still in beta also, not a released product.
- sadly first RC candidate 1 is February 9, 2014, 2 days earlier.
Sqlite was so close now, *so close* to achieve this goal ...
very sad.
___
sqlite-users mailing list
- my badly written sql takes about 3'40, (on my windows pc)
- your neater version takes about 7'20,(on my windows pc)
== Do you see the same ratio ? I don't catch why yours is slower.
One uses tables for the join constants and the other (slower one) dynamically
regenerates the constant table
- my badly written sql takes about 3'40, (on my windows pc)
- your neater version takes about 7'20,(on my windows pc)
== Do you see the same ratio ? I don't catch why yours is slower.
One uses tables for the join constants and the other (slower one)
dynamically regenerates the constant table
Hello,
I'm trying to do the SQLite version of the sudoku solver that exist here in
POSTGRESQL
(here : http://wiki.postgresql.org/wiki/Sudoku_puzzle)
I'm at this stage below currently.
could anyone help me ? I have a syntax error , and a bit confuse where it
can be (not sure about the modulo
hello again,
I get the message of error OperationalError: circular reference: x
from the recursive CTE below.
Is it a syntax error or a bug ?
drop table if exists gen9;
drop table if exists genx;
create table gen9(z);
insert into gen9 values
I think this should work, but with current almagation avalaible for
download sqlite-amalgamation-201401171527, I get nothing.
Has anyone a clue ?
drop table if exists gen9;
drop table if exists genx;
drop table if exists initial;
create table gen9(z);
insert into gen9 values
On Jan 17, 2014, at 11:26 PM, big stone stonebi...@gmail.com wrote:
Has anyone a clue ?
No. But this is what Charlie the Unicorn has to say on the subject:
Oh God you guys. This better be pretty important. Is the meadow on fire?
___
sqlite-users
34 matches
Mail list logo