Chúng tôi có một thách thức để ra điểm riêng của bạn , nhưng nó có vẻ như tất cả các câu trả lời chỉ có hardcode đầu ra và đó là nhàm chán ¹ . Vì vậy, hãy có một thách thức mới. Chương trình của bạn phải xuất độ dài riêng theo byte theo chuỗi " bytes", nhưng để ngăn các giải pháp được mã hóa cứng nếu chúng ta giảm kích thước của nó bằng cách xóa bất kỳ một byte nào, chương trình mới cũng phải xuất ra số byte mới, vẫn theo sau " bytes". Đầu ra không cần phải phân biệt chữ hoa chữ thường. Bạn cũng có thể chọn để xuất một dòng mới.

Câu trả lời của bạn sẽ được ghi bằng byte với ít byte hơn.

^{1: Tôi thực sự thích một số câu trả lời ở đó.}

Trái tay , 40 36 29 byte

vv""sseettyybb  ""jjHHOO]

Hãy thử trực tuyến! Xác minh!

Khi nghi ngờ, tăng gấp đôi trên tất cả mọi thứ. Điều này sử dụng khả năng của Backhand để di chuyển nhiều bước một lần để thực hiện dự phòng. Tất cả các unprintable đều có giá trị byte 28.

Giải trình:

Chương trình không chiếu xạ:

v       Reduce step count to 2
  "    Start string literal
    s e t y b        Push the " bytes" part of the output
                  " Push 28 twice and end the string literal
                       j    Jump to the 28th position (0 indexed) 
                             ]   Increment the 28 to 29
                           O     Print the 29
                         H       Halt and output the entire stack

Chương trình chiếu xạ:

Nếu bất kỳ ký tự nào bị xóa, mọi ký tự sau đó sẽ được chuyển xuống.

vv"sseettyybb
v " s e t y b     The same instructions are still executed

Tuy nhiên, thay vì nhảy đến ], thay vào đó, nó phản ánh kết thúc chương trình và Othay vào đó.

                             v  28th character (0 indexed)
vv""sseettyybb       ""jjHHOO]
v""sseettyybb       ""jjHHOO]OOHHjj"".....
                             ^ 28th character, reflecting off the end of the code

Bùa mê , 47 byte

>>yyLL     @"setyb 64"/
"47 bytes"@"setyb 64"L\

Hãy thử trực tuyến!

Đó ít nhiều là một cổng của câu trả lời Geiger Counter của tôi , nhưng với đầu ra khác nhau (chính là cổng của câu trả lời Klein).

>>yyLLRunic được yêu cầu để tạo (ít nhất) một IP, hợp nhất hai IPS và phản xạ trở lại bên trái, để tất cả các biến thể dẫn đến một IP di chuyển trái. Có thể được thay thế bởi yy<<nhưng nó không lưu bất kỳ byte nào.

Các gương phản xạ ở bên phải buộc IP xuống chuỗi bên trái phía dưới, do đó việc loại bỏ một trong số chúng bên phải cho phép IP vào chuỗi trên cùng bên phải. Việc loại bỏ một byte ở bất kỳ nơi nào khác dọc theo đường trên cùng sẽ điều chỉnh bộ phản xạ trên cùng để ngồi phía trên L (cho phép chương trình ở phía dưới bên phải). Việc loại bỏ một byte dọc phía dưới sẽ điều chỉnh bộ phản xạ (hoặc loại bỏ nó) để ký tự cuối cùng được lấp đầy một khoảng trắng, cho phép IP bật ra cả hai mặt của bộ phản xạ trên cùng bên phải và vào chuỗi trên cùng bên phải.

Các không gian dư thừa là đáng thất vọng, mặc dù. Nhưng tất cả các nỗ lực để giảm chúng đã dẫn đến các chương trình lớn hơn, các chương trình có cùng kích thước hoặc các chương trình không phải là bằng chứng phóng xạ 100%. Cả câu trả lời của Klein và> <> ở đây đều sử dụng các tính năng không có trong Runic.

