turbonss/deps/cmph/NEWSLOG.t2t

86 lines
3.8 KiB
Plaintext
Raw Normal View History

News Log
%!includeconf: CONFIG.t2t
2009-06-13 03:49:26 +03:00
----------------------------------------
2011-05-15 18:29:24 +03:00
==News for version 1.1==
Fixed a bug in the chd_pc algorithm and reorganized tests.
2010-09-10 02:28:20 +03:00
==News for version 1.0==
This is a bugfix only version, after which a revamp of the cmph code and
algorithms will be done.
----------------------------------------
2009-06-13 03:49:26 +03:00
==News for version 0.9==
- [The CHD algorithm chd.html], which is an algorithm that can be tuned to generate MPHFs that require approximately 2.07 bits per key to be stored. The algorithm outperforms [the BDZ algorithm bdz.html] and therefore is the fastest one available in the literature for sets that can be treated in internal memory.
- [The CHD_PH algorithm chd.html], which is an algorithm to generate PHFs with load factor up to //99 %//. It is actually the CHD algorithm without the ranking step. If we set the load factor to //81 %//, which is the maximum that can be obtained with [the BDZ algorithm bdz.html], the resulting functions can be stored in //1.40// bits per key. The space requirement increases with the load factor.
- All reported bugs and suggestions have been corrected and included as well.
2008-03-23 04:17:44 +02:00
----------------------------------------
==News for version 0.8==
2008-03-30 02:59:30 +02:00
- [An algorithm to generate MPHFs that require around 2.6 bits per key to be stored bdz.html], which is referred to as BDZ algorithm. The algorithm is the fastest one available in the literature for sets that can be treated in internal memory.
- [An algorithm to generate PHFs with range m = cn, for c > 1.22 bdz.html], which is referred to as BDZ_PH algorithm. It is actually the BDZ algorithm without the ranking step. The resulting functions can be stored in 1.95 bits per key for //c = 1.23// and are considerably faster than the MPHFs generated by the BDZ algorithm.
- An adapter to support a vector of struct as the source of keys has been added.
2008-03-30 02:59:30 +02:00
- An API to support the ability of packing a perfect hash function into a preallocated contiguous memory space. The computation of a packed function is still faster and can be easily mmapped.
2008-03-23 04:17:44 +02:00
- The hash functions djb2, fnv and sdbm were removed because they do not use random seeds and therefore are not useful for MPHFs algorithms.
- All reported bugs and suggestions have been corrected and included as well.
----------------------------------------
==News for version 0.7==
- Added man pages and a pkgconfig file.
----------------------------------------
==News for version 0.6==
- [An algorithm to generate MPHFs that require less than 4 bits per key to be stored fch.html], which is referred to as FCH algorithm. The algorithm is only efficient for small sets.
- The FCH algorithm is integrated with [BRZ algorithm brz.html] so that you will be able to efficiently generate space-efficient MPHFs for sets in the order of billion keys.
- All reported bugs and suggestions have been corrected and included as well.
----------------------------------------
==News for version 0.5==
- A thread safe vector adapter has been added.
- [A new algorithm for sets in the order of billion of keys that requires approximately 8.1 bits per key to store the resulting MPHFs. brz.html]
- All reported bugs and suggestions have been corrected and included as well.
----------------------------------------
==News for version 0.4==
- Vector Adapter has been added.
- An optimized version of bmz (bmz8) for small set of keys (at most 256 keys) has been added.
- All reported bugs and suggestions have been corrected and included as well.
----------------------------------------
==News for version 0.3==
- New heuristic added to the bmz algorithm permits to generate a mphf with only
//24.80n + O(1)// bytes. The resulting function can be stored in //3.72n// bytes.
%html% [click here bmz.html#heuristic] for details.
%!include: ALGORITHMS.t2t
%!include: FOOTER.t2t
2009-06-13 03:49:26 +03:00
2010-09-10 02:28:20 +03:00
%!include(html): ''GOOGLEANALYTICS.t2t''