Prev: CL to generate native docs
Next: ATTENTION: RETAIL FANZ OUT HERE : )/ CHECK THIS OUT : )
From: Pillsy on 5 Feb 2010 10:35
On Feb 5, 9:38 am, Raffael Cavallaro
<raffaelcavall...(a)pas.espam.s.il.vous.plait.mac.com> wrote:

> On 2010-02-05 07:29:23 -0500, Helmut Eller said:

> > Possibly, but I think that CL's current speed advantage will melt away
> > when Python switches to JIT compilers.

> Speed advantages are typically implementation issues, not issues with
> the language design per se.

True. OTOH, when it comes time to pick a language to use for a
project, the quality of the available implementations is a big deal.
It's not the only big deal---for instance, availability of libraries
is also a big deal, and one where Python is very strong.

> The real advantage of common lisp over python is that when you want a
> piece of novel syntax or a new control structure, in python you have to
> wait and hope that guido deigns to include it in some future version of
> python.

Absolutely. I commented elsewhere that the list comprehensions in
Python give it an advantage, but as nice as they are, they're a simple
macro away in Common Lisp. And I mean "simple", since I remember
writing a macro to do list comprehensions as an online exercise back
when I was teaching myself the language.

Cheers,
Pillsy
From: Nicolas Neuss on 5 Feb 2010 13:09
Helmut Eller <eller.helmut(a)gmail.com> writes:

>> E.g., your DFSEARCH function would then look like
>>
>> (defun dfsearch (board)
>> (and board
>> (aif (most-constrained-square board)
>> (some (lambda (d) (dfsearch (assign (copy-seq board) it d)))
>> (svref board it))
>> board)))
>
> Well, that's 6 lines; exactly as many as my version.

:-) I admit that in this case I have saved only some tokens and
characters.

>> After such changes, I think that the CL code would be about as short
>> (and as nice, although that is subjective, of course) as the Python code
>> and would run (even without any optimization effort!) much faster. And
>> that is the prime advantage of CL in my eyes.
>
> Possibly, but I think that CL's current speed advantage will melt away
> when Python switches to JIT compilers.

Is this somehow due in near future? And I'm also not sure that it
really will be able to compete with CL even then. A large speed jump
with CL comes when inserting type declarations locally, and IIUC Python
would have to invent a means for that first.

Nicolas
From: w_a_x_man on 5 Feb 2010 13:11
On Jan 30, 2:29 pm, John Thingstad <jpth...(a)online.no> wrote:
> The Sat, 30 Jan 2010 10:42:33 -0800, w_a_x_man wrote:
>
>
>
>
>
> > I don't know of anyone who works 6x6 Sudoku puzzles. How long does your
> > program take to solve this 9x9 one?
>
> > +-------+-------+-------+
> > | _ _ 6 | 9 _ _ | _ 7 _ |
> > | _ _ _ | _ 1 _ | _ _ 2 |
> > | 8 _ _ | _ _ _ | _ _ _ |
> > +-------+-------+-------+
> > | _ 2 _ | _ _ _ | _ _ 4 |
> > | _ _ _ | _ _ _ | _ _ 1 |
> > | _ _ 5 | _ _ 6 | _ _ _ |
> > +-------+-------+-------+
> > | _ _ _ | _ _ _ | _ 6 _ |
> > | _ _ _ | _ _ 2 | _ 5 _ |
> > | _ 1 _ | _ 4 3 | _ _ _ |
> > +-------+-------+-------+
>
> Not so well, yet. For one the valu 6 is harcoded, that needs to be
> generalized. I foused on getting the constraints right. If there are
> still several options left it would go into a infinate loop. So I would
> need to add a backtracking search. Still that's not that difficult. Mabe
> monday..
>
> --
> John Thingstad

For what it's worth, I posted a 9x9 solver in the Scheme newsgroup.
From: Helmut Eller on 5 Feb 2010 14:04
* Pillsy [2010-02-05 16:28+0100] writes:

> OTOH, I'm not sure why you think the Python code is shorter, since
> it's 85 lines (without comments or whitespace) compared to 77 for your
> Lisp code.

Good then :-)

But it depends a bit on how you count doc strings and the "main" stuff.
The Python code also has some code to print solutions nicely, something
that I skipped entirely.

Helmut
From: Helmut Eller on 5 Feb 2010 14:24
* Nicolas Neuss [2010-02-05 19:09+0100] writes:

>> Possibly, but I think that CL's current speed advantage will melt away
>> when Python switches to JIT compilers.
>
> Is this somehow due in near future?

Google is sponsoring the Unladen Swallow project and employs Guido van
Rossum. I think they would have the resources to do it; at least for
x86.

> And I'm also not sure that it
> really will be able to compete with CL even then. A large speed jump
> with CL comes when inserting type declarations locally, and IIUC Python
> would have to invent a means for that first.

Type declarations might not be as important if the JIT compiler
infrastructure collects execution profiles like JVMs do. Not sure if
they are that ambitious, though.

Helmut
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: CL to generate native docs
Next: ATTENTION: RETAIL FANZ OUT HERE : )/ CHECK THIS OUT : )