3 ms·
Note that "the first X characters" is kind of misleading, because it is usually more fine grained. It is better (and IMHO even simpler!) to think of the hash a
by vog 9y ago
Note that "the first X characters" is kind of misleading, because it is usually more fine grained.
It is better (and IMHO even simpler!) to think of the hash as a large integer, not a string. Then you want that integer to be smaller than a certain value.
With strings, you can only say: "00123" shall start with "00", while wih integers, you would say: 00123 shall be smaller than 300.
(To be that fine grained with strings, you would either need multiple prefixes ("000", "001", "002") regexes ("00[012]"), both more hassle than a simple less-than operation.)
- jstanley 9y agoI agree with the gist, but note that even with strings, "00122" is less than "00200" :)
- vog 9y agoOh, you are right! However, my point still stands that this is not about prefixes, but about a less-than comparison.
- SomeStupidPoint 9y agoYou can implement 0 prefix checking pretty easily in bitstrings: 0 == hash >> (hash_length - prefix_length) Or, alternatively: !(hash & prefix_mask) where `prefix_mask` is 1111..000, with `prefix_length` number of 1s. I think that working in terms of bitstrings generated by the hash gives more context to why those integers are chosen (that they represent a certain portion of the space of possible answers), but it's also a matter of taste/background.
- vog 9y agoThis is still more combersome yet less precise than a straight greater-than check.