{"action":"closed","issue":{"url":"https://api.github.com/repos/dib-lab/khmer/issues/1490","repository_url":"https://api.github.com/repos/dib-lab/khmer","labels_url":"https://api.github.com/repos/dib-lab/khmer/issues/1490/labels{/name}","comments_url":"https://api.github.com/repos/dib-lab/khmer/issues/1490/comments","events_url":"https://api.github.com/repos/dib-lab/khmer/issues/1490/events","html_url":"https://github.com/dib-lab/khmer/issues/1490","id":184238476,"number":1490,"title":"Irreversible hashing for k>32","user":{"login":"betatim","id":1448859,"avatar_url":"https://avatars.githubusercontent.com/u/1448859?v=3","gravatar_id":"","url":"https://api.github.com/users/betatim","html_url":"https://github.com/betatim","followers_url":"https://api.github.com/users/betatim/followers","following_url":"https://api.github.com/users/betatim/following{/other_user}","gists_url":"https://api.github.com/users/betatim/gists{/gist_id}","starred_url":"https://api.github.com/users/betatim/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/betatim/subscriptions","organizations_url":"https://api.github.com/users/betatim/orgs","repos_url":"https://api.github.com/users/betatim/repos","events_url":"https://api.github.com/users/betatim/events{/privacy}","received_events_url":"https://api.github.com/users/betatim/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-10-20T14:02:40Z","updated_at":"2016-11-17T12:26:56Z","closed_at":"2016-11-17T12:26:56Z","body":"(This is related to #1441)\n\nWhat would it take to support `k`>32 without insisting on reversibility? Thats the question.\n\nWe need to use a hash function that \"mixes\" things to avoid `XXXACGT` and `YYYYACGT` giving the same value (for a 8bit hash value). This means we need to somehow detect that we are in \"irreversible mode\".\n\nWe tell `_hash()` what `k` is, so you could make it use a different hash function/scheme for `k>32` that still returns a `uint64`. `_revhash` would either raise an exception or return “something” when called with k>32. Currently `StringToHashIterator` is annoying because it has to know about what `_hash` does in order to do its clever thing with the sliding window. [Here](https://github.com/lemire/rollinghashcpp/blob/master/example3.cpp) this is solved by having a hash function object that allows you to \"roll\" one character left/right. We could add a similar abstraction so that the knowledge of the hash function isn't inside `StringToHashIterator` but instead where the hash function is defined (that would make me happy). Could be as simple as providing a `roll_hash_left/_right(current_hash_value, remove, add)` function.\n#1437 shows how to split things into \"needs string\" and \"only needs hashes\" iteration and contains `StringToHashIterator`.\n"}}
{"actor":{"display_login":"betatim"}}