In ZPAQ I changed the range and precision of probabilities, stretched probabilities, and mixer weights because I found cases where it hurt compression in PAQ. The changes I make were as follows:

Probabilities. In PAQ they were 12 bits. In ZPAQ, 15 bits (odd multiples of 2^-16). This improved compression of highly redundant data.

Stretched probabilities. In PAQ they were 12 bits with 8 bits after the decimal point (-8 to 8 in steps of 1/256). In ZPAQ they were 12 bits with 6 bits after the decimal point (-32 to 32 in steps of 1/64). This improved compression when one model had a high degree of certainty. The extra 2 bits of precision did not seem to make any difference. Quantization errors in probability estimates tend to expand the data proportionally to the square of the error. A 1% error only expands the data by 0.01%.

Mixer weights. In PAQ they were 16 bits in the range 0 to 1. In ZPAQ they are 20 bits in the range -8 to 8 in steps of 2^-16. I wanted to keep them at 16 bits so I could implement mixers using SSE2 assembler like in PAQ, but cutting either the range or precision hurt compression. When I implemented JIT in ZPAQ, I was able to improve the speed of predict() using SSE2 but not update(). I wrote update() both ways and the scalar form was faster.