Efficient way of generating a random number of N (less than 64) bits with exactly M bits equal to oneGenerating unsigned, bounded random value using signed bounded random valuesIs deniable error-correction possible?What is the most computationally efficient way of generating pseudo-random permutations?Has there been any research on entropy efficient information-theoretically secure PRNGs?Secure entropy extractor for thermal noise collected from camera input?Generating DH key with specific bit-lengthRSA-KEM: minimal number of random bitsRandomizing Prime Field Elements

Does C++20 mandate source code being stored in files?

Don't understand MOSFET as amplifier

Are there any plans for handling people floating away during an EVA?

Why doesn't the Falcon-9 first stage use three legs to land?

In an emergency, how do I find and share my position?

How to organize ideas to start writing a novel?

How can I support the recycling, but not the new production of aluminum?

Shouldn't the "credit score" prevent Americans from going deeper and deeper into personal debt?

Why didn’t Doctor Strange stay in the original winning timeline?

Is it safe to remove the bottom chords of a series of garage roof trusses?

Why is Boris Johnson visiting only Paris & Berlin if every member of the EU needs to agree on a withdrawal deal?

Is refusing to concede in the face of an unstoppable Nexus combo punishable?

What is the evidence on the danger of feeding whole blueberries and grapes to infants and toddlers?

(Why) May a Beit Din refuse to bury a body in order to coerce a man into giving a divorce?

Turn TDE off when restoring SQL databases

The sound of thunder's like a whip

Why were movies shot on film shot at 24 frames per second?

Is "stainless" a bulk or a surface property of stainless steel?

How to specify and fit a hybrid machine learning - linear model

Ask for a paid taxi in order to arrive as early as possible for an interview within the city

Are there nouns that change meaning based on gender?

Does adding the 'precise' tag to daggers break anything?

Is it appropriate for a prospective landlord to ask me for my credit report?

How should I think about joining a company whose business I do not understand?



Efficient way of generating a random number of N (less than 64) bits with exactly M bits equal to one


Generating unsigned, bounded random value using signed bounded random valuesIs deniable error-correction possible?What is the most computationally efficient way of generating pseudo-random permutations?Has there been any research on entropy efficient information-theoretically secure PRNGs?Secure entropy extractor for thermal noise collected from camera input?Generating DH key with specific bit-lengthRSA-KEM: minimal number of random bitsRandomizing Prime Field Elements






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1












$begingroup$


Would there be an efficient way to implement a function with the following signature:



unsigned long long int random_word(size_t n, size_t m)


that would generate a random machine word (64 bits here) such that exactly m bits over the n least significant ones at set to 1. For example: random_word(10, 3) would generate a 64-bit random number such that 3 bits over the 10 LSBs are set to 1. For a given n and m every possible output should have equal probability (uniform distribution of possible permutations).



If assembly bit twiddling hacks to do that are known, great, if not, I am looking for references and research directions.










share|improve this question







New contributor



Vincent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






$endgroup$













  • $begingroup$
    If the percentage of samples that match the requirement from the full range of numbers isn't too small, then rejection sampling should work (only needs to be done on those n bits, the prefix can be randomized once and then you rejection sample the n bits)
    $endgroup$
    – Natanael
    8 hours ago







  • 5




    $begingroup$
    Seems more like a programming challenge than crypto-related. Define "efficient":. Code size? Minimal number of uniformlly random bit used? Is that on average, for the first call, or..? Speed: for the first call, for a million calls with the same n,m..? Is the time to generate uniform random bits counted in the performance?
    $endgroup$
    – fgrieu
    8 hours ago











  • $begingroup$
    Why do you need this in cryptography?
    $endgroup$
    – Conrado
    8 hours ago






  • 1




    $begingroup$
    There's actually a second way that's likely more efficient (at least when m is far from n/2). Generate 64 minus n bits of random bits for the prefix, then simply generate a bitstring of m 1's and n-m 0's, and then you perform a randomized bitwise sort (with some random sort algorithms with a sufficiently small bias, using a unique random seed), and concatenate the two strings.
    $endgroup$
    – Natanael
    8 hours ago











  • $begingroup$
    I don't get your sort. But if you just randomize the positions of the ones or zeros in the n LSB bits, and let the rest consist of random bits, then that should not introduce any bias, right?
    $endgroup$
    – Maarten Bodewes
    7 hours ago

















