prefacio
En una situación muy calurosa, tienes que ir aún más lejos con el golf.
(por ejemplo, en un desafío en el que su respuesta tiene 100 caracteres de longitud y es vergonzoso que no haya podido hacerlo 99)
En ese caso, a partir de ahora utilizará el algoritmo del ganador de este desafío :)
objetivo
Debe escribir un programa que tome un uint32 y devuelva la forma más comprimida.
$ mathpack 147456
9<<14
- Habrá múltiples soluciones para un número. Elige el más corto
- Si la forma comprimida es más larga o igual al número original, devuelva el número original
reglas
- escribir en cualquier idioma - salida en cualquier idioma
- Soy consciente de que en C
'abc'
está6382179
y puede lograr resultados bastante buenos con esta conversión. pero los idiomas están separados en este desafío, así que no se desanime - Está prohibido utilizar variables externas. solo operadores y literales y funciones relacionadas con las matemáticas!
puntuación
Estos son los casos de prueba: pastebin.com/0bYPzUhX
su puntaje (porcentaje) será la proporción de byte_size_of_your_output / byte_size_of_the_list
sin saltos de línea .
(debe hacerlo usted mismo, ya que verifico los mejores códigos por si acaso) ¡los
ganadores serán elegidos por puntaje e idioma de salida !
ejemplos:
$ mathpack 147456 | mathpack 97787584 | mathpack 387420489
9<<14 | 9e7^9e6 | pow(9,9)
code-challenge
bebe
fuente
fuente
write in any language - output in any language
- los dos idiomas pueden ser diferentes, ¿verdad?Respuestas:
Código: Mathematica, Salida: C, ~ 62.1518% (12674/20392)
Pensé que también le daría una oportunidad a C debido a esos divertidos literales de personajes. Actualmente, esto es lo único que intenta esta respuesta, y está funcionando bastante bien.
Espero no haberme perdido nada, pero esta respuesta se asegura de evitar las barras diagonales inversas, las comillas simples y los trigrafos. Hay un código comentado que utiliza secuencias de escape octales u otras para caracteres no imprimibles, pero no creo que sea realmente necesario, porque C debería ser capaz de manejar cualquier byte en literales de caracteres, afaik (corríjame si yo 'Estoy mal).
Al igual que con la otra presentación, pruebe esto con
fuente
\n
) y 13 (\r
). Un byte cero compilará bien, pero con el mensaje de errorwarning: null character(s) preserved in literal
.Código: Mathematica, Salida: Julia, ~ 98.9457% (20177/20392 bytes)
La función toma un número y devuelve la cadena más corta que encuentra. Actualmente aplica cuatro optimizaciones simples (podría agregar más mañana).
Puede aplicarlo a todo el archivo (para medir su puntaje) de la siguiente manera:
Tenga en cuenta que algunas de estas optimizaciones suponen que está en una Julia de 64 bits, de modo que los literales enteros le dan un
int64
valor predeterminado. De lo contrario, se desbordará de todos modos para enteros mayores que 2 31 . Usando esa suposición, podemos aplicar algunas optimizaciones cuyos pasos intermedios son incluso mayores que 2 32 .EDITAR: agregué la optimización sugerida en los ejemplos de OP para bit xor dos grandes números en notación científica (en realidad, para todos xor , o y y ). Tenga en cuenta que la ampliación de la
xormap
,ormap
yandmap
para incluir más allá de operandos 2 32 podría ayudar a encontrar optimizaciones adicionales, pero no funciona para los casos de prueba dado y sólo aumenta el tiempo de funcionamiento por algo así como un factor de 10.EDITAR: eliminé otros 16 bytes, comprobando
n-9, n-8, ..., n+8, n+9
si alguno de ellos se puede acortar, en cuyo caso representé el número basado en eso, sumando o restando la diferencia. Hay algunos casos en los que uno de esos 18 números se puede representar con 3 o más caracteres menos que éln
mismo, en cuyo caso puedo hacer algunos ahorros adicionales. Tarda unos 30 segundos en ejecutarse en todos los casos de prueba, pero, por supuesto, si alguien realmente "utilizara" esta función, solo la ejecutaría en un solo número, por lo que aún está por debajo de un segundo.EDITAR: Otros 4 bytes increíbles haciendo lo mismo para multiplicación y división. 50 segundos ahora (los divididos no tardan tanto, porque solo los estoy verificando si el número es realmente divisible por el factor de interés).
EDITAR: Otra optimización que en realidad no ayuda con el conjunto de pruebas dado. Este podría ahorrar un byte para cosas como 2 30 o 2 31 . Si tuviéramos uint64s en su lugar, habría muchos números en los que esto podría ser un gran ahorro (básicamente, cada vez que la representación de bits termina en muchos 1s).
EDITAR: Se eliminó el xor , o , y las optimizaciones por completo. Acabo de darme cuenta de que ni siquiera funcionan en Julia, porque (obviamente) la notación científica le da un flotante donde los operadores de bits no están definidos. Curiosamente, una o más de las optimizaciones más nuevas parecen captar todos los casos que fueron acortados por estas optimizaciones, porque el puntaje no cambió en absoluto.
fuente
J a C (no probado, pero funciona en la mayoría de los casos, una especie de respuesta de referencia).
Emite un literal de cadena que, si se ingresa en C, representa el número (como se menciona en el OP). Esta no es una presentación seria, sino algo para fortalecer mis habilidades de J, que pensé que compartiría.
Una línea alternativa:
Lo que J intenta hacer con esto cuando lo ingresas:
Muchas gracias, J. Además, para los que están en 'el saber' sobre J, visio rocas para crear funciones más complejas:
fuente
\
,?
o'
?m&u@:v
, úsalom u v
para guardar personajes preciosos y mejorar la legibilidad. Aplicando esto a su código, obtenemosf =: [: (,~ 0 $~ 8 - 8 | #) #:
yg =: [: ($~ 8 ,~ # % 8:) f
por últimotoCString =: a. {~ [: #. g
. Todos combinados obtenemosa. {~ [: #. [: ($~ 8 ,~ # % 8:) [: (,~ 0 $~ 8 - 8 | #) #:
, lo cual es realmente fácil de leer.