Wyobraź sobie kostkę, którą możemy pokroić na mniejsze kostki bez pozostawiania kawałków.

Sprawdź, ile kostek można wyciąć.

Na przykład, sześcian można pokroić na 8, 27 (oczywiście 3 potęgi liczb całkowitych) i 20 (19 małych kostek plus jeden osiem razy większy od pozostałych, patrz zdjęcie).
Zobacz tutaj pomoc: http://mathworld.wolfram.com/CubeDissection.html

Program powinien przyjąć jako liczbę całkowitą wejściową n( 0 <= n <= 1 000) i wypisać wszystkie liczby mniejsze lub równe, aby nsześcian mógł zostać pocięty na tę liczbę kostek. Załóżmy, że kostkę można pokroić na 1 kostkę, a nie na 0 kostek.

Można używać tylko integralnych typów danych (bez tablic, obiektów itp.) O rozmiarze nie większym niż 64-bitowy. Najkrótszy kod wygrywa.

Golfscript, 55 (lub 43 42)

{.:^}{.47>20{.^>^@- 7%|!|}:/~1/38/39/{}{;}if^(}while;]`

Można go przetestować tutaj (wystarczy zmienić numer w wierszu 2) i używa tylko tablicy (ostatnich dwóch znaków kodu) do czystego drukowania, a nie do gromadzenia lub rozwiązywania problemów. Jeśli to odłożysz, wszystkie wyniki zostaną połączone.

Metoda: Iteracja w dół od podanego n: Jeśli bieżąca liczba jest większa niż 47 lub w postaci 1 + 7x, 20 + 7x, 38 + 7x lub 39 + 7x, gdzie x = jakakolwiek liczba całkowita nieujemna, trzymaj ją na stosie , w przeciwnym razie upuść.

Krótka odpowiedź (43 bajty):

{: / 6 +, {7 * / +}% |}: &;): a, 48, ^ 1 & 20 & 38 & 39 & {a <}, `

):a,48,^1{:/6+,{7*/+}%|}:&~20&38&39&{a<},`

Metoda: podobna, ale z kilkoma zestawami teorii. Używa tablic, więc technicznie nie jest to akceptowalna odpowiedź. Można przetestować tutaj . Btw: nikt nigdy nie powiedział, że muszą być w określonej kolejności;)

Mathematica, 62 bajty (lub 52)

Odpowiedź jest zakodowana na stałe, nic ciekawego.

If[EvenQ@BitShiftRight[164015534735101,n],Print@n]~Do~{n,1000}

Ten ma 52 bajty długości, ale narusza moje zasady - używa dużych liczb całkowitych (potęgi 2) i list (zasięg).

Select[Range@1000,EvenQ@Floor[164015534735101/2^#]&]

C 72

i;main(){for(scanf("%d",&i);i;i--)0x952BD7AF7EFC>>i&1||printf("%d ",i);}

Kolejna zakodowana odpowiedź. Odlicza się to w dół (nie ma nic w regułach dotyczących kolejności, w jakiej liczby muszą być wyprowadzane.) Teoretycznie powinno to działać. Stała ma bit ustawiony na 1 dla wszystkich liczb, na które NIE MOŻNA wyciąć sześcianu, i 0 dla liczb, które mogą. Teoretycznie stała przesunięta w prawo o bardzo dużą liczbę powinna wynosić zero, więc dużą liczbę należy zawsze wydrukować.

Co ciekawe, w praktyce to nie działa. Powyższy kod kompiluje się i działa poprawnie na GCC do 65. Ale powyżej tej liczby jest błąd (lub „funkcja”) w kompilatorze. to interpretuje 0x952BD7AF7EFC>>ijako 0x952BD7AF7EFC>>i%64. Pomija (na przykład) liczby od 66 do 71 (od 64 + 2 do 64 + 7).

Aby uruchomić się w Visual Studio, potrzebna jest nieco więcej płyt kotłowych (nie pozwala to na uniknięcie takich rzeczy, jak domniemane liczby całkowite i #includes.) Po uruchomieniu programu jest w porządku do 257 ... Następnie przeskakuje 258 przez 263 (256 + 2 do 256 + 7). Więc to zajmujei%256.

Mogę to naprawić później (jeśli mogę się niepokoić). Morał: podręczniki kompilatora zwykle nie określają górnej granicy przesunięć bitów. Jest po temu powód!