Checking the collision \
lexp.lt
# Why? In a work related context, I had to create a hash algorithm working on a finite set of values ([0, 0xFFFFFFFF]) to output a non sequential serie from a sequential one (the output had to be rendered as a UUID. Basically, I wanted to avoid generating UUID looking like 00000000-0000-0000-0000-000000000001, that will definitely appear to be sequential and easily abused to find other IDs. # The transformation Previously I called it a hash, it’s more like a map function (or transform function for my C++ folks), operating on [0, 0xFFFFFFFF] -> [0, 0xFFFFFFFF] where the sequential aspect is lost.

I had some fun trying to check if a hash (more like a transformation really) was collision free, so I wrote a quick piece code and then iterated on it so that it was usable.

I might add a quick bench and graphs and try to push it even further just for fun, to explore std::future a bit more (though the shared bit set might be a problem unless you put a shared condition variable on it to allow concurrent read but block concurrent writes?)

  • sajran
    2·
    1 month ago

    I like the problem solving description, I actually went through a similar learning process leading to bitset recently. It was very satisfying!

    However, I just have to ask a question: What is the reason you didn’t just use UUID?

    • SuperFola@programming.devOPEnglish
      2·
      1 month ago

      Thanks!

      It would have been a lot easier to generate a fresh UUID for every record, but that means storing it. And we would have a unique sequential id alongside a unique UUID, two different keys for the exact same data. It is doable, afterall it’s just an additional 128bits for every record, but for the sake of it I wanted to not store an additional ID and be able to compute the UUID on the fly from the base sequential ID.

      • sajran
        1·
        1 month ago

        Ah, I didn’t think about this. Thanks for the explanation!