Primes in π

[davar55]

Originally Posted by J F

a(20) neares 450k digits, still nothing
a(196) finished with a 312306-digit PRP

Re: a(20) at 450K: what's the probability at this point that
it will reach or exceed 1M digits ? If so, how expensive will
it be to check that far ?

[J F]

Originally Posted by davar55

Re: a(20) at 450K: what's the probability at this point that
it will reach or exceed 1M digits ? If so, how expensive will
it be to check that far ?

Quick and dirty calculation, chance for (at least) one PRP from
450K to 500K 4-5%, 500K to 1M ballpark 25%.
That doesn't sound too bad, but the required core-hours ARE bad!
With PFGW a PRP-test at 450K digits takes ~2.5h on an older
non-AVX I5-750 core, 900K digits would be ~10h, a modern AVX-core
is a bit less than half that time.
Many thousand of them after TF (+TF time) - there you go.

[davar55]

Thanks. Will this computation be continuing indefinitely, or is there
some software limit, or a time budget? I think we'll need a(20) to
have a satisfactory entry in oeis, if that's deemed ok.

[davar55]

Originally Posted by ewmayer

This would also appear to follow if the digits are normal, which is generally believed but as yet unproven.
If normality holds, the digits will further be "as random as can be", but note the above 2 properties will be true of all normal reals, which are (provably) a dense subset of the reals. Interestingly, the normals likely include both irrationals and transcendentals - for example, sqrt(2), pi and e are all generally believed (but not proven) to be normal.
I find it interesting that is far easier to prove that almost all reals are normal than to prove that a selected one, even one as well-studied as sqrt(2), is.

For pi, e and sqrt(2), is there any evidence beyond empirical observation of the so-far known digits that addresses
their normality, i.e. other than statistics? Are there any positive results toward this? I too "generally believe" they
are normal, but looking at the first say trillion digits of sqrt(2) is still subject to the law of small numbers considering
the infinity of its non-repetitiveness.

[davar55]

I was very excited when I thought of the OP question. In attacking the
question by hand and with my calculator, I anticipated some very long
primes coming out of the digits of pi. Now I eagerly await a(20).

[davar55]

In preparation for a possible oeis entry, and since the PRPs here were not posted,
could someone post a list of the first 99 (01 thru 99) elements of this sequence?

Each line as:

xxx -> #

where xxx is the index (001 thru 099) and
# is either the prime, PRP### followed by abcde.....vwxyz (the end digits), or "no such prime".

(If you want to improve on this format, fine.)

[J F]

Originally Posted by davar55

...and since the PRPs here were not posted...

??
Some outdated limits for the unfinished numbers and finished
#196 aside, what's wrong with the list in post 74?


Completely off topic: can someone recommend a program or
efficient way to cut down an arbitrary integer to a shorter
representation? Let's say I have a 1M digit number and want
it down to a 30? 20? chars term of form a*b^c+d.
As short as possible with 'reasonable' (minutes? no idea
about the complexity) CPU time.
Thanks in advance.

[fivemack]

Obviously it will nearly always not be possible to get such a representation, but I'd be tempted to use the linear-forms stuff in Pari on log(N) and logs of enough small numbers to try to fit A,B,C, then figure out D by subtraction.

lp=[];forprime(p=2,200,lp=concat(lp,[log(p)]))
lindep(concat([log(861*136^997+142857)],lp))

312ms to recognise 85*53^2269-11 using primes up to 100 (with realprecision=500); 2152ms using primes up to 200; 5512ms for primes up to 300; you get a non-sparse vector if it didn't work.

[axn]

Originally Posted by J F

Completely off topic: can someone recommend a program or
efficient way to cut down an arbitrary integer to a shorter
representation? Let's say I have a 1M digit number and want
it down to a 30? 20? chars term of form a*b^c+d.
As short as possible with 'reasonable' (minutes? no idea
about the complexity) CPU time.
Thanks in advance.

Simple information-theoretic reasoning suggests what you want cannot be done (i.e, compressing an arbitrary integer). If it could be done, you've just found out the world's most efficient compression algorithm

[J F]

Shame - talk about obvious, I could have come up
with this myself...
I had some muddy thoughts similiar to Mr. Fivemack,
with X=a*b^c+d try to puzzle the logs together to
come close up to log(X) and the add/substract 'the rest'.
At this moment I just didn't think about that this is
trying to map a set 1:1 to a much smaller set.
*in the corner, with red ears*

Thanks for the replys

[davar55]

Originally Posted by J F

??
Some outdated limits for the unfinished numbers and finished
#196 aside, what's wrong with the list in post 74?
...
Thanks in advance.

Your welcome (OP).