On Thursday 01 July 2004 2:33 am, Ron Johnson wrote:
> On Wed, 2004-06-30 at 22:02 -0500, Alex McKenzie wrote:
> > Ron Johnson wrote:
> > > On Wed, 2004-06-30 at 16:43 -0500, Brad Bendily wrote:
> > >
> > >>>It took about 15 minutes on my Athlon(tm) XP 2200+. Shoulda
> > >>>timed it.
> > >
> > >
> > > $ time python -c 'print str(2**3000000)'
> > >
> > > real 14m15.753s
> > > user 13m1.612s
> > > sys 0m0.606s
> > >
> > >
> > >>I have a P4 1.4 Ghz machine. I was doing a few other things at the time
> > >>too...
> > >>
> > >>
> > >>Wed Jun 30 15:49:54 CDT 2004
> > >>903090
> > >>Wed Jun 30 16:23:23 CDT 2004
> > >>
> > >>
> > >>33 minutes!
> > >
> > >
> > This is with an Athlon 750, 768MB@PC133, using 85% cpu with the other
> > bit for F@H
> >
> > $ time python -c 'print str(2**3000000)'
> > 903090
> >
> > real 37m25.302s
> > user 32m4.510s
> > sys 0m0.000s
> >
> > Hmmm....should I spend the $60 to upgrade?
>
> Oddly, when I did a "python -c 'print str(2**3000001)'", it took:
> real 12m28.495s
> user 12m17.516s
> sys 0m0.087s
>
> That's *faster* than 2**3000000. Very odd.
>
> Here's something else interesting (not good nor bad, but interest-
> ing) about python - delayed execution:
> $time python -c 'a = 2**3000001'
>
> real 0m0.139s
> user 0m0.109s
> sys 0m0.013s
>
> I figured it was a bug, so I tried it from the interactive python
> chevron prompt, and "a = 2**3000001" returned instantly, too.
> However, when I decided to "print a", that's what takes a long
> time.
Uh-cording to Kcalc, log10(2)*3000000=903089.9869919436.
I don't know how long it took me to figure that out, since I wasn't
timing the key presses. Obviously, with more precision it would
have come closer to an integer, but it is close enough already
that round() will suffice. That's how you find out how many digits
it has without actually having to compute the number itself. Ain't
math wonderful?
Andy Johnson
___________________
Nolug mailing list
nolug@nolug.org
Received on 07/02/04
This archive was generated by hypermail 2.2.0 : 12/19/08 EST