More evaluation cases

[Dieterbe]

I will rebase this branch once #8 is merged, to get the better location for the test data, but that's just a code detail and doesn't hold back from sharing these results. I wanted to share these results and invite @dgryski and @woodsaj and @nopzor to have a closer look

here's my updated conclusions:

• high compression seems only achievable in special cases like equal values, lack of decimals. In "real, noisy" float scenarios, compression is marginal.
• equal values compress very well, and it doesn't seem to matter what the actual value is.
• rounding down to limit the number of decimals can help a little bit, but rounding to 0 decimals can help a lot, especially for small numbers, the gain can be 6x.
• for large numbers however, rounding down the decimals doesn't seem to help at all.
• numbers that don't compress well, will get no benefit of larger chunks. numbers that compress well do benefit from larger chunks, multiplying their gains.
• chunk size only matters for values that compress well, and there, around 120 points seems like the sweet spot (like the paper said).
• mixed signs (+-) add a 10x overhead, but this disappears as soon as we limit the number of decimals

screenshot of output:

[Dieterbe]

also 0 ~1000 [inf] means that in theory the number could go up to inf, but in practice they stay low, between 0 and 1000

[Dieterbe]

rebased against latest master. will merge soon unless someone objects.

[dgryski]

LGTM. Go ahead and merge.