Fun with partition function - Page 2

paulunderwood · 2017-04-06, 17:30

Quote:

Originally Posted by Batalov

In theory, yes. Practically, no, -- you will not find 221444161 in A046063.

Not only A046063 is visibly not calculated that far - we do know that it was not taken anywhere near that far

Nor here

science_man_88 · 2017-04-06, 17:32

Quote:

Originally Posted by Batalov

In theory, yes. Practically, no, -- you will not find 221444161 in A046063.

Not only A046063 is visibly not calculated that far - we do know that it was not taken anywhere near that far

the b file listing has it to over 99 million so over a third of the way there.

Batalov · 2017-04-06, 22:13

Quote:

Originally Posted by science_man_88

the b file listing has it to over 99 million so over a third of the way there.

Indeed, sounds easy enough

- and you will have no trouble telling me what is the n such that A046063(n) = 221444161 ? Right?

Quote:

Originally Posted by paulunderwood

Nor here

No need to look there, really. Just see the OP message?
...But you don't know how long that calculation took (and only for that single value). But you can know: just find the next value n > 10000076282 so that p(n) is PRP. Or the previous n (i.e. slightly below 10^10). And the same question: what is n :: A046063(n) = 10000076282 ?

paulunderwood · 2017-04-07, 00:47

Quote:

Originally Posted by Batalov

No need to look there, really. Just see the OP message?
...But you don't know how long that calculation took (and only for that single value). But you can know: just find the next value n > 10000076282 so that p(n) is PRP. Or the previous n (i.e. slightly below 10^10). And the same question: what is n :: A046063(n) = 10000076282 ?

I guess it took a single core an hour to calculate numbpart(10000076282) with Pari. With a sieve, that is 76282 values to check, (but then you used Arb.) Am I close? -- without trying to gauge it for myself.

Edit: I am revising my guess to 62 hours, based on:

Code:

time echo "numbpart(10^10/2^8);" | gp -q

real	0m8.736s
user	0m8.468s
sys	0m0.016s

time echo "numbpart(10^10/2^7);" | gp -q

real	0m29.226s
user	0m28.488s
sys	0m0.016s

time echo "numbpart(10^10/2^6);" | gp -q

real	1m41.768s
user	1m41.884s
sys	0m0.020s

? 28.488/8.468
3.3641946150212564950401511572980632971
? 101.884/28.488
3.5763830384723392305532153889356922213
? (3.6)^6*102/3600
61.675499520000000000000000000000000000

Batalov · 2017-04-18, 16:15

Quote:

Originally Posted by paulunderwood

I am looking forward to your record-breaking 16,569 digit partitions prime's proof

Done

paulunderwood · 2017-04-20, 22:55

Quote:

Originally Posted by Batalov

Done

Congrats for a speedy proof

Batalov · 2017-04-21, 18:36

Quote:

Originally Posted by paulunderwood

I guess it took a single core an hour to calculate numbpart(10000076282) with Pari. With a sieve, that is 76282 values to check, (but then you used Arb.) Am I close? -- without trying to gauge it for myself.

Edit: I am revising my guess to 62 hours, based on:

It is much faster to calculate p(n) values in Arb, as well as immediately abandon those that are divisible by small primes. However, it is still much longer than you estimated.

To revise my own estimate I ran a small search for an even larger PRP p(n), n > 14180076200 (a randomly chosen starting point*). It took ~10 hrs x 80 threads, so it is not a very trivial computation. The new largest known PRP is p(14180123587),which has 132646 decimal digits.
_________________
*Note that the decimal size of p(n) is known to be ~ \(1.114 \sqrt n\)
(due to Hardy and Ramanujan, 1918)

paulunderwood · 2017-04-21, 19:10

Quote:

Originally Posted by Batalov

It is much faster to calculate p(n) values in Arb, as well as immediately abandon those that are divisible by small primes. However, it is still much longer than you estimated.

To revise my own estimate I ran a small search for an even larger PRP p(n), n > 14180076200 (a randomly chosen starting point*). It took ~10 hrs x 80 threads, so it is not a very trivial computation. The new largest known PRP is p(14180123587),which has 132646 decimal digits.
_________________
*Note that the decimal size of p(n) is known to be ~ \(1.114 \sqrt n\)
(due to Hardy and Ramanujan, 1918)

Thanks for relaying the constant. Congrats for the new PRP

Batalov · 2017-04-26, 19:58

A couple of larger PRPs was also found, the larger slightly above 200000 decimal digits.
numbpart(32235776596), 200002 digit size

paulunderwood · 2017-04-26, 20:06

Quote:

Originally Posted by Batalov

A couple of larger PRPs was also found, the larger slightly above 200000 decimal digits.
numbpart(32235776596), 200002 digit size

Congrats again

How long does it take ARB to generate such a number?

Batalov · 2017-04-26, 20:53

Only 0.85s to generate number.
~13 minutes to check with PFGW.

In this size range you would expect to need to check 460000 candidates (of which you can sieve away 95-98%, but you'd still need to run a few thousand PRP tests). So the estimate is ~10^3 cpu-hours to find one.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
A useful function.	JM Montolio A	Miscellaneous Math	28	2018-03-08 14:29
phi function	rula	Homework Help	3	2017-01-18 01:41
Have a look at the partition numbers	fivemack	Factoring	57	2007-12-28 10:37
Partition number congruences	fivemack	Math	0	2007-05-18 19:39
Linux/SUSE noob trouble - Resize partition	OmbooHankvald	Linux	19	2005-11-18 10:39

2017-04-26, 19:58	#20
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	A couple of larger PRPs was also found, the larger slightly above 200000 decimal digits. numbpart(32235776596), 200002 digit size

2017-04-26, 20:53	#22
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 Posts	Only 0.85s to generate number. ~13 minutes to check with PFGW. In this size range you would expect to need to check 460000 candidates (of which you can sieve away 95-98%, but you'd still need to run a few thousand PRP tests). So the estimate is ~10^3 cpu-hours to find one.