My guess is that all the individual characters of Hello World are found inside the 0xC894 number. Every 4 bits of x shows where in this number we can find the characters for Hello World.
You can read x right to left. (Skip the rightmost 0 as it’s immediately bit shifted away in first iteration)
3 becomes H
2 becomes e
1 becomes l
5 becomes o
etc.
I guess when we’ve exhausted all bits of x only 0 will be remaining for one final iteration, which translates to !
Too readable. You’ve gotta encode the characters as the solutions of a polynomial over a finite field, implemented with linear feedback on the bit shifts. /s
32 is ASCII space, the highest number you need is 114 for r (or 122 for z if you want to be generic), that’s a range of 82 or 90 values.
The target string has 13 characters, a long long has 8 bytes or 16 nibbles – 13 fits into 16 so nibbles (the (x >>= 4) & 15) it is. Also the initial x happens to have 13 nibbles in it so that makes sense. But a nibble only has 16 values, not 82, so you need some kind of compression and that’s the rest of the math, no idea how it was derived.
If I were to write that thing I’d throw PAQ at it it can probably spit out an arithmetic coding that works, and look even more arcane as you wouldn’t have the obvious nibble steps. Or, wait, throw NEAT at it: Train it to, given a specific initial seed, produce a second seed and a character, score by edit distance. The problem space is small enough for the approach to be feasible even though it’s actually a terrible use of the technique, but using evolution will produce something that’s utterly, utterly inscrutable.
Umm… someone explain this code please?
Bit shift magic.
My guess is that all the individual characters of Hello World are found inside the 0xC894 number. Every 4 bits of
xshows where in this number we can find the characters for Hello World.You can read x right to left. (Skip the rightmost 0 as it’s immediately bit shifted away in first iteration)
3 becomes H 2 becomes e 1 becomes l 5 becomes o
etc.
I guess when we’ve exhausted all bits of x only 0 will be remaining for one final iteration, which translates to !
Too readable. You’ve gotta encode the characters as the solutions of a polynomial over a finite field, implemented with linear feedback on the bit shifts. /s
I understand that the characters are probably encoded into that number, but I’m struggling to understand that C/C++ code.
32 is ASCII space, the highest number you need is 114 for r (or 122 for z if you want to be generic), that’s a range of 82 or 90 values.
The target string has 13 characters, a long long has 8 bytes or 16 nibbles – 13 fits into 16 so nibbles (the
(x >>= 4) & 15) it is. Also the initial x happens to have 13 nibbles in it so that makes sense. But a nibble only has 16 values, not 82, so you need some kind of compression and that’s the rest of the math, no idea how it was derived.If I were to write that thing I’d throw PAQ at it it can probably spit out an arithmetic coding that works, and look even more arcane as you wouldn’t have the obvious nibble steps. Or, wait, throw NEAT at it: Train it to, given a specific initial seed, produce a second seed and a character, score by edit distance. The problem space is small enough for the approach to be feasible even though it’s actually a terrible use of the technique, but using evolution will produce something that’s utterly, utterly inscrutable.