mersenneforum.org Fun with partition function
 Register FAQ Search Today's Posts Mark Forums Read

2017-04-06, 17:30   #12
paulunderwood

Sep 2002
Database er0rr

2·3·23·31 Posts

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

2017-04-06, 17:32   #13
science_man_88

"Forget I exist"
Jul 2009
Dumbassville

20CF16 Posts

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.

2017-04-06, 22:13   #14
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

2·4,967 Posts

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 ?

2017-04-07, 00:47   #15
paulunderwood

Sep 2002
Database er0rr

2·3·23·31 Posts

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

Last fiddled with by paulunderwood on 2017-04-07 at 01:24

2017-04-18, 16:15   #16
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

993410 Posts

Quote:
 Originally Posted by paulunderwood I am looking forward to your record-breaking 16,569 digit partitions prime's proof
Done

2017-04-20, 22:55   #17
paulunderwood

Sep 2002
Database er0rr

2·3·23·31 Posts

Quote:
 Originally Posted by Batalov Done
Congrats for a speedy proof

2017-04-21, 18:36   #18
Batalov

"Serge"
Mar 2008
Phi(4,2^7658614+1)/2

2·4,967 Posts

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)

2017-04-21, 19:10   #19
paulunderwood

Sep 2002
Database er0rr

102668 Posts

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

 2017-04-26, 19:58 #20 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2·4,967 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:06   #21
paulunderwood

Sep 2002
Database er0rr

10B616 Posts

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?

Last fiddled with by paulunderwood on 2017-04-26 at 20:09

 2017-04-26, 20:53 #22 Batalov     "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2·4,967 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.

 Similar Threads Thread Thread Starter Forum Replies Last Post JM Montolio A Miscellaneous Math 28 2018-03-08 14:29 rula Homework Help 3 2017-01-18 01:41 fivemack Factoring 57 2007-12-28 10:37 fivemack Math 0 2007-05-18 19:39 OmbooHankvald Linux 19 2005-11-18 10:39

All times are UTC. The time now is 10:33.

Sun Sep 25 10:33:48 UTC 2022 up 38 days, 8:02, 0 users, load averages: 0.75, 0.85, 0.97