что может быть случай, когда лучший алгоритм зависит по стоимости num, Так почему бы не использовать 2 выбираемых алгоритма, обернутых в один генератор ?

вы могли бы смешать ваш shuffle и set решения с пороговым значением num. Это в основном сборка ваших 2 первых решений в одном генераторе:

from random import shuffle,randint

def MyGenerator(foo, num):
    if num < 100000 # has to be adjusted by experiments
      order = list(range(num))
      shuffle(order)
      for i in order:
          if foo(i):
              yield i
    else:   # big values, few collisions with random generator 
      tried = set()
      while len(tried) < num:
        i = randint(0, num-1)
        if i in tried:
           continue
        tried.add(i)
        if foo(i):
           yield i

на randint решение (для больших значений num) работает хорошо, потому что в случайном порядке не так много повторов генератор.

получить лучшую производительность в Python намного сложнее, чем в языках более низкого уровня. Например, в C вы часто можете сохранить немного в горячих внутренних циклах, заменив умножение сдвигом. Накладные расходы на ориентацию байт-кода python стирают это. Конечно, это меняет снова когда вы рассматриваете, какой вариант "python" вы нацеливаете (pypy? и NumPy? на Cython?)- ты действительно нужно написать код на основе которого вы с помощью.

но еще более важным является организация операции, чтобы избежать сериализации зависимости, поскольку все процессоры в эти дни суперскалярной. Конечно, настоящие компиляторы знают об этом, но все равно важно, когда выбор алгоритм.

один из самых простых способов получить немного больше существующих ответов будет путем генерации чисел в кусках с помощью numpy.arange () и применение ((x + c) * m) % n непосредственно к numpy ndarray. Каждый цикл уровня python этого можно избежать.

если функция может быть применена непосредственно к numpy ndarrays, это может быть даже лучше. Конечно, достаточно маленькая функция в python в любом случае будет доминировать над служебными вызовами.

лучший быстрый генератор случайных чисел сегодня PCG. Я написал порт pure-python здесь но сосредоточены на гибкости и легкости понимания, а не на скорости.

Xoroshiro128 + is второе-лучшее качество и быстрее, но менее информативно для изучения.

Python (и многие другие) выбор по умолчанию Мерсенн Твистер является одним из худших.

(есть также что - то под названием splitmix64, о котором я недостаточно знаю - некоторые люди говорят, что это лучше, чем xoroshiro128+, но у него есть проблема с периодом-конечно, вы можете хочу здесь)

и default-PCG и xoroshiro128 + используют 2n-разрядное состояние для генерации N-разрядных чисел. Этот вообще желательно, но значит числа будут повторяться. Однако PCG имеет альтернативные режимы, которые этого избегают.

конечно, многое из этого зависит, будет ли num (близко к) степень 2. Теоретически, варианты PCG могут быть созданы для любой ширины бита, но в настоящее время реализованы только различные размеры слов, так как вам понадобится явная маскировка. Я не уверен, как именно генерировать параметры для новых битовых размеров (возможно, это в статье?), но их можно проверить, просто выполнив период / 2 прыжок и проверка того, что значение отличается.

конечно, если вы делаете только 200 вызовов RNG, вам, вероятно, на самом деле не нужно избегать дубликатов на математической стороне.

кроме того, вы можете использовать РСЛОС, который тут существует для каждого размера бита (хотя обратите внимание, что он никогда не генерирует значение всех нулей (или, что эквивалентно, значение всех единиц)). LFSRs являются последовательными и (AFAIK) не скачкообразными и, следовательно, не могут легко разделить на несколько задач. Edit: я понял, что это неправда, просто представить шаг продвижения как матрицу и экспоненциально его прыгать.

обратите внимание, что LFSRs do имеют те же очевидные предубеждения, что и просто генерирование чисел в последовательном порядке на основе случайной начальной точки - например, если rng_outputs[a: b] все терпят неудачу