Cool! Makes sense, too— it feels unrandom to sit there hitting one key a bunch. How do you know when to stop?
So here's what I got: figure I have a bias to switch keys. That means that 01 and 10 are more common than 11 and 00. So what I need to do is group 01 with 00, and 10 with 11. What I do is generate twice as many bits as I need, treat the string as a sequence of two-bit pairs, and reduce each one to its first bit.
That looks like this: 01011110000010111000010011111011111111000000111010110001111000111100111100001100011010011101
Gets you past the litmus test, but looks like it goes too far the other way? Hard for me to tell, actually.
Another thing would be something like a sequential xor of each bit in triples (i.e. 010 -> (0 ^ 1) ^ 0 = 1), which segments triples across probability like so:
You can do that quickly by counting the 1s— 1 or 3 is 1, 0 or 2 is 0.
That looks like this:
00011011011011000000111111001011000101010000100100110011011010
I don't know if it adds much more (apparent) entropy, though.
So here's what I got: figure I have a bias to switch keys. That means that 01 and 10 are more common than 11 and 00. So what I need to do is group 01 with 00, and 10 with 11. What I do is generate twice as many bits as I need, treat the string as a sequence of two-bit pairs, and reduce each one to its first bit. That looks like this: 01011110000010111000010011111011111111000000111010110001111000111100111100001100011010011101
Gets you past the litmus test, but looks like it goes too far the other way? Hard for me to tell, actually.
Another thing would be something like a sequential xor of each bit in triples (i.e. 010 -> (0 ^ 1) ^ 0 = 1), which segments triples across probability like so:
You can do that quickly by counting the 1s— 1 or 3 is 1, 0 or 2 is 0. That looks like this: 00011011011011000000111111001011000101010000100100110011011010I don't know if it adds much more (apparent) entropy, though.
Data: