This program's full of nonprintable characters, so here's a hexdump:
00000000: 2573 dc01 7e13 dcb6 1f %s..~....
Note: this uses a numeric input routine that's incapable of inputting negative numbers, so this submission is restricted to nonnegative integers only.
One problem with cops-and-robbers challenges is that you don't write explanations of the code (to make it harder to crack). On the other hand, this means that I don't have to go to to the trouble here.
I picked 7 as the language because, especially in its compressed notation, it's pretty hard to read, and I don't see why it should be only me who has to go to the trouble of moving around 8-bit chunks of programs written in a 3-bit encoding. Good luck!
Explanation
Now that the program's been cracked (by brute force, unfortunately; that's always a danger in these short solutions), I may as well explain what I was getting at. This was actually fairly solvable by reading the program; I could have made it much more difficult, but that felt like a bad idea when brute-force cracks exist.
We'll start by representing the program in a more natural encoding. As usual, bolded numbers indicate commands that run immediately (not all of which are representable in a program; 6
and 7
are but 2
to 5
aren't), unbolded numbers represent their escaped equivalents (0
to 5
, all of which are representable in the original program; note that 0
is an escaped 6
and 1
is an escaped 7
):
11271734002770236713303
The set of commands available in a 7 program source mean that it's basically just a literal that represents the original stack (there's nothing else you can do with just escaped commands, 6
and 7
). So the first thing a program will do is push a bunch of stuff onto the stack. Here's how the stack looks after the program's run (|
separates stack elements, as usual in 7):
772|7|34662|023|73363
The final stack element then gets copied to become the code to run (while remaining on the stack). As it happens, this is the only part of the program that's code; everything else is just data. Here's what it translates to:
73363
7 Push an empty element onto the stack
3 Output the top stack element, discard the element below
73 Combined effect of these: discard the top stack element
3 Output the top stack element, discard the element below
6 Escape the top stack element, then append it to the element below
3 Output the top stack element, discard the element below
In other words, this is mostly just a bunch of I/O instructions. Let's analyse this in detail:
73
discards the 73363
that's still on top of the stack.
3
outputs the 023
, and discards the 34662
. It can thus be seen that the 34662
is a comment, which was used to store the bytes needed in the other version of the program. As for what 023
does when output, it selects I/O format 0 (integers), then 23
is a directive which requests the implementation to input an integer (in 7, you do input via outputting specific codes that request input). The input is done by making copies of the stack element below, e.g. if the input integer is 10, the next stack element (currently 7
) will become 7777777777
. Thus, we're accepting input from the user in decimal, but it's being stored as unary.
6
escapes the top stack element (changing each instance of 7
to 1
; this is how strings consisting entirely of 7
s are escaped), then appends it to the stack element before (772
). So our data is now something like 7721111111111
.
- Finally,
3
outputs the stack element in question (and pops a blank stack element that's part of the default initial stack). Its value is calculated by taking the number of 1
s and 7
s, and subtracting the number of 0
s and 6
s. (The 2
in the middle is ignored in most cases; if it's at the end of the string, it'll become a trailing newline instead of being ignored, but PPCG rules don't care about that.) Thus, the output is the original input plus 2.
At this point, there's nothing useful on the stack and nothing in the program, so the program exits.
How do we reverse this? It's a simple matter of changing the 11
to 00
, so that we're prepending characters to the input that make it 2 lower, rather than 2 higher. There's a 00
conveniently hidden eight octal digits further on in the program (so that octal digits and bytes line up with each other), so we can simply swap it with the 11
at the start.
Can we have imaginary/complex integers? – Stewie Griffin – 2017-01-16T16:18:45.177
@stewie if you indicate so you may – Post Rock Garf Hunter – 2017-01-16T16:20:34.113
1Is anagramming defined as permuting the characters, or permuting the bytes (in languages which don't use a single-byte character set)? – None – 2017-01-16T16:57:25.003
>
Does capitalisation matter? – user41805 – 2017-01-16T17:03:50.940
@ais523 permuting bytes – Post Rock Garf Hunter – 2017-01-16T17:23:14.030
@KritixiLithos To be anagrams the bytes should be the same. – Post Rock Garf Hunter – 2017-01-16T17:24:26.073
@KritixiLithos By default, yes.
– Martin Ender – 2017-01-16T17:43:58.693Is it a problem if
f(g(x))
is potentially not exactlyx
due to floating point rounding, or would that be considered violating the injective function requirement? – SLuck49 – 2017-01-18T14:08:28.010@SLuck49 I believe that it is a meta consensus that floating point errors in the final answer are fine. However if you are rounding on top of the floating point error (causing your answer to be wrong) I would consider that a violation of the requirements. – Post Rock Garf Hunter – 2017-01-18T14:12:13.043