We Are Mystified by Eric Holloway

[swamidass (S. Joshua Swamidass)]

@dga471

Again, this doesn’t make sense to me because the function itself is a very simple set of instructions which could be applied to copy anything.

I agree @dga471. It looks like an example of goal-post moving. Clearly a copy is a deterministic function. However, a deterministic function is not supposed to be able to increase MI. Yet it can. This gets back to some old questions I asked @EricMH that he never answered about the simulation: what are valid choices for X, Y, and E? He never answered.

Another very puzzling set of statements:

@EricMH

LZ only makes asymptotically optimal guarantees for ergodic sequences.

Compression is not possible except in ergodic sequences, period. Ergodic, however, is a strange term. Clearly all these big strings are compressible down to the random seed, so they are ergodic. They are just not ergodic in the way that LZ understands ergodic (key point!). We have to introduce some order into the sequences, which my first implementation did (by encoding as strings of 0 and 1) to get any compression from any algorithm. This gets to an interesting catch-22 that @EricMH falls into:

1. He wants compression to reduce the size of the random bit string.
2. He doesn’t want there to be any “computer perceivable” order in these bit strings.

These two requirements are not consistent. These are logically contradictory requirements. We have to pick one or the other, but we can’t have both. I actually produced an implementation that satisfied #1 but he complained about #2 not being satisfied. Then I produced an implementation that satisfied #2, and he complained about #1 not being satisfied. So which one is it @EricMH? Which of these two mutually contradictory requirements is how you want to run the simulation? You can’t have both. You have to choose. And no, I did not make an error. I’m just trying to follow these self-contradictory requirements.

@EricMH

That being said, this is not necessarily a ding against the GZip version. It can either be easily corrected by ensuring it doesn’t return decompressed values, as I did, or this issue can be acknowledged as a tradeoff for some other useful property the GZip version preserves.

This is in error. This hackish “fix” does not produce a compression algorithm by your definition. It creates instead a function where the compression function will almost always increase the size of the input by one bit. It is not a compression algorithm then, violating one of your requirements.

Moreover, his last experiment demonstrates another error in interpretation:

@EricMH

So, looks like the sequences must become rrrreeeeeaaaaaalllllyyyyy long for MI_LZ(Y:Y) > 0 if iid Y. I have a loglog plot of LZ(Y+Y)/len(Y+Y) for iid Y, and it looks like it won’t cross the X axis until Y’s length reaches 10^{12}.

Once again the claim is wrong, again. Actually it will never cross for copies of pseudorandom bit strings, and this is a problem because MI supposed to equal len(Y), no zero. H(Y+Y) is suppose to approach len(Y) not len(Y+Y). That will actually become less likely as the length increases. So it is both a false claim, and if it were true, that will still demonstrate the error in his implementation.

I do believe that @EricMH is an honest character here. However, it is hard to make progress when basic and demonstrable errors are being made over and over.