Imaginez un cube que nous pouvons couper en cubes plus petits sans morceaux restants.
Trouvez combien de cubes un cube peut être coupé.
Par exemple, un cube peut être coupé en 8, 27 (évidemment les 3èmes puissances d'entiers) et 20 (19 petits cubes plus un huit fois la taille des autres, voir image).
Voir ici de l'aide: http://mathworld.wolfram.com/CubeDissection.html
Le programme doit prendre comme entier n
( 0 <= n <= 1 000
) d' entrée et imprimer tous les nombres inférieurs ou égaux pour n
qu'un cube puisse être coupé en ce nombre de cubes. Supposons que le cube puisse être coupé en 1 cube et ne puisse pas être en 0 cube.
Vous ne pouvez utiliser que des types de données intégraux (pas de tableaux, d'objets, etc.) d'une taille ne dépassant pas 64 bits. Le code le plus court gagne.
la source
Réponses:
Golfscript, 55 (ou
4342)Peut être testé ici (changez simplement le nombre sur la ligne 2) et utilise uniquement le tableau (les deux derniers caractères du code) pour une impression propre, pas pour une collection ou une résolution de problème. Si vous ne le laissez pas, tous les résultats seront concaténés.
Méthode: Itérer vers le bas à partir de n donné: Si le nombre actuel est supérieur à 47 ou de la forme 1 + 7x, 20 + 7x, 38 + 7x ou 39 + 7x où x = tout entier non négatif, alors conservez-le sur la pile , sinon laissez-le tomber.
Réponse courte (43 octets):
{: / 6 +, {7 * / +}% |}: &;): a, 48, ^ 1 & 20 & 38 & 39 & {a <}, `Méthode: similaire, mais avec quelques ops de théorie des ensembles. Cela utilise des tableaux donc ce n'est techniquement pas une réponse acceptable. Peut être testé ici . Btw: personne n'a jamais dit qu'ils devaient être dans un ordre particulier;)
la source
Mathematica, 62 octets (ou 52)
C'est une réponse codée en dur, rien d'intéressant.
Celui-ci fait 52 octets de long mais viole mes règles - il utilise de grands entiers (puissances de 2) et des listes (Range).
la source
C, 72
Une autre réponse codée en dur. Cela compte vers le bas (il n'y a rien dans les règles concernant l'ordre dans lequel les chiffres doivent être sortis.) En théorie, cela devrait fonctionner. La constante a un bit mis à 1 pour tous les nombres dans lesquels un cube NE PEUT PAS être coupé, et à 0 pour les nombres qui le peuvent. En théorie, la constante lorsqu'elle est décalée vers la droite d'un très grand nombre doit être nulle, donc le grand nombre doit toujours être imprimé.
Ce qui est intéressant, c'est que dans la pratique, cela ne fonctionne pas. Le code ci-dessus compile et fonctionne correctement sur GCC jusqu'à 65. Mais au-dessus de ce nombre, il y a un bogue (ou "fonctionnalité") dans le compilateur. il interprète
0x952BD7AF7EFC>>i
comme0x952BD7AF7EFC>>i%64
. Il saute donc (par exemple) les nombres 66 à 71 (64 + 2 à 64 + 7).Pour fonctionner dans Visual Studio, un peu plus de passe-partout est nécessaire (cela ne vous permet pas de vous en tirer avec des choses comme les entiers et les
#include
s implicites .) Une fois le programme opérationnel, il peut aller jusqu'à 257 ... Ensuite, il passe de 258 à 263 (256 + 2 à 256 + 7.) Il faut donci%256.
Je peux le corriger plus tard (si cela me dérange). Moral: les manuels du compilateur ne vous indiquent normalement pas la limite supérieure des décalages de bits. Il y a une raison à cela!
la source
0
bit zéro, je pourrais le changer1
comme le vôtre pour le cas i = 0. Mais il ne s'affiche jamais de toute façon.NUM>>i
modifications ont été apportéesNUM>>i%64
. De plus, si un64-bit
nombre est décalé vers la droite plus de 64 fois, il devrait devenirzero
NUM>>i
devientNUM>>(i%64)
ou de manière équivalenteNUM>>(i&63)
car le compilateur tronque les bits les plus à gauche dei
avant d'effectuer le décalage de bits. GCC ne considère que les 6 bits les plus à droite. Visual Studio a le même bogue mais est légèrement meilleur, considérant uniquement les 8 bits les plus à droiteNUM>>(i%256)
. Par curiosité, j'essaierai Ideone à mon retour du travail.