ลองนึกภาพก้อนที่เราสามารถตัดเป็นก้อนเล็กโดยไม่เหลือชิ้น

ค้นหาจำนวนคิวบ์ที่สามารถตัดได้หนึ่งลูกบาศก์

ตัวอย่างเช่นลูกบาศก์สามารถตัดเป็น 8, 27 (พลังที่ 3 อย่างชัดเจนของจำนวนเต็ม) และ 20 (19 ก้อนเล็กบวกหนึ่งแปดเท่าของขนาดอื่นดูภาพ)
ดูความช่วยเหลือบางส่วนได้ที่นี่: http://mathworld.wolfram.com/CubeDissection.html

โปรแกรมควรใช้เป็นจำนวนเต็มเข้าn( 0 <= n <= 1 000) และพิมพ์ตัวเลขทั้งหมดน้อยกว่าหรือเท่ากับเพื่อnให้สามารถตัดคิวบ์ลงในจำนวนคิวบ์นั้น สมมติว่าลูกบาศก์นั้นสามารถตัดเป็น 1 ลูกบาศก์และไม่สามารถกลายเป็น 0 ลูกบาศก์ได้

คุณสามารถใช้ประเภทข้อมูลที่ครบถ้วนเท่านั้น (ไม่มีอาร์เรย์, วัตถุอื่น ๆ ) ที่มีขนาดไม่เกิน 64 บิต รหัสที่สั้นที่สุดชนะ

Golfscript, 55 (หรือ43 42)

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

สามารถทดสอบได้ที่นี่ (เพียงเปลี่ยนหมายเลขในบรรทัดที่ 2) และใช้เฉพาะอาเรย์ (สองตัวอักษรสุดท้ายของรหัส) สำหรับการพิมพ์ที่สะอาดไม่ใช่สำหรับการรวบรวมหรือการแก้ปัญหา หากคุณปล่อยทิ้งไว้ผลลัพธ์ทั้งหมดจะถูกต่อกัน

วิธีการ: วนซ้ำจาก n ที่ระบุ: หากจำนวนปัจจุบันมากกว่า 47 หรือรูปแบบ 1 + 7x, 20 + 7x, 38 + 7x หรือ 39 + 7x โดยที่ x = จำนวนเต็มใด ๆ ที่ไม่เป็นลบให้เก็บไว้ในสแต็ก มิฉะนั้นวางไว้

คำตอบสั้น ๆ (43 ไบต์):

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

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

วิธีการ:คล้ายกัน แต่ใช้ทฤษฎีเซตน้อย นี่ใช้อาร์เรย์ดังนั้นจึงไม่ใช่คำตอบที่ยอมรับได้ทางเทคนิค สามารถทดสอบได้ที่นี่ Btw: ไม่มีใครเคยบอกว่าพวกเขาจะต้องอยู่ในลำดับใดโดยเฉพาะ;)

Mathematica, 62 ไบต์ (หรือ 52)

มันเป็นคำตอบที่ยากมากไม่มีอะไรน่าสนใจ

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

อันนี้ยาว 52 ไบต์ แต่ละเมิดกฎของฉัน - มันใช้จำนวนเต็มขนาดใหญ่ (พลังของ 2) และรายการ (ช่วง)

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

C, 72

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

อีกคำตอบที่ hardcoded สิ่งนี้นับถอยหลัง (ไม่มีสิ่งใดในกฎเกณฑ์เกี่ยวกับลำดับตัวเลขที่ต้องส่งออก) ในทางทฤษฎีมันควรใช้งานได้ ค่าคงที่มีการตั้งค่าเป็นบิต 1 สำหรับตัวเลขทั้งหมดที่ลูกบาศก์ไม่สามารถตัดได้และ 0 สำหรับตัวเลขที่สามารถ ตามทฤษฎีแล้วค่าคงที่เมื่อถูกเลื่อนด้วยจำนวนที่มากควรเป็นศูนย์ดังนั้นจำนวนมากควรถูกพิมพ์เสมอ

สิ่งที่น่าสนใจคือในทางปฏิบัติสิ่งนี้ไม่ได้ผล โค้ดด้านบนรวบรวมและทำงานได้ดีบน GCC สูงถึง 65 แต่เหนือหมายเลขนั้นมีจุดบกพร่อง (หรือ "คุณสมบัติ") ในคอมไพเลอร์ มันตีความเป็น0x952BD7AF7EFC>>i 0x952BD7AF7EFC>>i%64ดังนั้นจึงข้าม (ตัวอย่าง) ตัวเลข 66 ถึง 71 (64 + 2 ถึง 64 + 7)

เพื่อให้ทำงานใน Visual Studio จำเป็นต้องมี boilerplate เพิ่มขึ้นอีกเล็กน้อย (ไม่อนุญาตให้คุณหลีกเลี่ยงสิ่งต่าง ๆ เช่นจำนวนเต็มและ#includes โดยนัย) เมื่อโปรแกรมทำงานและทำงานเสร็จก็ปรับได้มากถึง 257 ... จากนั้นข้ามไป 258 ถึง 263 (256 +2 ถึง 256 + 7) ดังนั้นมันจึงใช้เวลาi%256.

ฉันอาจแก้ไขได้ในภายหลัง (ถ้าฉันสามารถใส่ใจได้) Moral: คู่มือคอมไพเลอร์ไม่ปกติบอกคุณขีด จำกัด บนบิต มีเหตุผลสำหรับสิ่งนั้น!