On 02/20/2013 04:49 PM, Tim Daneliuk wrote:
On 02/20/2013 12:38 PM, Ian Kelly wrote:
On Wed, Feb 20, 2013 at 7:21 AM, Tim Daneliuk wrote:
Thanks. I was specifically curious about your use of dynamic programming.
What about this algorithm makes it particularly an example of this? Is
it your u
On 02/20/2013 12:38 PM, Ian Kelly wrote:
On Wed, Feb 20, 2013 at 7:21 AM, Tim Daneliuk wrote:
Thanks. I was specifically curious about your use of dynamic programming.
What about this algorithm makes it particularly an example of this? Is
it your use of memoization or something other than thi
On Wed, Feb 20, 2013 at 7:21 AM, Tim Daneliuk wrote:
> Thanks. I was specifically curious about your use of dynamic programming.
> What about this algorithm makes it particularly an example of this? Is
> it your use of memoization or something other than this?
In retrospect, I was using the ter
On 2013-02-19, John Immarino wrote:
> Thanks,Chris. I'm a newbie to Python and didn't realize that
> it's not as good at number crunching as some of the others. It
> does seem to do better than Basic with numbers in lists as
> opposed to arrays in Basic.
Python is good enough at number crunching
On 02/19/2013 12:31 PM, Ian Kelly wrote:
On Tue, Feb 19, 2013 at 7:46 AM, Tim Daneliuk wrote:
Are you sure you wouldn't like to share with the class? I'd be interested
in seeing your approach...
Very well:
def collatz(n, memo):
if n not in memo:
if n % 2 == 0:
nex
Chris Angelico wrote:
On Wed, Feb 20, 2013 at 7:28 AM, Serhiy Storchaka wrote:
10-15% faster:
... num = max(range(2, M + 1), key=g) ...
Yes, but 20-30% less clear and readable. Though I do like the idea of
playing this code in the key of G Major.
On the SmartStupid, presumably.
http://wor
On Tuesday, February 19, 2013 3:28:25 PM UTC-5, Serhiy Storchaka wrote:
> 10-15% faster:
>
>
> def f(M):
> def g(n, cache = {1: 0}):
> if n in cache:
> return cache[n]
> if n % 2:
> m = 3 * n + 1
> else:
> m = n // 2
>
On Tue, Feb 19, 2013 at 5:23 PM, Alexander Blinne wrote:
> If changed into
>
> signed int n;
>
> there is a veeery long, perhaps infinite loop.
Yes, infinite. Here's the first such sequence encountered with a
signed 32-bit int.
[113383, 340150, 170075, 510226, 255113, 765340, 382670, 191335,
57
Am 19.02.2013 12:42, schrieb Piet van Oostrum:
> Terry Reedy writes:
>> I find this surprising too. I am also surprised that it even works,
>> given that the highest intermediate value is about 57 billion and I do
>> not remember that Basic had infinite precision ints.
>
> That may explain why th
On Wed, Feb 20, 2013 at 7:28 AM, Serhiy Storchaka wrote:
> 10-15% faster:
> ... num = max(range(2, M + 1), key=g) ...
Yes, but 20-30% less clear and readable. Though I do like the idea of
playing this code in the key of G Major.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On 19.02.13 20:31, Ian Kelly wrote:
On Tue, Feb 19, 2013 at 7:46 AM, Tim Daneliuk wrote:
Are you sure you wouldn't like to share with the class? I'd be interested
in seeing your approach...
Very well:
def collatz(n, memo):
if n not in memo:
if n % 2 == 0:
next_n =
On Tue, Feb 19, 2013 at 7:46 AM, Tim Daneliuk wrote:
> Are you sure you wouldn't like to share with the class? I'd be interested
> in seeing your approach...
Very well:
def collatz(n, memo):
if n not in memo:
if n % 2 == 0:
next_n = n // 2
else:
next_
On 02/18/2013 03:54 PM, Ian Kelly wrote:
On Mon, Feb 18, 2013 at 12:13 PM, John Immarino wrote:
I coded a Python solution for Problem #14 on the Project Euler website. I was
very surprised to find that it took 107 sec. to run even though it's a pretty
simple program. I also coded an equivale
> max=0
> m=0
> while m<=100:
> m+=1
> count=0
> n=m
> while n!=1:
> count+=1
> if n%2==0:
> n=n//2
> else:
> n=3*n+1
> if count>max:
> max=count
> num=m
> print(num,max)
>
I have tried to run your program
Terry Reedy writes:
> On 2/18/2013 2:13 PM, John Immarino wrote:
>> I coded a Python solution for Problem #14 on the Project Euler
>> website. I was very surprised to find that it took 107 sec. to run
>> even though it's a pretty simple program. I also coded an equivalent
>> solution for the pro
On 18.02.13 21:13, John Immarino wrote:
max=0
m=0
while m<=100:
m+=1
count=0
n=m
while n!=1:
count+=1
if n%2==0:
n=n//2
else:
n=3*n+1
if count>max:
max=count
num=m
print(num,max)
Some minor tip
John Immarino writes:
> I coded a Python solution for Problem #14 on the Project Euler
> website. I was very surprised to find that it took 107 sec. to run
> even though it's a pretty simple program. I also coded an equivalent
> solution for the problem in the old MSDOS basic. (That's the 16 bit
On 2/18/2013 4:55 PM, Chris Angelico wrote:
Running under Python 2.6, both your version and mine take about 90
seconds to run. But under Python 3.3, where (among other things)
range() yields values lazily, my version is significantly faster than
yours. BUT! Both versions, under 3.3, are signific
Hi John,
Thanks for the problem. I've been writing Python for about 4 years now and am
beginning to feel like I'm writing much better Python code.
Python does fine on this problem if you play to its strengths. The following
uses dictionary lookups to store previously computed sequence lengths,
On Tue, Feb 19, 2013 at 12:39 PM, John Immarino wrote:
> On Monday, February 18, 2013 2:58:57 PM UTC-7, Chris Angelico wrote:
>> On Tue, Feb 19, 2013 at 8:56 AM, Chris Angelico wrote:
>>
>> > On Tue, Feb 19, 2013 at 8:55 AM, Chris Angelico wrote:
>>
>> >> How long did your BASIC version take, an
>
> > max=0
>
>
>
> "max" is a bad name -- it masks the built-in max() function
>
>
>
> > m=0
>
> > while m<=100:
>
> > m+=1
>
>
>
> Since "m" is only modified here and has a value of 1 for the first
>
> pass through, you can replace those three lines with
>
>
>
On Monday, February 18, 2013 2:58:57 PM UTC-7, Chris Angelico wrote:
> On Tue, Feb 19, 2013 at 8:56 AM, Chris Angelico wrote:
>
> > On Tue, Feb 19, 2013 at 8:55 AM, Chris Angelico wrote:
>
> >> How long did your BASIC version take, and how long did the Python
>
> >> version on the same hardwar
On 2/18/2013 2:13 PM, John Immarino wrote:
I coded a Python solution for Problem #14 on the Project Euler
website. I was very surprised to find that it took 107 sec. to run
even though it's a pretty simple program. I also coded an equivalent
solution for the problem in the old MSDOS basic. (That
Am 18.02.2013 20:13, schrieb John Immarino:
> I coded a Python solution for Problem #14 on the Project Euler website. I was
> very surprised to find that it took 107 sec. to run even though it's a pretty
> simple program. I also coded an equivalent solution for the problem in the
> old MSDOS ba
On Mon, Feb 18, 2013 at 3:01 PM, Chris Angelico wrote:
> On Tue, Feb 19, 2013 at 8:54 AM, Ian Kelly wrote:
>> Well, I don't see anything that looks especially slow in that code,
>> but the algorithm that you're using is not very efficient. I rewrote
>> it using dynamic programming (details left
On Tue, Feb 19, 2013 at 8:54 AM, Ian Kelly wrote:
> Well, I don't see anything that looks especially slow in that code,
> but the algorithm that you're using is not very efficient. I rewrote
> it using dynamic programming (details left as an exercise), which got
> the runtime down to about 4 seco
On Tue, Feb 19, 2013 at 8:55 AM, Chris Angelico wrote:
> How long did your BASIC version take, and how long did the Python
> version on the same hardware?
Oops, my bad, you already posted the figures :) And I forgot to ask:
Which Python version didyou use?
ChrisA
--
http://mail.python.org/mailm
On Tue, Feb 19, 2013 at 8:56 AM, Chris Angelico wrote:
> On Tue, Feb 19, 2013 at 8:55 AM, Chris Angelico wrote:
>> How long did your BASIC version take, and how long did the Python
>> version on the same hardware?
>
> Oops, my bad, you already posted the figures :) And I forgot to ask:
> Which Py
On Tue, Feb 19, 2013 at 6:13 AM, John Immarino wrote:
> I coded a Python solution for Problem #14 on the Project Euler website. I was
> very surprised to find that it took 107 sec. to run even though it's a pretty
> simple program. I also coded an equivalent solution for the problem in the
> o
On Mon, Feb 18, 2013 at 12:13 PM, John Immarino wrote:
> I coded a Python solution for Problem #14 on the Project Euler website. I was
> very surprised to find that it took 107 sec. to run even though it's a pretty
> simple program. I also coded an equivalent solution for the problem in the
>
I coded a Python solution for Problem #14 on the Project Euler website. I was
very surprised to find that it took 107 sec. to run even though it's a pretty
simple program. I also coded an equivalent solution for the problem in the old
MSDOS basic. (That's the 16 bit app of 1980s vintage.) It r
31 matches
Mail list logo
