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 swi

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: - + + - 000 001 010 011 100 101 110 111 0 1 1 0 1 0 0 1 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. Data: 011101101010100100010100100010111001010100110000101011101101110 0 1 0 1 1 1 1 0 0 0 0 0 1 0 1 1 1 0 0 0 0 1 0 0 1 1 1 1 1 0 1 0 0 0 1 1 0 1 1 0 1 1 0 1 1 0 0 0 0 0 0 1 111010111010100101000101011110100011011011010001111011110101001 1 1 1 1 1 1 1 0 0 0 0 0 0 1 1 1 0 1 0 1 1 0 0 0 1 1 1 1 0 0 0 1 1 1 1 1 0 0 1 0 1 1 0 0 0 1 0 1 0 1 0 0 101110100101101010110101010001101101010010110111010110101001110 1 1 1 1 0 0 1 1 1 1 0 0 0 0 0 1 1 0 0 0 1 1 0 1 0 0 1 1 1 0 1 0 0 1 0 0 1 0 0 1 1 0 0 1 1 0 1 1 0 0 1 0