Почему np.random.default_rng (). Permutation (n) предпочтительнее исходной np.random.permutation (n)?

Question

Numpy документация на np.random.permutation предлагает использовать весь новый код np.random.default_rng() из пакета Random Generator. Я вижу в документации, что пакет Random Generator стандартизировал генерацию широкого спектра случайных распределений вокруг BitGenerator по сравнению с использованием Mersenne Twister, с которым я смутно знаком.

Я вижу один недостаток, то, что раньше было одной строкой кода для выполнения простых перестановок:

np.random.permutation(10)

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

rng = np.random.default_rng()
rng.permutation(10)

• Почему этот новый подход является улучшением по сравнению с предыдущим?
• И почему бы существующим методам, таким как np.random.permutation, просто не обернуть этот новый предпочтительный метод?
• Есть ли веская причина не использовать этот новый метод как однострочник np.random.default_rng().permutation(10), предполагая, что он не вызывается на больших объемах?
• Есть ли аргумент для переключения существующего кода на этот метод?

Answer 1

Некоторый контекст:

• Всегда ли numpy .random.seed () всегда дает одно и то же случайное число каждый раз?
• NumPy: Выберите новый PRNG BitGenerator по умолчанию

На ваши вопросы в логическом порядке:

И почему бы не существующие методы, такие как np.random .permutation просто оберните этот новый предпочтительный метод?

Вероятно, из-за проблем с обратной совместимостью . Даже если бы API "верхнего уровня" не изменился, его внутренние компоненты были бы достаточно значительными, чтобы считаться нарушением совместимости.

Почему этот новый подход является улучшением по сравнению с предыдущим подходом?

«По умолчанию генератор использует биты, предоставленные PCG64, который имеет лучшие статистические характеристики, чем устаревший MT19937, используемый в RandomState.» ( источник ). Строка документации PCG64 предоставляет более подробную техническую информацию.

Есть ли веская причина не использовать этот новый метод как однострочный np.random.default_rng().permutation(10), предполагая, что он не вызывается на высокой скорости? volume?

Я полностью согласен с тем, что это немного неудобная добавленная строка кода, если она выполняется при запуске модуля. Я хотел бы только указать, что NumPy документы напрямую используют эту форму в примерах строк документации, например:

n = np.random.default_rng().standard_exponential((3, 8000))

Небольшая разница будет в том, что экземпляр класса создается во время загрузки / импорта модуля, тогда как в вашей форме это может появиться позже. Но это должно быть незначительное различие (опять же, при условии, что оно использовалось только один или несколько раз). Если вы посмотрите на источник default_rng(seed), при вызове с None он просто вернет Generator(PCG64(seed)) после нескольких быстрых проверок seed.

Есть ли аргумент для переключения существующего кода на этот метод?

Собираетесь передать этот, потому что у меня нет никаких технических знаний, чтобы дать хорошее сравнение алгоритмов, а также потому, что это зависит от некоторых других переменных, например, от того, беспокоитесь ли вы о совместимости нисходящего кода со старыми версиями NumPy, где default_rng() просто не существует.