1












$begingroup$


Would there be an efficient way to implement a function with the following signature:



unsigned long long int random_word(size_t n, size_t m)


that would generate a random machine word (64 bits here) such that exactly m bits over the n least significant ones at set to 1. For example: random_word(10, 3) would generate a 64-bit random number such that 3 bits over the 10 LSBs are set to 1. For a given n and m every possible output should have equal probability (uniform distribution of possible permutations).



If assembly bit twiddling hacks to do that are known, great, if not, I am looking for references and research directions.










share|improve this question







New contributor



Vincent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






$endgroup$













  • $begingroup$
    If the percentage of samples that match the requirement from the full range of numbers isn't too small, then rejection sampling should work (only needs to be done on those n bits, the prefix can be randomized once and then you rejection sample the n bits)
    $endgroup$
    – Natanael
    8 hours ago







  • 5




    $begingroup$
    Seems more like a programming challenge than crypto-related. Define "efficient":. Code size? Minimal number of uniformlly random bit used? Is that on average, for the first call, or..? Speed: for the first call, for a million calls with the same n,m..? Is the time to generate uniform random bits counted in the performance?
    $endgroup$
    – fgrieu
    8 hours ago











  • $begingroup$
    Why do you need this in cryptography?
    $endgroup$
    – Conrado
    8 hours ago






  • 1




    $begingroup$
    There's actually a second way that's likely more efficient (at least when m is far from n/2). Generate 64 minus n bits of random bits for the prefix, then simply generate a bitstring of m 1's and n-m 0's, and then you perform a randomized bitwise sort (with some random sort algorithms with a sufficiently small bias, using a unique random seed), and concatenate the two strings.
    $endgroup$
    – Natanael
    8 hours ago











  • $begingroup$
    I don't get your sort. But if you just randomize the positions of the ones or zeros in the n LSB bits, and let the rest consist of random bits, then that should not introduce any bias, right?
    $endgroup$
    – Maarten Bodewes
    7 hours ago













1












1








1





$begingroup$


Would there be an efficient way to implement a function with the following signature:



unsigned long long int random_word(size_t n, size_t m)


that would generate a random machine word (64 bits here) such that exactly m bits over the n least significant ones at set to 1. For example: random_word(10, 3) would generate a 64-bit random number such that 3 bits over the 10 LSBs are set to 1. For a given n and m every possible output should have equal probability (uniform distribution of possible permutations).



If assembly bit twiddling hacks to do that are known, great, if not, I am looking for references and research directions.










share|improve this question







New contributor



Vincent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






$endgroup$




Would there be an efficient way to implement a function with the following signature:



unsigned long long int random_word(size_t n, size_t m)


that would generate a random machine word (64 bits here) such that exactly m bits over the n least significant ones at set to 1. For example: random_word(10, 3) would generate a 64-bit random number such that 3 bits over the 10 LSBs are set to 1. For a given n and m every possible output should have equal probability (uniform distribution of possible permutations).



If assembly bit twiddling hacks to do that are known, great, if not, I am looking for references and research directions.







algorithm-design random-number-generator implementation randomness pseudo-random-permutation






share|improve this question







New contributor



Vincent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










share|improve this question







New contributor



Vincent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








share|improve this question




share|improve this question






New contributor



Vincent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








asked 8 hours ago









VincentVincent

1062 bronze badges




1062 bronze badges




New contributor



Vincent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




New contributor




