Unfortunately, RKMH has created a bunch of new requirements since the initial bits of this library came into existence. There is a lot of duplicated functionality and some spaghetti coding (functions call functions that call functions....). The total test coverage has also dropped from ~80% to more like 8%. I think it's useful to have both string and char* implementations, so I'd like to have everything duplicated to some degree, but I'd also like to clean things up:

1. Maintain a single hash function wrapper - right now there are a bunch of places in the code that MurmurHash3_x64_128 gets called, and there should really be only one to ensure consistency.
2. New requirement: set hash seed from CLI
3. New requirement: set hash bits (32, 64) from CLI.
4. New requirement: allow setting the alphabet (which means extending to amino acids).
5. Remove top_minhash and bottom_minhash helper functions, because they are silly convenience functions that are actually less convenient.
6. Increase test coverage toward 100%, perhaps using catch.hpp

Writing this down here so I can remember it one day, when I've submitted my thesis...

Right now we have an API for hashing kmers (calc_hash(**)) and reads (calc_hashes(**)). However, these have fixed hash functions (currently MurmerHash64). Ideally, it would be easier if we could drop in new hash functions using a common API rather than the spaghetti code / infinite-if-elif-elses the design currently uses.

I'm imagining a function that takes a string, a start position, an end position, and a std::function that wraps a given hash function with the necessary parameters. The signature might look something like:

mkmh::hash_t calc_hash(char* seq, const size_t& start, const size_t& end, std::function<mkmh::hash_t(char*, int, int, int)>& hashfunc)

where hashfunc is a wrapper around a hash function that might look like:

mkmh::hash_t murmurhash64(const char* seq, int offset, int end, int seed);

It's a little strange passing a nearly identical function to another one, but it means we could use multiple hash functions within mkmh without modifying the API (or even adding to the source code).

I've made a lot of improvements to the pliib, which holds a lot of the utility functions for strings used in mkmh. At some point, I'd like to refactor mkmh to rely on pliib, rather than carrying multiple versions of the same functions around. This will mean users will have to install pliib (which is also a single-header lib), but it should make the process of updating string manipulation functions a lot easier.

MurmurHash, while relatively fast / dispersive / backwards compatible with Mash, is slower than some newer algorithms. Moving to xxHash should yield a ~2X speed improvement in the hashing portions of the code, and ntHash should go even faster.