On Feb 2, 1:01 am, casevh wrote:
> On Feb 1, 10:02 pm, Mensanator wrote:
>
>
>
>
>
> > On Feb 1, 8:20 pm, casevh wrote:
>
> > > On Feb 1, 1:04 pm, Mensanator wrote:
>
> > > > On Feb 1, 2:27 am, casevh wrote:
>
> > > > > On Jan 31, 9:36 pm, "Tim Roberts" wrote:
>
> > > > > > Actually, all I'm
On Feb 1, 10:02 pm, Mensanator wrote:
> On Feb 1, 8:20 pm, casevh wrote:
>
>
>
> > On Feb 1, 1:04 pm, Mensanator wrote:
>
> > > On Feb 1, 2:27 am, casevh wrote:
>
> > > > On Jan 31, 9:36 pm, "Tim Roberts" wrote:
>
> > > > > Actually, all I'm interested in is whether the 100 digit numbers have
On Feb 1, 8:20�pm, casevh wrote:
> On Feb 1, 1:04�pm, Mensanator wrote:
>
>
>
> > On Feb 1, 2:27�am, casevh wrote:
>
> > > On Jan 31, 9:36�pm, "Tim Roberts" wrote:
>
> > > > Actually, all I'm interested in is whether the 100 digit numbers have
> > > > an exact integral root, or not. �At the mo
On Feb 1, 1:04 pm, Mensanator wrote:
> On Feb 1, 2:27 am, casevh wrote:
>
> > On Jan 31, 9:36 pm, "Tim Roberts" wrote:
>
> > > Actually, all I'm interested in is whether the 100 digit numbers have an
> > > exact integral root, or not. At the moment, because of accuracy
> > > concerns, I'm doi
On Feb 1, 2:27 am, casevh wrote:
> On Jan 31, 9:36 pm, "Tim Roberts" wrote:
>
> > Actually, all I'm interested in is whether the 100 digit numbers have an
> > exact integral root, or not. At the moment, because of accuracy concerns,
> > I'm doing something like
>
> > for ro
On Sun, 1 Feb 2009 15:36:43 +1000, Tim Roberts wrote:
>
> Actually, all I'm interested in is whether the 100 digit
> numbers have an exact integral root, or not. At the
> moment, because of accuracy concerns, I'm doing something
> like
>
> for root in powersp:
>
On Jan 31, 9:36 pm, "Tim Roberts" wrote:
> Actually, all I'm interested in is whether the 100 digit numbers have an
> exact integral root, or not. At the moment, because of accuracy concerns,
> I'm doing something like
>
> for root in powersp:
> n
"Tim Roberts" writes:
> for root in powersp:
> nroot = round(bignum**(1.0/root))
> if bignum==long(nroot)**root:
> .
> which is probably very inefficient
Paul,
Yes, very good, on all counts. Many thanks.
Tim
From: Paul Rubin [mailto:"http://phr.cx"@NOSPAM.invalid]
Sent: Sun 01-Feb-09 3:53 PM
To: python-list@python.org
Subject: Re: nth root
"Tim Roberts" writes:
> Actually, a
"Tim Roberts" writes:
> Actually, all I'm interested in is whether the 100 digit numbers
> have an exact integral root, or not. At the moment, because of
> accuracy concerns, I'm doing something like
>
> for root in powersp:
> nroot = round(bignum
Actually, all I'm interested in is whether the 100 digit numbers have an exact
integral root, or not. At the moment, because of accuracy concerns, I'm doing
something like
for root in powersp:
nroot = round(bignum**(1.0/root))
"Tim Roberts" wrote:
>
>Thanks - you're probably right - just my intuition said to me that rather than
>calculating that the 13th root of
>4021503534212915433093809093996098953996019232
>is 3221.2904208350265
>there must be a quicker way of finding out its between 3221 and 3222
>
>
On 2009-01-30 22:00, Tim Roberts wrote:
Unfortunately, unless I'm doing something wrong, this appears to take 20 times
as long... :-)
What on earth are numpy and psyco? Do I need to watch the Lord of the Rings?
No, but Google would help.
--
Robert Kern
"I have come to believe that the whol
On Jan 31, 7:04 pm, ajaksu wrote:
> also a great way make some innocent bystander waste his eyesight
> trying to figure out the magic trick :D
Oh, come on! At least I put the two lines next to each other! :-)
Mark
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 31, 12:03 pm, Mark Dickinson wrote:
[...]
> t1 = timeit.Timer("x = n**power", "n =
> 4021503534212915433093809093996098953996019232; power = 1./13")
> t2 = timeit.Timer("x = n**power", "n =
> 4021503534212915433093809093996098953996019232.; power = 1./13")
And by using a float literal in
Mark Dickinson wrote:
Well, random numbers is one thing. But how about the following:
n = 12345**13
n
154662214940914131102165197707101295849230845947265625L
int(n ** (1./13)) # should be 12345; okay
12345
int((n-1) ** (1./13)) # should be 12344; oops!
12345
Good point! Oops indeed. :
On Jan 31, 4:48 pm, Dan Goodman wrote:
> I don't think accuracy is too big a problem here actually (at least for
> 13th roots). I just tested it with several hundred thousand random 100
> digit numbers and it never made a mistake.
Well, random numbers is one thing. But how about the following:
On Jan 31, 10:53 am, Mensanator wrote:
> On Jan 31, 8:05 am, Mark Dickinson wrote:
>
> > On Jan 31, 1:23 pm, Steve Holden wrote:
>
> > > Much more significant points, given the limited precision of the doubles
> > > Python will be using. Could gmpy do this better, I wonder?
>
> > Almost certainl
On Jan 31, 8:05 am, Mark Dickinson wrote:
> On Jan 31, 1:23 pm, Steve Holden wrote:
>
> > Much more significant points, given the limited precision of the doubles
> > Python will be using. Could gmpy do this better, I wonder?
>
> Almost certainly, if exact results are wanted! At least, GMP has
>
Mark Dickinson wrote:
I'd also be a bit worried about accuracy. Is it important to you
that the
integer part of the result is *exactly* right, or is it okay if
(n**13)**(1./13) sometimes comes out as slightly less than n, or if
(n**13-1)**(1./13) sometimes comes out as n?
I don't think accura
On Jan 31, 1:23 pm, Steve Holden wrote:
> Much more significant points, given the limited precision of the doubles
> Python will be using. Could gmpy do this better, I wonder?
Almost certainly, if exact results are wanted! At least, GMP has
an mpz_root function; I don't know offhand whether gmpy
On Jan 31, 1:23 pm, Steve Holden wrote:
> [Mark]
> > power operation. The integer -> float conversion is probably quite
> > significant, timewise.
>
> I bow to your superior intuition!
Here's another timing that shows the significance of the int -> float
conversion: (non-debug build of the trunk
Mark Dickinson wrote:
> On Jan 31, 5:43 am, "Tim Roberts" wrote:
>> Dan,
>>
>> Thanks - you're probably right - just my intuition said to me that rather
>> than calculating that the 13th root of
>> 4021503534212915433093809093996098953996019232
>> is 3221.2904208350265
>> there must be a qui
On Jan 31, 5:43 am, "Tim Roberts" wrote:
> Dan,
>
> Thanks - you're probably right - just my intuition said to me that rather
> than calculating that the 13th root of
> 4021503534212915433093809093996098953996019232
> is 3221.2904208350265
> there must be a quicker way of finding out its bet
Tim
From: Dan Goodman [mailto:dg.gm...@thesamovar.net]
Sent: Sat 31-Jan-09 3:11 PM
To: python-list@python.org
Subject: Re: nth root
Takes less than 1 sec here to do (10**100)**(1./13) a million times, and
only about half as long to do (1e100)**(1./13), or abo
Takes less than 1 sec here to do (10**100)**(1./13) a million times, and
only about half as long to do (1e100)**(1./13), or about 14 times as
long as to do .2**2. Doesn't look like one could hope for it to be that
much quicker as you need 9 sig figs of accuracy to get the integer part
of (10**1
Unfortunately, unless I'm doing something wrong, this appears to take 20 times
as long... :-)
What on earth are numpy and psyco? Do I need to watch the Lord of the Rings?
Tim
Tim wrote:
> In PythonWin I'm running a program to find the 13th root (say) of
> millions of hundred-digit numbers
Tim wrote:
In PythonWin I'm running a program to find the 13th root (say) of
millions of hundred-digit numbers. I'm using
n = 13
root = base**(1.0/n)
which correctly computes the root to a large number of decimal
places, but therefore takes a long time. All I need is the integer
comp
In PythonWin I'm running a program to find the 13th root (say) of millions
of hundred-digit numbers. I'm using
n = 13
root = base**(1.0/n)
which correctly computes the root to a large number of decimal places, but
therefore takes a long time. All I need is the integer component. Is there
29 matches
Mail list logo