Vincent is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • $begingroup$
    If the percentage of samples that match the requirement from the full range of numbers isn't too small, then rejection sampling should work (only needs to be done on those n bits, the prefix can be randomized once and then you rejection sample the n bits)
    $endgroup$
    – Natanael
    8 hours ago







  • 5




    $begingroup$
    Seems more like a programming challenge than crypto-related. Define "efficient":. Code size? Minimal number of uniformlly random bit used? Is that on average, for the first call, or..? Speed: for the first call, for a million calls with the same n,m..? Is the time to generate uniform random bits counted in the performance?
    $endgroup$
    – fgrieu
    8 hours ago











  • $begingroup$
    Why do you need this in cryptography?
    $endgroup$
    – Conrado
    8 hours ago






  • 1




    $begingroup$
    There's actually a second way that's likely more efficient (at least when m is far from n/2). Generate 64 minus n bits of random bits for the prefix, then simply generate a bitstring of m 1's and n-m 0's, and then you perform a randomized bitwise sort (with some random sort algorithms with a sufficiently small bias, using a unique random seed), and concatenate the two strings.
    $endgroup$
    – Natanael
    8 hours ago











  • $begingroup$
    I don't get your sort. But if you just randomize the positions of the ones or zeros in the n LSB bits, and let the rest consist of random bits, then that should not introduce any bias, right?
    $endgroup$
    – Maarten Bodewes
    7 hours ago
















  • $begingroup$
    If the percentage of samples that match the requirement from the full range of numbers isn't too small, then rejection sampling should work (only needs to be done on those n bits, the prefix can be randomized once and then you rejection sample the n bits)
    $endgroup$
    – Natanael
    8 hours ago







  • 5




    $begingroup$
    Seems more like a programming challenge than crypto-related. Define "efficient":. Code size? Minimal number of uniformlly random bit used? Is that on average, for the first call, or..? Speed: for the first call, for a million calls with the same n,m..? Is the time to generate uniform random bits counted in the performance?
    $endgroup$
    – fgrieu
    8 hours ago











  • $begingroup$
    Why do you need this in cryptography?
    $endgroup$
    – Conrado
    8 hours ago






  • 1




    $begingroup$
    There's actually a second way that's likely more efficient (at least when m is far from n/2). Generate 64 minus n bits of random bits for the prefix, then simply generate a bitstring of m 1's and n-m 0's, and then you perform a randomized bitwise sort (with some random sort algorithms with a sufficiently small bias, using a unique random seed), and concatenate the two strings.
    $endgroup$
    – Natanael
    8 hours ago











  • $begingroup$
    I don't get your sort. But if you just randomize the positions of the ones or zeros in the n LSB bits, and let the rest consist of random bits, then that should not introduce any bias, right?
    $endgroup$
    – Maarten Bodewes
    7 hours ago















$begingroup$
If the percentage of samples that match the requirement from the full range of numbers isn't too small, then rejection sampling should work (only needs to be done on those n bits, the prefix can be randomized once and then you rejection sample the n bits)
$endgroup$
– Natanael
8 hours ago





$begingroup$
If the percentage of samples that match the requirement from the full range of numbers isn't too small, then rejection sampling should work (only needs to be done on those n bits, the prefix can be randomized once and then you rejection sample the n bits)
$endgroup$
– Natanael
8 hours ago





5




5




$begingroup$
Seems more like a programming challenge than crypto-related. Define "efficient":. Code size? Minimal number of uniformlly random bit used? Is that on average, for the first call, or..? Speed: for the first call, for a million calls with the same n,m..? Is the time to generate uniform random bits counted in the performance?
$endgroup$
– fgrieu
8 hours ago





$begingroup$
Seems more like a programming challenge than crypto-related. Define "efficient":. Code size? Minimal number of uniformlly random bit used? Is that on average, for the first call, or..? Speed: for the first call, for a million calls with the same n,m..? Is the time to generate uniform random bits counted in the performance?
$endgroup$
– fgrieu
8 hours ago













$begingroup$
Why do you need this in cryptography?
$endgroup$
– Conrado
8 hours ago




$begingroup$
Why do you need this in cryptography?
$endgroup$
– Conrado
8 hours ago




1




1




$begingroup$
There's actually a second way that's likely more efficient (at least when m is far from n/2). Generate 64 minus n bits of random bits for the prefix, then simply generate a bitstring of m 1's and n-m 0's, and then you perform a randomized bitwise sort (with some random sort algorithms with a sufficiently small bias, using a unique random seed), and concatenate the two strings.
$endgroup$
– Natanael
8 hours ago





$begingroup$
There's actually a second way that's likely more efficient (at least when m is far from n/2). Generate 64 minus n bits of random bits for the prefix, then simply generate a bitstring of m 1's and n-m 0's, and then you perform a randomized bitwise sort (with some random sort algorithms with a sufficiently small bias, using a unique random seed), and concatenate the two strings.
$endgroup$
– Natanael
8 hours ago













$begingroup$
I don't get your sort. But if you just randomize the positions of the ones or zeros in the n LSB bits, and let the rest consist of random bits, then that should not introduce any bias, right?
$endgroup$
– Maarten Bodewes
7 hours ago