> <> , 43 39 byte

||vn-{"' bytes"-10/
 o>o<"38 bytes"[0/0

Hãy thử trực tuyến! Xác minh!

Trong chương trình không chiếu xạ, chúng tôi thêm 0vào '(39) và trong chương trình chiếu xạ, chúng tôi bỏ qua 0 và -1thay vào đó. Nếu một cái gì đó được loại bỏ khỏi hàng trên cùng, thay vào đó chúng tôi chuyển sang hàng dưới cùng và chỉ xuất ra 38 bytes.

Lục giác , 71 byte

//.........||.>e;s;@..\;t;y;b<>}F"+!P0;/|/F!P0$@;<...t;ye;bs/.........)

Hãy thử trực tuyến! Xác minh!

Tôi đã mất quá nhiều thời gian để cố gắng đưa nó vào một hình lục giác kích thước 5, nhưng thay vào đó tôi phải giải quyết cho một kích thước phụ 6 :(.

Mở rộng:

      / / . . . .
     . . . . . | |
    . > e ; s ; @ .
   . \ ; t ; y ; b <
  > } F " + ! P 0 ; /
 | / F ! P 0 $ @ ; < .
  . . t ; y e ; b s /
   . . . . . . . . .
    ) . . . . . . .
     . . . . . . .
      . . . . . .

Ban đầu tôi đã thực hiện điều này với )một hàng thấp hơn, nhưng hóa ra đó chính xác là nơi phân chia giữa các hình lục giác kích thước 5 và kích thước 6. Điều này có nghĩa là khi một byte bị loại bỏ, kích thước tất cả sẽ dịch chuyển xuống và làm hỏng các đường dẫn. Tôi chắc chắn rằng kích thước 5 là có thể.

Klein 000, 41 byte

<<@"setyb "$"4"+"0"/
..@"setyb 04"(....<1

Hãy thử trực tuyến! Trình xác minh của JoKing

Tôi nghĩ câu trả lời này tương tự như câu trả lời của JoKing> <> , nhưng tôi không đọc> <> vì vậy tôi không chắc chắn.

Có 4 loại loại bỏ byte khác nhau ở đây

1. Một byte được loại bỏ khỏi dòng đầu tiên trước đó /. Trong trường hợp này, dấu gạch chéo được di chuyển một cách hiệu quả để lại một khoảng trắng, làm chệch hướng nó xuống dòng dưới cùng và ngăn phần sửa đổi của mã được thực thi. Điều này khiến chúng tôi chạy mã ("40 bytes"@, mà đầu ra 40 bytes.

2. Đầu tiên /được loại bỏ khỏi dòng đầu tiên. Trong trường hợp này, chúng tôi chạy mã "0"+"4"$" bytes"@, đó là một cách phức tạp hoặc in ấn 40 bytes.

3. Dòng mới được gỡ bỏ. Điều này làm cho chúng ta bắt đầu từ cuối dòng thứ hai và mã kết quả (đã loại bỏ noops) 1("40 bytes"@, chỉ in 40 bytes.

4. Một byte từ dòng cuối cùng được loại bỏ. Điều này làm cho 1phần cuối của dòng đầu tiên được di chuyển sang trái và ngăn không cho nó được thêm vào ngăn xếp khi mũi nhọn bị lệch /. Mã "0"+cho lý do đó đẩy 0thay vì 1, phần còn lại của mã biến 0thành 40 bytes.

Klein 001, 41 byte

\("40 bytes"@......1
..@"setyb "$"4"+"0"/

Hãy thử trực tuyến! Trình xác minh của JoKing

Đây là một câu trả lời bằng cách sử dụng một cấu trúc liên kết khác nhau. Nó có cùng kích thước nhưng tôi nghĩ vẫn còn chỗ để cải thiện.