Imagine un cubo que podamos cortar en cubos más pequeños sin piezas restantes.
Averigua cuántos cubos puede cortar un cubo.
Por ejemplo, un cubo se puede cortar en 8, 27 (obviamente 3er potencias de enteros) y 20 (19 cubos pequeños más uno ocho veces el tamaño de los otros, ver imagen).
Vea aquí algo de ayuda: http://mathworld.wolfram.com/CubeDissection.html
El programa debe tomar como entero de entrada n
( 0 <= n <= 1 000
) e imprimir todos los números menores o iguales para n
que un cubo se pueda cortar en ese número de cubos. Suponga que el cubo se puede cortar en 1 cubo y no se puede cortar en 0 cubos.
Puede usar solo tipos de datos integrales (sin matrices, objetos, etc.) de tamaño no mayor a 64 bits. El código más corto gana.
code-golf
math
restricted-source
Somnium
fuente
fuente
Respuestas:
Golfscript, 55 (o
4342)Puede probarse aquí (solo cambie el número en la línea 2) y solo usa la matriz (dos últimos caracteres de código) para una impresión limpia, no para ninguna colección o resolución de problemas. Si lo deja, todos los resultados serán concatenados.
Método: Iterar hacia abajo desde n dado: Si el número actual es mayor que 47 o de la forma 1 + 7x, 20 + 7x, 38 + 7x, o 39 + 7x donde x = cualquier número entero no negativo, manténgalo en la pila , de lo contrario colóquelo.
Respuesta corta (43 bytes):
{: / 6 +, {7 * / +}% |}: &;): a, 48, ^ 1 y 20 y 38 y 39 y {a <}, `Método: similar, pero con algunas operaciones de teoría de conjuntos. Esto usa matrices, por lo que técnicamente no es una respuesta aceptable. Se puede probar aquí . Por cierto: nadie dijo que tenían que estar en un orden particular;)
fuente
Mathematica, 62 bytes (o 52)
Es una respuesta codificada, nada interesante.
Este tiene 52 bytes de longitud pero viola mis reglas: utiliza enteros grandes (potencias de 2) y listas (Rango).
fuente
C, 72
Otra respuesta codificada. Esto cuenta hacia abajo (no hay nada en las reglas sobre el orden en que los números tienen que salir). En teoría, debería funcionar. La constante tiene un bit establecido en 1 para todos los números en los que NO se puede cortar un cubo, y un 0 para los números que sí se pueden cortar. En teoría, la constante cuando se desplaza a la derecha por un número muy grande debe ser cero, por lo que el número grande siempre debe imprimirse.
Lo interesante es que en la práctica esto no funciona. El código anterior compila y funciona bien en GCC hasta 65. Pero por encima de ese número hay un error (o "característica") en el compilador. se interpreta
0x952BD7AF7EFC>>i
como0x952BD7AF7EFC>>i%64
. Por lo tanto, omite (por ejemplo) los números del 66 al 71 (64 + 2 a 64 + 7).Para ejecutarse en Visual Studio, se necesita un poco más repetitivo (no le permite salirse con la suya con números enteros implícitos y
#include
s). Una vez que el programa está en funcionamiento, está bien hasta 257 ... Luego se salta 258 263 (256 + 2 a 256 + 7.) Por lo tanto, está tomandoi%256.
Puedo arreglarlo más tarde (si me molestan). Moral: los manuales del compilador normalmente no le indican el límite superior de los cambios de bits. ¡Hay una razón para eso!
fuente
0
bit cero, podría cambiarlo por el1
tuyo para el caso i = 0. Pero nunca se muestra de todos modos.NUM>>i
cambia aNUM>>i%64
. Además, si un64-bit
número es correcto desplazado más de 64 veces que debe convertirsezero
NUM>>i
se convierteNUM>>(i%64)
o equivalenteNUM>>(i&63)
porque el compilador está truncando los bits más a la izquierda dei
antes de realizar el desplazamiento de bits. GCC solo considera los 6 bits más a la derecha. Visual Studio tiene el mismo error pero es ligeramente mejor, considerando solo los 8 bits más a la derechaNUM>>(i%256)
. Por curiosidad intentaré Ideone cuando llegue a casa del trabajo.