$begingroup$
I don't get your sort. But if you just randomize the positions of the ones or zeros in the n LSB bits, and let the rest consist of random bits, then that should not introduce any bias, right?
$endgroup$
– Maarten Bodewes
7 hours ago










2 Answers
2






active

oldest

votes


















2












$begingroup$

I'd guess that you can simply split this into two problems:



  1. create 64 - n random bits, call this R

  2. shuffle n bits where m bits (at any location) are set to 1, call this P

Finally you can simply perform R | P (presuming big endian notation).



Shuffling lists of elements is an operation present in almost any language. If there is any inefficiency it would be in the shuffling algorithm (although Fisher-Yates is optimal, so you'd expect some form of that algorithm, possibly the inefficiency is getting values in a range...).






share|improve this answer











$endgroup$














  • $begingroup$
    I'm thinking that you could also just generate a value x within of 0..n - i where i goes from 0 to m, where you set the x'th bit that is not set. That would be equivalent and easier to implement.
    $endgroup$
    – Maarten Bodewes
    4 hours ago


















1












$begingroup$



The problem for choosing $k$ bits from $64$ ultimately comes down to computing a uniformly random integer $r$ with $0 leq r < frac64!k!(64-k)!$ then decoding it to determine which bits. The $k!$ in the denominator is annoying, but we can ignore it, because we can just allow our algorithm to have $k!$ random numbers that map to the same output (setting bit 0 then bit 4 is the same as setting bit 4 then bit 0). Now we just have multiplying a decreasing sequence starting from $64$: with $k=4$ this equals $64 * 63 * 62 * 61$.



So for efficiency, you select a random number in $0 le r_0 < 64$, then another $0 le r_1 < 63$ ... through $0 le r_k-1 < 64-(k-1)$ each time using $r_n$ to select among the remaining unset bits.



I threw the following Python code together showing the idea, though it's not fast or anything:



# b = size of integer type
# n = number of set bits
# random_limited(x) is some function returning [0, x) sufficiently uniformly
def random_n_set_bits(b, n):
assert b > 0
assert n >= 0 and n <= b
result = 0
available = list(range(b))
for i in range(n):
index = random_limited(len(available))
bit = available[index]
available = available[:index] + available[index + 1:]
result |= (1 << bit)
return result





share|improve this answer











$endgroup$

















    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "281"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );






    Vincent is a new contributor. Be nice, and check out our Code of Conduct.









    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f72722%2fefficient-way-of-generating-a-random-number-of-n-less-than-64-bits-with-exactl%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2












    $begingroup$

    I'd guess that you can simply split this into two problems:



    1. create 64 - n random bits, call this R

    2. shuffle n bits where m bits (at any location) are set to 1, call this P

    Finally you can simply perform R | P (presuming big endian notation).



    Shuffling lists of elements is an operation present in almost any language. If there is any inefficiency it would be in the shuffling algorithm (although Fisher-Yates is optimal, so you'd expect some form of that algorithm, possibly the inefficiency is getting values in a range...).






    share|improve this answer











    $endgroup$














    • $begingroup$
      I'm thinking that you could also just generate a value x within of 0..n - i where i goes from 0 to m, where you set the x'th bit that is not set. That would be equivalent and easier to implement.
      $endgroup$
      – Maarten Bodewes
      4 hours ago















    2












    $begingroup$

    I'd guess that you can simply split this into two problems:



    1. create 64 - n random bits, call this R

    2. shuffle n bits where m bits (at any location) are set to 1, call this P

    Finally you can simply perform R | P (presuming big endian notation).



    Shuffling lists of elements is an operation present in almost any language. If there is any inefficiency it would be in the shuffling algorithm (although Fisher-Yates is optimal, so you'd expect some form of that algorithm, possibly the inefficiency is getting values in a range...).






    share|improve this answer











    $endgroup$














    • $begingroup$
      I'm thinking that you could also just generate a value x within of 0..n - i where i goes from 0 to m, where you set the x'th bit that is not set. That would be equivalent and easier to implement.
      $endgroup$
      – Maarten Bodewes
      4 hours ago













    2












    2








    2





    $begingroup$

    I'd guess that you can simply split this into two problems:



    1. create 64 - n random bits, call this R

    2. shuffle n bits where m bits (at any location) are set to 1, call this P

    Finally you can simply perform R | P (presuming big endian notation).



    Shuffling lists of elements is an operation present in almost any language. If there is any inefficiency it would be in the shuffling algorithm (although Fisher-Yates is optimal, so you'd expect some form of that algorithm, possibly the inefficiency is getting values in a range...).






    share|improve this answer











    $endgroup$



    I'd guess that you can simply split this into two problems:



    1. create 64 - n random bits, call this R

    2. shuffle n bits where m bits (at any location) are set to 1, call this P

    Finally you can simply perform R | P (presuming big endian notation).



    Shuffling lists of elements is an operation present in almost any language. If there is any inefficiency it would be in the shuffling algorithm (although Fisher-Yates is optimal, so you'd expect some form of that algorithm, possibly the inefficiency is getting values in a range...).







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 5 hours ago

























    answered 6 hours ago









    Maarten BodewesMaarten Bodewes

    58.5k6 gold badges85 silver badges213 bronze badges




    58.5k6 gold badges85 silver badges213 bronze badges














    • $begingroup$
      I'm thinking that you could also just generate a value x within of 0..n - i where i goes from 0 to m, where you set the x'th bit that is not set. That would be equivalent and easier to implement.
      $endgroup$
      – Maarten Bodewes
      4 hours ago
















    • $begingroup$
      I'm thinking that you could also just generate a value x within of 0..n - i where i goes from 0 to m, where you set the x'th bit that is not set. That would be equivalent and easier to implement.
      $endgroup$
      – Maarten Bodewes
      4 hours ago















    $begingroup$
    I'm thinking that you could also just generate a value x within of 0..n - i where i goes from 0 to m, where you set the x'th bit that is not set. That would be equivalent and easier to implement.
    $endgroup$
    – Maarten Bodewes
    4 hours ago




    $begingroup$
    I'm thinking that you could also just generate a value x within of 0..n - i where i goes from 0 to m, where you set the x'th bit that is not set. That would be equivalent and easier to implement.
    $endgroup$
    – Maarten Bodewes
    4 hours ago













    1












    $begingroup$



    The problem for choosing $k$ bits from $64$ ultimately comes down to computing a uniformly random integer $r$ with $0 leq r < frac64!k!(64-k)!$ then decoding it to determine which bits. The $k!$ in the denominator is annoying, but we can ignore it, because we can just allow our algorithm to have $k!$ random numbers that map to the same output (setting bit 0 then bit 4 is the same as setting bit 4 then bit 0). Now we just have multiplying a decreasing sequence starting from $64$: with $k=4$ this equals $64 * 63 * 62 * 61$.



    So for efficiency, you select a random number in $0 le r_0 < 64$, then another $0 le r_1 < 63$ ... through $0 le r_k-1 < 64-(k-1)$ each time using $r_n$ to select among the remaining unset bits.



    I threw the following Python code together showing the idea, though it's not fast or anything:



    # b = size of integer type
    # n = number of set bits
    # random_limited(x) is some function returning [0, x) sufficiently uniformly
    def random_n_set_bits(b, n):
    assert b > 0
    assert n >= 0 and n <= b
    result = 0
    available = list(range(b))
    for i in range(n):
    index = random_limited(len(available))
    bit = available[index]
    available = available[:index] + available[index + 1:]
    result |= (1 << bit)
    return result





    share|improve this answer











    $endgroup$



















      1












      $begingroup$



      The problem for choosing $k$ bits from $64$ ultimately comes down to computing a uniformly random integer $r$ with $0 leq r < frac64!k!(64-k)!$ then decoding it to determine which bits. The $k!$ in the denominator is annoying, but we can ignore it, because we can just allow our algorithm to have $k!$ random numbers that map to the same output (setting bit 0 then bit 4 is the same as setting bit 4 then bit 0). Now we just have multiplying a decreasing sequence starting from $64$: with $k=4$ this equals $64 * 63 * 62 * 61$.



      So for efficiency, you select a random number in $0 le r_0 < 64$, then another $0 le r_1 < 63$ ... through $0 le r_k-1 < 64-(k-1)$ each time using $r_n$ to select among the remaining unset bits.



      I threw the following Python code together showing the idea, though it's not fast or anything:



      # b = size of integer type
      # n = number of set bits
      # random_limited(x) is some function returning [0, x) sufficiently uniformly
      def random_n_set_bits(b, n):
      assert b > 0
      assert n >= 0 and n <= b
      result = 0
      available = list(range(b))
      for i in range(n):
      index = random_limited(len(available))
      bit = available[index]
      available = available[:index] + available[index + 1:]
      result |= (1 << bit)
      return result





      share|improve this answer











      $endgroup$

















        1












        1








        1





        $begingroup$



        The problem for choosing $k$ bits from $64$ ultimately comes down to computing a uniformly random integer $r$ with $0 leq r < frac64!k!(64-k)!$ then decoding it to determine which bits. The $k!$ in the denominator is annoying, but we can ignore it, because we can just allow our algorithm to have $k!$ random numbers that map to the same output (setting bit 0 then bit 4 is the same as setting bit 4 then bit 0). Now we just have multiplying a decreasing sequence starting from $64$: with $k=4$ this equals $64 * 63 * 62 * 61$.



        So for efficiency, you select a random number in $0 le r_0 < 64$, then another $0 le r_1 < 63$ ... through $0 le r_k-1 < 64-(k-1)$ each time using $r_n$ to select among the remaining unset bits.



        I threw the following Python code together showing the idea, though it's not fast or anything:



        # b = size of integer type
        # n = number of set bits
        # random_limited(x) is some function returning [0, x) sufficiently uniformly
        def random_n_set_bits(b, n):
        assert b > 0
        assert n >= 0 and n <= b
        result = 0
        available = list(range(b))
        for i in range(n):
        index = random_limited(len(available))
        bit = available[index]
        available = available[:index] + available[index + 1:]
        result |= (1 << bit)
        return result





        share|improve this answer











        $endgroup$





        The problem for choosing $k$ bits from $64$ ultimately comes down to computing a uniformly random integer $r$ with $0 leq r < frac64!k!(64-k)!$ then decoding it to determine which bits. The $k!$ in the denominator is annoying, but we can ignore it, because we can just allow our algorithm to have $k!$ random numbers that map to the same output (setting bit 0 then bit 4 is the same as setting bit 4 then bit 0). Now we just have multiplying a decreasing sequence starting from $64$: with $k=4$ this equals $64 * 63 * 62 * 61$.



        So for efficiency, you select a random number in $0 le r_0 < 64$, then another $0 le r_1 < 63$ ... through $0 le r_k-1 < 64-(k-1)$ each time using $r_n$ to select among the remaining unset bits.



        I threw the following Python code together showing the idea, though it's not fast or anything:



        # b = size of integer type
        # n = number of set bits
        # random_limited(x) is some function returning [0, x) sufficiently uniformly
        def random_n_set_bits(b, n):
        assert b > 0
        assert n >= 0 and n <= b
        result = 0
        available = list(range(b))
        for i in range(n):
        index = random_limited(len(available))
        bit = available[index]
        available = available[:index] + available[index + 1:]
        result |= (1 << bit)
        return result






        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 5 hours ago

























        answered 6 hours ago









        MyriaMyria

        1,0265 silver badges14 bronze badges




        1,0265 silver badges14 bronze badges























            Vincent is a new contributor. Be nice, and check out our Code of Conduct.









            draft saved

            draft discarded


















            Vincent is a new contributor. Be nice, and check out our Code of Conduct.












            Vincent is a new contributor. Be nice, and check out our Code of Conduct.











            Vincent is a new contributor. Be nice, and check out our Code of Conduct.














            Thanks for contributing an answer to Cryptography Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f72722%2fefficient-way-of-generating-a-random-number-of-n-less-than-64-bits-with-exactl%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            ParseJSON using SSJSUsing AMPscript with SSJS ActivitiesHow to resubscribe a user in Marketing cloud using SSJS?Pulling Subscriber Status from Lists using SSJSRetrieving Emails using SSJSProblem in updating DE using SSJSUsing SSJS to send single email in Marketing CloudError adding EmailSendDefinition using SSJS

            Кампала Садржај Географија Географија Историја Становништво Привреда Партнерски градови Референце Спољашње везе Мени за навигацију0°11′ СГШ; 32°20′ ИГД / 0.18° СГШ; 32.34° ИГД / 0.18; 32.340°11′ СГШ; 32°20′ ИГД / 0.18° СГШ; 32.34° ИГД / 0.18; 32.34МедијиПодациЗванични веб-сајту

            19. јануар Садржај Догађаји Рођења Смрти Празници и дани сећања Види још Референце Мени за навигацијуу