Python 2, 110 bytes
n=input()
x=p=7*n|1
while~-p:x=p/2*x/p+2*10**n;p-=2
l=m=0
for c in`x`:
l=l*(p==c)+1;p=c
if l>m:m=l;print p*l
El número máximo de dígitos para verificar se toma de stdin. 10,000 dígitos terminan en aproximadamente 2 segundos con PyPy 5.3.
Uso de muestra
$ echo 10000 | pypy pi-runs.py
3
33
111
9999
99999
999999
Algo útil
from sys import argv
from gmpy2 import mpz
def pibs(a, b):
if a == b:
if a == 0:
return (1, 1, 1123)
p = a*(a*(32*a-48)+22)-3
q = a*a*a*24893568
t = 21460*a+1123
return (p, -q, p*t)
m = (a+b) >> 1
p1, q1, t1 = pibs(a, m)
p2, q2, t2 = pibs(m+1, b)
return (p1*p2, q1*q2, q2*t1 + p1*t2)
if __name__ == '__main__':
from sys import argv
digits = int(argv[1])
pi_terms = mpz(digits*0.16975227728583067)
p, q, t = pibs(0, pi_terms)
z = mpz(10)**digits
pi = 3528*q*z/t
l=m=0
x=0
for c in str(pi):
l=l*(p==c)+1;p=c
if l>m:m=l;print x,p*l
x+=1
He cambiado de Chudnovsky a Ramanujan 39 por esto. Chudnovsky se quedó sin memoria en mi sistema poco después de 100 millones de dígitos, pero Ramanujan llegó a 400 millones, en solo unos 38 minutos. Creo que este es otro caso en el que la tasa de crecimiento de términos más lenta gana al final, al menos en un sistema con recursos limitados.
Uso de muestra
$ python pi-ramanujan39-runs.py 400000000
0 3
25 33
155 111
765 9999
766 99999
767 999999
710106 3333333
22931752 44444444
24658609 777777777
386980421 6666666666
Generadores ilimitados más rápidos
La implementación de referencia dada en la descripción del problema es interesante. Utiliza un generador ilimitado, tomado directamente del papel Algoritmos de espiga no limitada para los dígitos de Pi . Según el autor, las implementaciones proporcionadas son "deliberadamente oscuras", por lo que decidí hacer nuevas implementaciones de los tres algoritmos enumerados por el autor, sin ofuscación deliberada. También agregué un cuarto, basado en Ramanujan # 39 .
try:
from gmpy2 import mpz
except:
mpz = long
def g1_ref():
# Leibniz/Euler, reference
q, r, t = mpz(1), mpz(0), mpz(1)
i, j = 1, 3
while True:
n = (q+r)/t
if n*t > 4*q+r-t:
yield n
q, r = 10*q, 10*(r-n*t)
q, r, t = q*i, (2*q+r)*j, t*j
i += 1; j += 2
def g1_md():
# Leibniz/Euler, multi-digit
q, r, t = mpz(1), mpz(0), mpz(1)
i, j = 1, 3
z = mpz(10)**10
while True:
n = (q+r)/t
if n*t > 4*q+r-t:
for d in digits(n, i>34 and 10 or 1): yield d
q, r = z*q, z*(r-n*t)
u, v, x = 1, 0, 1
for k in range(33):
u, v, x = u*i, (2*u+v)*j, x*j
i += 1; j += 2
q, r, t = q*u, q*v+r*x, t*x
def g2_md():
# Lambert, multi-digit
q, r, s, t = mpz(0), mpz(4), mpz(1), mpz(0)
i, j, k = 1, 1, 1
z = mpz(10)**49
while True:
n = (q+r)/(s+t)
if n == q/s:
for d in digits(n, i>65 and 49 or 1): yield d
q, r = z*(q-n*s), z*(r-n*t)
u, v, w, x = 1, 0, 0, 1
for l in range(64):
u, v, w, x = u*j+v, u*k, w*j+x, w*k
i += 1; j += 2; k += j
q, r, s, t = q*u+r*w, q*v+r*x, s*u+t*w, s*v+t*x
def g3_ref():
# Gosper, reference
q, r, t = mpz(1), mpz(180), mpz(60)
i = 2
while True:
u, y = i*(i*27+27)+6, (q+r)/t
yield y
q, r, t, i = 10*q*i*(2*i-1), 10*u*(q*(5*i-2)+r-y*t), t*u, i+1
def g3_md():
# Gosper, multi-digit
q, r, t = mpz(1), mpz(0), mpz(1)
i, j = 1, 60
z = mpz(10)**50
while True:
n = (q+r)/t
if n*t > 6*i*q+r-t:
for d in digits(n, i>38 and 50 or 1): yield d
q, r = z*q, z*(r-n*t)
u, v, x = 1, 0, 1
for k in range(37):
u, v, x = u*i*(2*i-1), j*(u*(5*i-2)+v), x*j
i += 1; j += 54*i
q, r, t = q*u, q*v+r*x, t*x
def g4_md():
# Ramanujan 39, multi-digit
q, r, s ,t = mpz(0), mpz(3528), mpz(1), mpz(0)
i = 1
z = mpz(10)**3511
while True:
n = (q+r)/(s+t)
if n == (22583*i*q+r)/(22583*i*s+t):
for d in digits(n, i>597 and 3511 or 1): yield d
q, r = z*(q-n*s), z*(r-n*t)
u, v, x = mpz(1), mpz(0), mpz(1)
for k in range(596):
c, d, f = i*(i*(i*32-48)+22)-3, 21460*i-20337, -i*i*i*24893568
u, v, x = u*c, (u*d+v)*f, x*f
i += 1
q, r, s, t = q*u, q*v+r*x, s*u, s*v+t*x
def digits(x, n):
o = []
for k in range(n):
x, r = divmod(x, 10)
o.append(r)
return reversed(o)
Notas
Arriba hay 6 implementaciones: las dos implementaciones de referencia proporcionadas por el autor (denotado _ref), y cuatro que calculan términos en lotes, generando múltiples dígitos a la vez ( _md). Todas las implementaciones han sido confirmadas a 100,000 dígitos. Al elegir tamaños de lote, elegí valores que lentamente pierden precisión con el tiempo. Por ejemplo, g1_mdgenera 10 dígitos por lote, con 33 iteraciones. Sin embargo, esto solo producirá ~ 9.93 dígitos correctos. Cuando se agote la precisión, la condición de verificación fallará, lo que desencadenará la ejecución de un lote adicional. Esto parece ser más eficaz que la precisión lenta y adicionalmente innecesaria con el tiempo.
- g1 (Leibniz / Euler)
Se jmantiene una variable adicional que representa 2*i+1. El autor hace lo mismo en la implementación de referencia. Calcular por nseparado es mucho más simple (y menos oscuro), porque utiliza los valores actuales de q, ry t, en lugar de los siguientes.
- g2 (Lambert)
El cheque n == q/ses ciertamente bastante laxo. Eso debería leer n == (q*(k+2*j+4)+r)/(s*(k+2*j+4)+t), dónde jestá 2*i-1y kestá i*i. En iteraciones más altas, los términos ry se tvuelven cada vez menos significativos. Como es, es bueno para los primeros 100,000 dígitos, por lo que probablemente sea bueno para todos. El autor no proporciona implementación de referencia.
- g3 (Gosper)
El autor conjetura que no es necesario verificar que nno cambiará en las iteraciones posteriores, y que solo sirve para ralentizar el algoritmo. Aunque probablemente sea cierto, el generador está reteniendo ~ 13% más dígitos correctos de los que ha generado actualmente, lo que parece un poco inútil. He agregado el cheque nuevamente y espero hasta que 50 dígitos sean correctos, generándolos todos a la vez, con una ganancia notable en el rendimiento.
- g4 (Ramanujan 39)
Calculado como
Desafortunadamente, sno se pone a cero, debido a la composición inicial (3528 ÷), pero sigue siendo significativamente más rápido que g3. La convergencia es de ~ 5.89 dígitos por término, se generan 3511 dígitos a la vez. Si eso es demasiado, generar 271 dígitos por 46 iteraciones también es una opción decente.
Tiempos
Tomado en mi sistema, solo para fines de comparación. Los tiempos se enumeran en segundos. Si un tiempo tardó más de 10 minutos, no ejecuté más pruebas.
| g1_ref | g1_md | g2_md | g3_ref | g3_md | g4_md
------------+---------+---------+---------+---------+---------+--------
10,000 | 1.645 | 0.229 | 0.093 | 0.312 | 0.062 | 0.062
20,000 | 6.859 | 0.937 | 0.234 | 1.140 | 0.250 | 0.109
50,000 | 55.62 | 5.546 | 1.437 | 9.703 | 1.468 | 0.234
100,000 | 247.9 | 24.42 | 5.812 | 39.32 | 5.765 | 0.593
200,000 | 2,158 | 158.7 | 25.73 | 174.5 | 33.62 | 2.156
500,000 | - | 1,270 | 215.5 | 3,173 | 874.8 | 13.51
1,000,000 | - | - | 1,019 | - | - | 58.02
Es interesante que g2finalmente supere g3, a pesar de una tasa de convergencia más lenta. Sospecho que esto se debe a que los operandos crecen a un ritmo significativamente más lento, ganando a la larga. La implicación más rápida g4_mdes aproximadamente 235 veces más rápida que la g3_refimplicación en 500,000 dígitos. Dicho esto, todavía hay una sobrecarga significativa para la transmisión de dígitos de esta manera. Calcular todos los dígitos directamente usando Ramanujan 39 ( fuente de Python ) es aproximadamente 10 veces más rápido.
¿Por qué no Chudnovsky?
El algoritmo de Chudnovsky requiere una raíz cuadrada de precisión completa, que honestamente no estoy seguro de cómo trabajar, suponiendo que pueda serlo. Ramanujan 39 es algo especial en este sentido. Sin embargo, parece que el método podría conducir a fórmulas similares a las de Machin, como las utilizadas por y-cruncher, por lo que podría ser una vía que vale la pena explorar.