Imagine um cubo que possamos cortar em cubos menores sem pedaços restantes.
Encontre quantos cubos um cubo pode ser cortado.
Por exemplo, um cubo pode ser cortado em 8, 27 (obviamente, terceira potência de números inteiros) e 20 (19 cubos pequenos mais um oito vezes o tamanho dos outros, veja a imagem).
Veja aqui alguma ajuda: http://mathworld.wolfram.com/CubeDissection.html
O programa deve assumir como número inteiro de entrada n
( 0 <= n <= 1 000
) e imprimir todos os números menores ou iguais a, n
para que um cubo possa ser cortado nesse número de cubos. Suponha que o cubo possa ser cortado em 1 cubo e não em 0 cubos.
Você pode usar apenas tipos de dados integrais (sem matrizes, objetos etc.) de tamanho não superior a 64 bits. O menor código vence.
fonte
Respostas:
Golfscript, 55 (ou
4342)Pode ser testado aqui (basta alterar o número na linha 2) e usa apenas a matriz (dois últimos caracteres de código) para impressão limpa, não para coleta ou solução de problemas. Se você deixar de fora, todos os resultados serão concatenados.
Método: Iterate down from from n: Se o número atual for maior que 47 ou no formato 1 + 7x, 20 + 7x, 38 + 7x ou 39 + 7x em que x = qualquer número inteiro não negativo, mantenha-o na pilha , caso contrário, solte-o.
Resposta curta (43 bytes):
{: / 6 +, {7 * / +}% |}: &;): a, 48, ^ 1 & 20 & 38 & 39 & {a <}, `Método: Similar, mas com algumas operações de teoria dos conjuntos. Isso usa matrizes, portanto tecnicamente não é uma resposta aceitável. Pode ser testado aqui . Btw: ninguém nunca disse que tinha que estar em uma ordem específica;)
fonte
Mathematica, 62 bytes (ou 52)
É uma resposta codificada, nada de interessante.
Este tem 52 bytes, mas viola minhas regras - usa números inteiros grandes (potências de 2) e listas (Intervalo).
fonte
C, 72
Outra resposta codificada. Isso conta para baixo (não há nada nas regras sobre a ordem em que os números devem ser impressos.) Em teoria, deveria funcionar. A constante tem um bit definido como 1 para todos os números nos quais um cubo NÃO pode ser cortado e um 0 para os números que podem. Em teoria, a constante quando deslocada para a direita por um número muito grande deve ser zero, portanto o número grande sempre deve ser impresso.
O interessante é que, na prática, isso não funciona. O código acima compila e executa bem no GCC até 65. Mas acima desse número, há um erro (ou "recurso") no compilador. interpreta
0x952BD7AF7EFC>>i
como0x952BD7AF7EFC>>i%64
. Por isso, pula (por exemplo) os números 66 a 71 (64 + 2 a 64 + 7).Para executar no Visual Studio, é necessário um pouco mais de clichê (não permite que você se dê bem com números e números implícitos
#include
). Depois que o programa estiver em funcionamento, é possível chegar a 257 ... Em seguida, pula 258 263 (256 + 2 a 256 + 7).i%256.
Posso corrigi-lo mais tarde (se puder me incomodar.) Moral: os manuais do compilador normalmente não informam o limite superior dos turnos de bits. Há uma razão para isso!
fonte
0
para zero, eu poderia alterá-lo para um1
como o seu para o caso i = 0. Mas nunca é exibido de qualquer maneira.NUM>>i
muda paraNUM>>i%64
. Além disso, se um64-bit
número é direito deslocou mais de 64 vezes, deve tornar-sezero
NUM>>i
se tornaNUM>>(i%64)
ou equivalentementeNUM>>(i&63)
porque o compilador está truncando os bits mais à esquerdai
antes de executar o deslocamento de bits. O GCC considera apenas os 6 bits mais à direita. O Visual Studio tem o mesmo bug, mas é um pouco melhor, considerando apenas os 8 bits mais à direitaNUM>>(i%256)
. Por curiosidade, tentarei o Ideone quando chegar em casa do trabalho.