On Thu, May 7, 2015 at 7:14 PM, Alain Ketterlin
wrote:
> Dave Angel writes:
>
>> On 05/06/2015 11:36 AM, Alain Ketterlin wrote:
>>> Yes, plus the time for memory allocation. Since the code uses "r *=
>>> ...", space is reallocated when the result doesn't fit. The new size is
>>> probably proporti
Dave Angel writes:
> On 05/06/2015 11:36 AM, Alain Ketterlin wrote:
>> Yes, plus the time for memory allocation. Since the code uses "r *=
>> ...", space is reallocated when the result doesn't fit. The new size is
>> probably proportional to the current (insufficient) size. This means
>> that ove
On Wed, 06 May 2015 09:12:05 -0400, Dave Angel wrote:
> Remember the days when you knew how many cycles each assembly
> instruction took, and could simply add them up to compare algorithms?
I do! I do! :-)
And then the MC68020 came out, and instruction execution overlapped in
weird (but predic
On 06/05/2015 17:17, Ian Kelly wrote:
On Wed, May 6, 2015 at 1:08 AM, Steven D'Aprano
Besides, "typical load" is a myth -- there is no such thing. A high-end
Windows web server getting ten thousand hits a minute, a virtual machine
starved for RAM, a Mac laptop, a Linux server idling away with a
On 05/06/2015 11:36 AM, Alain Ketterlin wrote:
Yes, plus the time for memory allocation. Since the code uses "r *=
...", space is reallocated when the result doesn't fit. The new size is
probably proportional to the current (insufficient) size. This means
that overall, you'll need fewer reallocat
Ian Kelly writes:
> That was my initial thought as well, but the problem is that this
> actually predicts the *opposite* of what is being reported: upward
> should be less expensive, not more.
Wait, what? Hmm, you're right. Needed coffee, will think about it more
later.
--
https://mail.python.
On Wed, May 6, 2015 at 1:08 AM, Steven D'Aprano
wrote:
> On Wednesday 06 May 2015 15:58, Ian Kelly wrote:
>
>> On Tue, May 5, 2015 at 7:27 PM, Steven D'Aprano
>> wrote:
>>> Only the minimum is statistically useful.
>>
>> I disagree. The minimum tells you how fast the code *can* run, under
>> opti
On Wed, May 6, 2015 at 9:12 AM, Paul Rubin wrote:
> Steven D'Aprano writes:
>> Multiplying upwards seems to be more expensive than multiplying
>> downwards... I can only guess that it has something to do with the way
>> multiplication is implemented, or perhaps the memory management
>> involved,
Paul Rubin writes:
> Steven D'Aprano writes:
>> Multiplying upwards seems to be more expensive than multiplying
>> downwards... I can only guess that it has something to do with the way
>> multiplication is implemented, or perhaps the memory management
>> involved, or something. Who the hell kno
Steven D'Aprano writes:
> Multiplying upwards seems to be more expensive than multiplying
> downwards... I can only guess that it has something to do with the way
> multiplication is implemented, or perhaps the memory management
> involved, or something. Who the hell knows?
It seems pretty natura
On 05/06/2015 09:55 AM, Chris Angelico wrote:
On Wed, May 6, 2015 at 11:12 PM, Dave Angel wrote:
I had guessed that the order of multiplication would make a big difference,
once the product started getting bigger than the machine word size.
Reason I thought that is that if you multiply startin
On Wed, May 6, 2015 at 11:12 PM, Dave Angel wrote:
> I had guessed that the order of multiplication would make a big difference,
> once the product started getting bigger than the machine word size.
>
> Reason I thought that is that if you multiply starting at the top value (and
> end with multipl
On 05/06/2015 02:26 AM, Steven D'Aprano wrote:
On Wednesday 06 May 2015 14:05, Steven D'Aprano wrote:
My interpretation of this is that the difference has something to do with
the cost of multiplications. Multiplying upwards seems to be more expensive
than multiplying downwards, a result I nev
On Wednesday 06 May 2015 15:58, Ian Kelly wrote:
> On Tue, May 5, 2015 at 7:27 PM, Steven D'Aprano
> wrote:
>> Only the minimum is statistically useful.
>
> I disagree. The minimum tells you how fast the code *can* run, under
> optimal circumstances. The mean tells you how fast it *realistically
On Wednesday 06 May 2015 14:05, Steven D'Aprano wrote:
[...]
Here are those anomalous timing results again:
> code = "fact(5)"
> t1 = Timer(code, setup="from __main__ import factorial_while as fact")
> t2 = Timer(code, setup="from __main__ import factorial_reduce as fact")
> t3 = Timer(code,
On Tue, May 5, 2015 at 7:27 PM, Steven D'Aprano
wrote:
> Only the minimum is statistically useful.
I disagree. The minimum tells you how fast the code *can* run, under
optimal circumstances. The mean tells you how fast it *realistically*
runs, under typical load. Both can be useful to measure.
--
On Sun, 3 May 2015 12:20 am, Cecil Westerhof wrote:
[...]
> But to my surprise tail recursion could even be more efficient. I
> wrote two different versions of factorial with self implemented tail
> recursion. For bigger values both are more efficient. And I expect
> that if the tail recursion is
On Wed, May 6, 2015 at 12:57 PM, Steven D'Aprano
wrote:
> On Wed, 6 May 2015 05:42 am, Cecil Westerhof wrote:
>
>> I would say that a variable that is filled by a range is different as
>> a normal variable. Do not ask me why. ;-)
>
>
> I would say that you are wrong. If I have understood you corre
On Wed, 6 May 2015 05:42 am, Cecil Westerhof wrote:
> I would say that a variable that is filled by a range is different as
> a normal variable. Do not ask me why. ;-)
I would say that you are wrong. If I have understood you correctly, that
cannot possibly be the case in Python, all Python varia
On Wed, 6 May 2015 02:18 am, Cecil Westerhof wrote:
> Well, I did not write many tail recursive functions. But what surprised
> me was that for large values the ‘tail recursive’ version was more
> efficient as the iterative version. And that was with myself
> implementing the tail recursion. I exp
On Wed, 6 May 2015 07:23 am, Ian Kelly wrote:
> On Tue, May 5, 2015 at 3:00 PM, Dave Angel wrote:
>> def loop(func, funcname, arg):
>> start = time.time()
>> for i in range(repeats):
>> func(arg, True)
>> print("{0}({1}) took {2:7.4}".format(funcname, arg,
>> time.time()-s
On 5/5/2015 5:12 PM, Cecil Westerhof wrote:
Op Tuesday 5 May 2015 22:46 CEST schreef Terry Reedy:
Well, I did not write many tail recursive functions. But what
surprised me was that for large values the ‘tail recursive’ version
was more efficient as the iterative version.
In your first thread
On 05/05/2015 05:39 PM, Ian Kelly wrote:
On Tue, May 5, 2015 at 3:23 PM, Ian Kelly wrote:
On Tue, May 5, 2015 at 3:00 PM, Dave Angel wrote:
def loop(func, funcname, arg):
start = time.time()
for i in range(repeats):
func(arg, True)
print("{0}({1}) took {2:7.4}".format(
On Tue, May 5, 2015 at 3:23 PM, Ian Kelly wrote:
> On Tue, May 5, 2015 at 3:00 PM, Dave Angel wrote:
>> def loop(func, funcname, arg):
>> start = time.time()
>> for i in range(repeats):
>> func(arg, True)
>> print("{0}({1}) took {2:7.4}".format(funcname, arg, time.time()-start
Op Tuesday 5 May 2015 22:46 CEST schreef Terry Reedy:
>> Well, I did not write many tail recursive functions. But what
>> surprised me was that for large values the ‘tail recursive’ version
>> was more efficient as the iterative version.
>
> In your first thread, what you mislabelled 'tail recursi
On Tue, May 5, 2015 at 3:00 PM, Dave Angel wrote:
> def loop(func, funcname, arg):
> start = time.time()
> for i in range(repeats):
> func(arg, True)
> print("{0}({1}) took {2:7.4}".format(funcname, arg, time.time()-start))
>
> start = time.time()
> for i in range(repea
On 05/05/2015 04:30 PM, Ian Kelly wrote:
On Tue, May 5, 2015 at 12:45 PM, Dave Angel wrote:
When the "simple" is True, the function takes noticeably and consistently
longer. For example, it might take 116 instead of 109 seconds. For the
same counts, your code took 111.
I can't replicate thi
On 5/5/2015 12:18 PM, Cecil Westerhof wrote:
Op Tuesday 5 May 2015 17:47 CEST schreef Paul Moore:
On Sunday, 3 May 2015 16:23:59 UTC+1, Cecil Westerhof wrote:
By the way: I think that even if the recursion does not go further
as 500, it is still a good idea to use tail recursion. Why use
stac
On Tue, May 5, 2015 at 12:45 PM, Dave Angel wrote:
> When the "simple" is True, the function takes noticeably and consistently
> longer. For example, it might take 116 instead of 109 seconds. For the
> same counts, your code took 111.
I can't replicate this. What version of Python is it, and wh
Op Tuesday 5 May 2015 20:45 CEST schreef Dave Angel:
> On 05/05/2015 12:18 PM, Cecil Westerhof wrote:
>
>>
>> Well, I did not write many tail recursive functions. But what
>> surprised me was that for large values the ‘tail recursive’ version
>> was more efficient as the iterative version. And tha
On 05/05/2015 12:18 PM, Cecil Westerhof wrote:
Well, I did not write many tail recursive functions. But what surprised
me was that for large values the ‘tail recursive’ version was more
efficient as the iterative version. And that was with myself
implementing the tail recursion. I expect the co
Op Tuesday 5 May 2015 17:47 CEST schreef Paul Moore:
> On Sunday, 3 May 2015 16:23:59 UTC+1, Cecil Westerhof wrote:
>>> By the way: I think that even if the recursion does not go further
>>> as 500, it is still a good idea to use tail recursion. Why use
>>> stack space when it is not necessary?
>
On Sunday, 3 May 2015 16:23:59 UTC+1, Cecil Westerhof wrote:
> > By the way: I think that even if the recursion does not go further
> > as 500, it is still a good idea to use tail recursion. Why use stack
> > space when it is not necessary?
>
> I pushed the example to GitHub:
> https://github
Op Saturday 2 May 2015 16:20 CEST schreef Cecil Westerhof:
> I am throwing the cat among the pigeons. ;-)
>
> In another thread I mentioned that I liked to have tail recursion in
> Python. To be clear not automatic, but asked for.
>
> Looking at the replies I did hit a nerve. But I still want to
>
I am throwing the cat among the pigeons. ;-)
In another thread I mentioned that I liked to have tail recursion in
Python. To be clear not automatic, but asked for.
Looking at the replies I did hit a nerve. But I still want to
continue.
Some things are better expressed recursively for the people
35 matches
Mail list logo
