El código de golf siempre involucra algunas respuestas que doblan las reglas más o menos al romper las restricciones que los retadores dieron por sentado o simplemente no pensaron y no mencionaron en las reglas. Una de estas lagunas interesantes es la posibilidad de generar más de lo que el desafío requiere para obtener un mejor resultado.
Llevando esto a los extremos, podemos escribir un solucionador de golf de código universal que imprima la salida deseada, si no le importa, podría llevar años y generar muchas otras cosas antes y después.
Todo lo que necesitamos para generar es una secuencia que garantice que contenga todas las subsecuencias posibles. Para este código de golf, esta será la secuencia Ehrenfeucht-Mycielski :
La secuencia comienza con los tres bits 010; cada dígito sucesivo se forma al encontrar el sufijo más largo de la secuencia que también aparece antes dentro de la secuencia y complementar el bit que sigue a la aparición anterior más reciente de ese sufijo.
Cada subsecuencia finita de bits ocurre contiguamente, infinitamente a menudo dentro de la secuencia
Los primeros dígitos de la secuencia son:
010011010111000100001111 ... (secuencia A038219 en OEIS ).
Combinando 8 bits de la secuencia en un byte, obtendremos una salida ASCII que podemos enviar a la pantalla o a un archivo y que contiene todas las salidas finitas posibles . El programa generará partes de pi, la letra de "Nunca te daré por vencido" , un bonito arte ASCII, su propio código fuente y todo lo demás que quieras que salga.
Para probar la corrección, aquí hay hashes para los primeros 256 bytes de la secuencia:
MD5: 5dc589a06e5ca0cd9280a364a456d7a4
SHA-1: 657722ceef206ad22881ceba370d32c0960e267f
Los primeros 8 bytes de la secuencia en notación hexadecimal son:
4D 71 0F 65 27 46 0B 7C
Reglas:
Su programa debe generar la secuencia Ehrenfeucht-Mycielski (nada más), combinando 8 bits a un carácter byte / ASCII.
El programa más corto (recuento de personajes) gana. Resta 512 de tu recuento de caracteres si logras generar la secuencia en tiempo lineal por byte generado .
Respuestas:
C, –110 caracteres
Esta versión del programa utiliza el algoritmo de tiempo de ejecución lineal para generar la secuencia. Restar 512 de los 402 caracteres en el programa da un total de 110 negativos.
Según el problema, el programa se ejecuta en un bucle infinito, lo que requiere mucha asignación de memoria, y el uso
realloc()
para mantener la secuencia contigua puede contribuir a la fragmentación del montón. Puede mejorar el uso de memoria del programa reemplazandocalloc(7,8)
en la primera línea concalloc(1,sizeof*v)
. Esto ayudará especialmente en una máquina de 32 bits, donde 56 es probablemente demasiado grande por un factor de dos.El código es ilegible y no de una manera interesante; Por eso me disculpo. Francamente, incluso la versión sin golf no es terriblemente clara:
(El código anterior no basado en golf se basa en el código escrito por Grzegorz Herman y Michael Soltys, como se menciona en la descripción del problema, y en la página de inicio de Soltys ).
Gracias a @schnaader y @res por informar un error en la versión inicial.
fuente
malloc
versiones modificadas , sin golf y modificadas paralizan la salida después de aproximadamente 10000 bytes y continúan asignando memoria, lo queprog > out.dat
produce un bloqueo instantáneo con solo ~ 700 KB de uso de memoria. Si insertoprintf("\n%i\n", size);
despuésrealloc
, la mayor salida es4
. Sistema: Windows 7 Prof. 64-Bit, 4 GB RAM, GCC 4.6.1Ruby,
10910410194 caracteresImplementación en Ruby utilizando expresiones regulares para la búsqueda de sufijos. Como lleva bastante tiempo hasta que se agote la memoria, el usuario debe finalizar el programa.
Editar: Acabo de notar que es suficiente comenzar con la secuencia
0
.Edición 2: la propuesta de res guarda 2 caracteres, algunos otros porque no tenemos que cortar un solo byte antes
pack
.fuente
s=(s[/(.*).*\1/][/.#{$1}/]<?1??1:?0)+s
salvará otros dos caracteres.?C
?Perl, 95 caracteres
En realidad, al principio tenía una versión bastante decente de esto. Luego, mientras jugaba al golf, cada versión se hizo más lenta. Cada vez más lento.
Los primeros tres caracteres (
$|=
) no son necesarios, estrictamente hablando ... pero sin eso allí, normalmente tendrías que esperar a que el script termine de generar 4096 bytes completos antes de ver cualquiera de los resultados. Y eso llevaría horas. Quizás siglos; No estoy seguro. ¿Mencioné que el rendimiento de este programa se deteriora con el tiempo? Por eso me sentí obligado a incluirlos en el recuento.Por otro lado, este script tiene una de las expresiones regulares más feas que he creado, así que creo que estoy orgulloso de ello.
fuente