On Oct 27, 8:12?am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sat, 27 Oct 2007 10:24:41 +0200, Hendrik van Rooyen wrote:
> > So 0.002625**200000 is a number so small that its about as close as you
> > can practically get to bugger-all, as it is less than 10 ** -400000, and
> > more than 10**-600000
>
> If you read the rest of the thread, you'll see I give a much more
> accurate estimate. It's approaching 10**-520000.
>
> > Now I have heard rumours that there are approximately 10**80 elementary
> > particles in the universe, so this is much less than one of them, even
> > if my rumour is grossly wrong.
>
> > A light year is of the order of 9.46*10**18 millimetres, and no human
> > has ever been that far away from home. Call it 10**19 for convenience.
> > So your number slices the last millimetre in a light year into more than
> > 10**399981 parts.
>
> Numbers like 10**520000 (the reciprocal of the product found) is a
> perfectly reasonable number if you're dealing with (say) permutations.
> Admittedly, even something of the complexity of Go only has about 10**150
> possible moves, but Go is simplicity itself compared to (say) Borges'
> Library of Babel or the set of all possible genomes.
And numbers of that size needn't be intractable.
The run time to generate a Collatz sequence is
logarithmic to the starting number. A number with
53328 digits only takes about 2.5 million iterations.
Of course, you can't test ALL the numbers of that
size, but often we're researching only certain types,
such as the ith kth Generation Type [1,2] Mersenne
Hailstone:
Closed form: Type12MH(k,i)
Find ith, kth Generation Type [1,2] Mersenne Hailstone
using the closed form equation
2**(6*((i-1)*9**(k-1)+(9**(k-1)-1)/2+1)-1)-1
2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7
2**14348909-1 generation: 8
2**129140165-1 generation: 9
2**1162261469-1 generation:10
1.141 seconds
Generation 10 has over a billion bits or >300
million digits. I had to stop there because an
exponent of 32 bits gives an "outrageous exponent"
error.
The closed form formula only works for a very
specific type of number. The research goal was
to come with a generic algorithm that works with
any Type and see if the algorithm obtains the
same results:
Verify Type12MH Hailstones:
Find ith, kth Generation Type (xyz) Hailstone
using the non-recursive equation
(gmpy.divm(y**(k-1)-prev_gen[2],y-x,y**(k-1))/
y**(k-2))*xyz[1]**(k-1)+prev_gen[3]
where i=((hailstone-geni(k,1,xyz))/(xyz[1]**k))+1
2**5-1 generation: 1
2**29-1 generation: 2
2**245-1 generation: 3
2**2189-1 generation: 4
2**19685-1 generation: 5
2**177149-1 generation: 6
2**1594325-1 generation: 7
2**14348909-1 generation: 8
2**129140165-1 generation: 9
2**1162261469-1 generation:10
4.015 seconds
There are legitimate uses for such large numbers
and Python's ability to handle this was what got
me interested in using Python in the first place.
>
> It's not even what mathematicians call a "large number" -- it can be
> written using ordinary notation of powers. For large numbers that can't
> be written using ordinary notation, see here:
>
> http://en.wikipedia.org/wiki/Large_numberhttp://www.scottaaronson.com/writings/bignumbers.html
>
> For instance, Ackermann's Sequence starts off quite humbly:
>
> 2, 4, 27 ...
>
> but the fourth item is 4**4**4**4 (which has 10,154 digits) and the fifth
> can't even be written out in ordinary mathematical notation.
>
> Calculating numbers like 10**520000 or its reciprocal is also a very good
> exercise in programming. Anyone can write a program to multiply two
> floating point numbers together and get a moderately accurate answer:
>
> product = X*Y # yawn
>
> But multiplying 200,000 floating point numbers together and getting an
> accurate answer somewhere near 10**-520000 requires the programmer to
> actually think about what they're doing. You can't just say:
>
> A,T,C,G = (0.35, 0.30, 0.25, 0.10)
> product = map(operator.mul, [A*T*C*G]*200000)
>
> and expect to get anywhere.
>
> Despite my fear that this is a stupid attempt by the Original Poster's
> professor to quantify the old saw about evolution being impossible
> ("...blah blah blah hurricane in a junk yard blah blah Concorde blah blah
> blah..."), I really like this homework question.
>
> --
> Steven.
--
http://mail.python.org/mailman/listinfo/python-list
