Почему np.random.default_rng().permutation(n) предпочтительнее оригинального np.random.permutation(n)?

документация 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), предполагая, что он не вызывается в больших объемах?
  • Есть ли аргумент для переключения существующего кода на этот метод?

python numpy numpy-random
person David Parks    schedule 17.06.2020    source источник
comment
Я не могу дать обоснованный ответ, но я думаю, что идея состоит в том (аналогично тому, что делает C ++?) Отделить генераторы от сэмплеров и заставить людей явно указывать генератор. Также см. комментарии к выпуску.   -  person phipsgabler    schedule 17.06.2020
comment
Я думаю, что ожидается, что вы создадите default_rng один раз в начале вашего скрипта и будете использовать его повторно с perumutation, randint и т. д. Для одноразового случайного вызова я бы не стал прилагать никаких дополнительных усилий для использования нового упаковка. Я не использовал его при ответе на вопросы SO. При добавлении новых функций обычно безопаснее добавлять их с новыми вызовами и интерфейсом, а не заменять старые. Меньше риск испортить существующий код.   -  person hpaulj    schedule 17.06.2020

Ответы (1)


arrow_upward
2
arrow_downward

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

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

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

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

Почему этот новый подход лучше предыдущего?

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

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

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

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

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

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

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

person Brad Solomon    schedule 17.06.2020