On 02/05/2015 14:50, Joonas Liik wrote:
[top posting fixed]
On 2 May 2015 at 14:42, Marko Rauhamaa wrote:
Christian Gollwitzer :
That's why I still think it is a microoptimization, which helps only
in some specific cases.
It isn't done for performance. It's done to avoid a stack overflo
On Sat, May 2, 2015 at 9:53 AM, Joonas Liik wrote:
Top-posting is heavily frowned at on this list, so please don't do it.
> Balancing of trees is kind of irrelevant when "tree" means "search space"
> no?
I think it's relatively rare that DFS is truly the best algorithm for
such a search. For on
On Sat, May 2, 2015 at 9:55 AM, Chris Angelico wrote:
> On Sun, May 3, 2015 at 1:45 AM, Ian Kelly wrote:
>> On Sat, May 2, 2015 at 5:42 AM, Marko Rauhamaa wrote:
>>> Christian Gollwitzer :
>>>
That's why I still think it is a microoptimization, which helps only
in some specific cases.
Balancing of trees is kind of irrelevant when "tree" means "search space"
no?
And you definitely dont need to keep the entire tree in memory at the same
time.
By cropping unsuitable branches early (and not keeping the entire tree in
memory)
it is quite easy to have more than 1000 of call stack and
I agree, stack overflow is literally the main issue that ive run in to
(tree traversal)
I've yet to refactor recursion to iterative for speed, but i have done so
to avoid hitting the stack size limit.
Tree traversal and similar problems in particular lend themselves well to
recursion and are not q
On Sun, May 3, 2015 at 1:45 AM, Ian Kelly wrote:
> On Sat, May 2, 2015 at 5:42 AM, Marko Rauhamaa wrote:
>> Christian Gollwitzer :
>>
>>> That's why I still think it is a microoptimization, which helps only
>>> in some specific cases.
>>
>> It isn't done for performance. It's done to avoid a stac
On Sat, May 2, 2015 at 5:42 AM, Marko Rauhamaa wrote:
> Christian Gollwitzer :
>
>> That's why I still think it is a microoptimization, which helps only
>> in some specific cases.
>
> It isn't done for performance. It's done to avoid a stack overflow
> exception.
If your tree is balanced, then th
On Sat, May 2, 2015 at 4:35 AM, Dave Angel wrote:
> I can't see how that is worth doing. The recursive version is already a
> distortion of the definition of factorial that I learned. And to force it
> to be recursive and also contort it so it does the operations in the same
> order as the iterat
Christian Gollwitzer :
> That's why I still think it is a microoptimization, which helps only
> in some specific cases.
It isn't done for performance. It's done to avoid a stack overflow
exception.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Op Saturday 2 May 2015 12:35 CEST schreef Dave Angel:
> On 05/02/2015 05:33 AM, Cecil Westerhof wrote:
>
> Please check your email settings. Your messages that you type seem
> to be indented properly, but those that are quoting earlier messages
> (even your own) are not. See below. I suspect there
Am 02.05.15 um 13:21 schrieb Chris Angelico:
On Sat, May 2, 2015 at 9:07 PM, Christian Gollwitzer wrote:
I need to add, I grew up with imperative programming, and as such got
recursion as the solution to problems that are too complex for iteration,
i.e. tree traversal and such, and exactly thes
On Sat, May 2, 2015 at 9:07 PM, Christian Gollwitzer wrote:
> I need to add, I grew up with imperative programming, and as such got
> recursion as the solution to problems that are too complex for iteration,
> i.e. tree traversal and such, and exactly these are never tail-recursive.
Tree traversa
Op Saturday 2 May 2015 11:10 CEST schreef Marko Rauhamaa:
> Cecil Westerhof :
>> I find factorial a lot cleaner code as factorial_iterative, so here
>> tail recursion would be beneficial.
>
> I would just call math.factorial() and be done with it.
You missed the point. I did not need a factorial
Am 02.05.15 um 11:58 schrieb Marko Rauhamaa:
Chris Angelico :
Guido is against anything that disrupts tracebacks, and optimizing
tail recursion while maintaining traceback integrity is rather harder.
Tail recursion could be suppressed during debugging. Optimized code can
play all kinds of non
On Sat, May 2, 2015 at 8:22 PM, Dave Angel wrote:
> On 05/02/2015 05:58 AM, Marko Rauhamaa wrote:
>>
>> Chris Angelico :
>>
>>> Guido is against anything that disrupts tracebacks, and optimizing
>>> tail recursion while maintaining traceback integrity is rather harder.
>>
>>
>> Tail recursion coul
On 05/02/2015 05:33 AM, Cecil Westerhof wrote:
Please check your email settings. Your messages that you type seem to
be indented properly, but those that are quoting earlier messages (even
your own) are not. See below. I suspect there's some problem with how
your email program processes htm
On 05/02/2015 05:58 AM, Marko Rauhamaa wrote:
Chris Angelico :
Guido is against anything that disrupts tracebacks, and optimizing
tail recursion while maintaining traceback integrity is rather harder.
Tail recursion could be suppressed during debugging. Optimized code can
play all kinds of no
Op Saturday 2 May 2015 10:26 CEST schreef Cecil Westerhof:
> Op Friday 1 May 2015 09:03 CEST schreef Steven D'Aprano:
>
>> On Thu, 30 Apr 2015 09:30 pm, Cecil Westerhof wrote:
>>
>>> Tail recursion would nice to have also.
>>
>> People coming from functional languages like Lisp and Haskell often
>
Chris Angelico :
> Guido is against anything that disrupts tracebacks, and optimizing
> tail recursion while maintaining traceback integrity is rather harder.
Tail recursion could be suppressed during debugging. Optimized code can
play all kinds of non-obvious tricks with the execution frame.
>
On Sat, May 2, 2015 at 7:10 PM, Marko Rauhamaa wrote:
> Note: Scheme is my favorite language and I use tail recursion all the
> time. I also think eliminating tail recursion is such a low-hanging
> fruit that even CPython should just pick it. However, I wouldn't use the
> fibonacci sequence to jus
Cecil Westerhof :
> I find factorial a lot cleaner code as factorial_iterative, so here
> tail recursion would be beneficial.
I would just call math.factorial() and be done with it.
Note: Scheme is my favorite language and I use tail recursion all the
time. I also think eliminating tail recursion
Op Friday 1 May 2015 09:03 CEST schreef Steven D'Aprano:
> On Thu, 30 Apr 2015 09:30 pm, Cecil Westerhof wrote:
>
>> Tail recursion would nice to have also.
>
> People coming from functional languages like Lisp and Haskell often
> say that, but how many recursive algorithms naturally take a
> tail
Steven D'Aprano wrote:
People coming from functional languages like Lisp and Haskell often say
that, but how many recursive algorithms naturally take a tail-call form?
Not that many.
And the ones that do tend to be the ones that are
better expressed iteratively in Python. So Python
doesn't rea
Am 01.05.15 um 09:03 schrieb Steven D'Aprano:
On Thu, 30 Apr 2015 09:30 pm, Cecil Westerhof wrote:
Tail recursion would nice to have also.
People coming from functional languages like Lisp and Haskell often say
that, but how many recursive algorithms naturally take a tail-call form?
Not that
Op Friday 1 May 2015 09:03 CEST schreef Steven D'Aprano:
> On Thu, 30 Apr 2015 09:30 pm, Cecil Westerhof wrote:
>
>> Tail recursion would nice to have also.
>
> People coming from functional languages like Lisp and Haskell often
> say that, but how many recursive algorithms naturally take a
> tail
On Thu, 30 Apr 2015 09:30 pm, Cecil Westerhof wrote:
> Tail recursion would nice to have also.
People coming from functional languages like Lisp and Haskell often say
that, but how many recursive algorithms naturally take a tail-call form?
Not that many.
I suppose that it would be nice if Python
On Thu, 30 Apr 2015 08:16 pm, Marko Rauhamaa wrote:
> Still, Python has features that defy effective optimization. Most
> notably, Python's dot notation translates into a hash table lookup -- or
> worse.
Effective optimization may be difficult, but it isn't impossible. PyPy has a
very effective
Op Thursday 30 Apr 2015 19:59 CEST schreef Christian Gollwitzer:
> Am 30.04.15 um 18:11 schrieb Cecil Westerhof:
>> Op Thursday 30 Apr 2015 16:03 CEST schreef Michael Torrie:
>>
>>> On 04/30/2015 01:07 AM, Cecil Westerhof wrote:
When I do that the computer is freezed a few times. That is a
>>
Am 30.04.15 um 18:11 schrieb Cecil Westerhof:
Op Thursday 30 Apr 2015 16:03 CEST schreef Michael Torrie:
On 04/30/2015 01:07 AM, Cecil Westerhof wrote:
When I do that the computer is freezed a few times. That is a
little less nice. Does not happen with Clojure when it gets an out
of memory.
Op Thursday 30 Apr 2015 16:03 CEST schreef Michael Torrie:
> On 04/30/2015 01:07 AM, Cecil Westerhof wrote:
>> When I do that the computer is freezed a few times. That is a
>> little less nice. Does not happen with Clojure when it gets an out
>> of memory.
>
> A system freeze is probably due to th
On 04/30/2015 01:07 AM, Cecil Westerhof wrote:
> When I do that the computer is freezed a few times. That is a little
> less nice. Does not happen with Clojure when it gets an out of memory.
A system freeze is probably due to thrashing by your operating system as
a process (in this case Python) us
Op Thursday 30 Apr 2015 12:16 CEST schreef Marko Rauhamaa:
> Ben Finney :
>
>> The latter is not a property of Python; a programming language
>> doesn't have runtime performance. Rather, runtime performance is a
>> property of some specific *implementation* — that is, the runtime
>> Python machine
Op Thursday 30 Apr 2015 11:10 CEST schreef Ben Finney:
>> I like it that the code is concise and clear. But also that the
>> performance is not bad.
>
> The former is a property of Python, which is a programming language.
> I agree with your assessment :-)
>
> The latter is not a property of Pytho
On Thu, Apr 30, 2015 at 8:16 PM, Marko Rauhamaa wrote:
> Ben Finney :
>
>> The latter is not a property of Python; a programming language doesn't
>> have runtime performance. Rather, runtime performance is a property of
>> some specific *implementation* — that is, the runtime Python machine.
>>
>>
Ben Finney :
> The latter is not a property of Python; a programming language doesn't
> have runtime performance. Rather, runtime performance is a property of
> some specific *implementation* — that is, the runtime Python machine.
>
> There are numerous Python runtimes, and they have different
> p
Cecil Westerhof writes:
> I am coding with Python again.
Great to know!
> I like it that the code is concise and clear. But also that the
> performance is not bad.
The former is a property of Python, which is a programming language. I
agree with your assessment :-)
The latter is not a propert
I am coding with Python again. I like it that the code is concise and
clear. But also that the performance is not bad.
I wrote Lucky Numbers in Clojure and Python.
When calling with 1E7 Clojure takes 12 seconds and Python 8 seconds.
When calling it with 1E8 Clojure takes all 4/8 cores and gets an
37 matches
Mail list logo
