算是接續昨天寫的「Redis 對 HyperLogLog 省空間的實作」，在 Redis 的 HyperLogLog 實作有提到 Google 在 2013 年的論文「HyperLogLog in Practice: Algorithmic Engineering of a State of The Art Cardinality Estimation Algorithm」，裡面提出了 HyperLogLog++ (HLL++)。
論文中 Google 提出來的改進主要有三個，第一個是用了 64-bit hash function：
5.1 Using a 64 Bit Hash Function
原因也有提到，當需要處理超過十億筆資料時，32-bit hash 的 4B 上限就有點不太夠用：
To fulfill the requirement of being able to estimate multisets of cardinalities beyond 1 billion, we use a 64 bit hash function.
這點也簡化了原始論文中當 cardinality 接近 232 時的 count 估算修正，因為實務上不太可能遇到 264 上限？
It would be possible to introduce a similar correction if the cardinality
approaches 264, but it seems unlikely that such cardinalities are encountered in practice.
第二個是改善 cardinality 比較低時的 count 估算公式：
5.2 Estimating Small Cardinalities
第三個則是提出了 sparse representation 的概念，在 cardinality 比較低的時候不需要直接用完整的 HLL 資料結構儲存：
5.3 Sparse Representation
另外也是一路往回讀的關係，查資料才了解 (ε, δ)-model 的用法，在「A Quick Introduction to Data Stream Algorithmics」這邊投影片的 Page 17 可以看到指的是，有多少正確性 (randomized) 是給出 ε 內的誤差 (approximation)，像是 Page 18 的範例：
Example: Actual answer is within 5 ± 1 with prob ≥ 0.9