4 ms·
Billions of Code Name Permutations in 32 bits
- kazinator 5y agoIf instead of this: static const char nouns[][12] = { "COPPERTONE", "JOCKEY", "TIMBERWOLF", "SAWHORSE", "PANDA", "SANDSTORM", where the 12 was calculated to fit the longest word, you can have pointers to string literal objects, and not have to do that: static const char *nouns[] = { "COPPERTONE", "JOCKEY", "TIMBERWOLF", "SAWHORSE", "PANDA", "SANDSTORM", unless we are counting cycles here and get touching about loading a pointer from a table (which would make little sense, given that we hand off these strings to sprintf). No code changes should be necessary elsewhere; I don't see any place that depends on nouns[x] being an array. Speaking of sprintf, I'd add a size argument and use snprintf, plus publish a recommended minimum size constant.
- rrauenza 5y agoI really want one of these to take a git sha1 and make a unique code name for continuous releases ... but I haven't wanted to take the time to make sure no particular word combos wouldn't be offensive. And 160 bits is quite a large domain, but I think occasional rare duplicates would be ok. Has anyone already solved this?
- sillysaurusx 5y agoI (ab)use gfycat. #!/bin/sh curl -s -X POST "https://api.gfycat.com/v1/gfycats" -H "Content-Type: application/json" | exec jq .gfyname -r It generates a name like HardDisastrousJaguar. Thus far, all other code name formats seem to suck -- e.g. they're 12 words, they don't start with adjectives and end with nouns, etc. So the trick is to map a specific continuous release back to a name like HardDisastrousJaguar. Any ol' database would do the trick. And the best database is the code release itself; you can throw the above code into your continuous release process to generate a unique name during the release. But, like you, I would love it if there was a way to map 160 bits to a name like HardDisastrousJaguar without relying on external services. Unfortunately, us nerds seem to get caught up on correctness ("There might be collisions! We need 12 words for 160 bits!") while losing sight of the fact that it's supposed to be for humans to read. HardDisastrousJaguar is memorable; <12 random english words> is better than 160 random bits, but it's a long way from HardDisastrousJaguar.
- collegeburner 5y agoThere's a bitcoin wordlist that can encode 2^11 bits per word, so 3 words could hold a 32-bit hash. You'd need a pretty large wordlist for 3 words to hold 128 bits.
- sillysaurusx 5y agoCollisions are fine. The point is to give it a memorable name, not to represent 128 bits. (It's the same reason a CRC is 32 bits.)
- adzm 5y agoDo you have a link or reference to this word list? Additionally with just 256 words you can easily do four words for 32 bits.
- deleted 5y ago[deleted]
- gruez 5y agohttps://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md https://github.com/bitcoin/bips/blob/master/bip-0039/bip-003...
- Zababa 5y agoI think it has been solved a good amount of time considering how frequent the list of adjectives and names are on "modern" websites. I don't know if any of these implementations is FOSS though.
- ay 5y agoJust an idea, even if it may not sound as cool: Why not use a number YYYY.mmm.dd.seq (seq being the ordinal number of the commit within a 24h UTC period starting at 00:00Z), and you would get something that is relatively easily parsed by humans (you can omit year/month when talking about recent releases), has a simple 1:1 mapping to the git commit, and has the added benefit of being easily sortable - if you zero-pad the numbers, it will become lexicographically sortable without losing much readability. This assumes you only release from one branch, of course.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]