Gorilla Compression Ratio Calculation Audit
Gorilla Compression Ratio Calculation Audit
Ada re-derives this chapter’s own numbers step by step, at full precision
ADA · CALCULATION AUDIT
Gorilla Compression Ratio Calculation Audit
The chapter compresses a time series two ways: Gorilla squeezes a 16-byte point to about 1.37 bytes — a lossless 12x — while a lossy FFT turns an 8,000 B/s vibration stream into peaks for a 50x-plus cut that cannot be rebuilt. A ratio is only trustworthy after you divide the real numbers and note what survives. This audit works the Gorilla compression ratio against the FFT to show why the ratio must be read alongside reconstruction.
Companion to the chapter Time-Series Compression Audit Limits — every number here comes from that chapter.
A compression ratio is only trustworthy after you divide the real numbers. Gorilla's 12× is lossless; the FFT's 50× is not — and that gap is the whole audit-fidelity story.
See the relationship before changing it
The figure reads from left to right. The blue card is compressed bytes per point. The middle card applies this page's rule. The green card is lossless compression ratio. Walk the arrows once: set the input, apply the rule, then read the result with its unit.
The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only compressed bytes per point, so the numeric fixture does not switch without explanation.
Derive the baseline in four named moves
- 1
Name the input. The chapter baseline is 1.37 bytes.
- 2
Name the relationship. ratio = 16 original bytes / compressed bytes
- 3
Substitute with units. 16 / 1.37 = 11.68 times
- 4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.
Predict, then change compressed bytes per point
Try Predict the direction of ratio = 16 original bytes / compressed bytes. Test another compressed bytes per point, then compare lossless compression ratio.
Observe Fewer compressed bytes per point raise the lossless ratio while exact reconstruction remains required. Reset compressed bytes per point to 1.37 and compare lossless compression ratio.
Explain Fewer compressed bytes per point raise the lossless ratio while exact reconstruction remains required.
Check yourself
What should you do before trusting a moved-control result?
What does this small model leave out?
1. One raw point is 16 bytes.
A 64-bit timestamp plus a 64-bit double. Gorilla averages 1.37 bytes per point on production data, so:
2. Scale it to one hour at 1 Hz.
3600 points × 16 B = 57,600 B raw; 3600 × 1.37 = 4,932 B compressed. That saves 57,600 − 4,932 = 52,668 B, or 91.4% — and every value still reconstructs exactly.
3. Lossy FFT trades reconstruction for a bigger cut.
A 4 kHz, 2-byte vibration stream is 4000 × 2 = 8,000 B/s. Ten spectral bins at roughly 12–16 bytes each ≈ 120–160 B/s, so 8000 ÷ 160 = 50× up to 8000 ÷ 120 = 67× — but the waveform cannot be rebuilt from peaks.
| Method | Arithmetic | Result | Reconstruction |
|---|---|---|---|
| Gorilla (per point) | 16 ÷ 1.37 | 11.68× ≈ 12× | Exact |
| Gorilla (per hour) | 57,600 → 4,932 B | 91.4% saved | Exact |
| FFT peaks (per second) | 8000 → 120–160 B | 50–67× | Lossy |
What the audit buys you: the 12× Gorilla number and the 50× FFT number are not competitors — one keeps every bit for the compliance log, the other discards the waveform for a trend chart, so the ratio must always be read alongside the reconstruction column or you will size the wrong pipe for an audit-grade record.
The ratio model deliberately does not simulate the distribution-dependent spread around Gorilla's 1.37-byte average, index overhead, query cost, CPU energy, or FFT reconstruction error; it compares the chapter's representative point sizes only.
Work the audit first, then check the displayed derivation.
Every number above is taken from the chapter’s own examples and re-derived step by step.