Политика совместимости

numpy.random имеет несколько более строгую политику совместимости, чем остальная часть NumPy. Пользователи псевдослучайных чисел часто имеют случаи использования, чтобы иметь возможность воспроизвести запуски в мельчайших деталях при заданном зерне (так называемая «совместимость потока»), и поэтому мы стараемся сбалансировать эти потребности с гибкостью для улучшения наших алгоритмов. NEP 19 описывает эволюцию этой политики.

Основной вид совместимости, который мы обеспечиваем, — это совместимость потока от запуска к запуску при определенных условиях. Если вы создаёте Generator с тем же BitGenerator, с тем же зерном, выполняете ту же последовательность вызовов методов с теми же аргументами, на той же сборке numpy, в той же среде, на той же машине, вы должны получить тот же поток чисел. Обратите внимание, что эти условия очень жёсткие. Есть ряд факторов, не зависящих от NumPy, которые ограничивают нашу способность гарантировать большее, чем это. Например, различные процессоры реализуют арифметику с плавающей запятой по-разному, и это может вызывать различия в определённых граничных случаях, которые распространяются на остальную часть потока. Generator.multivariate_normal, например, использует разложение матрицы из numpy.linalg. Даже на одной и той же платформе другая сборка numpy может использовать другую версию алгоритма разложения этой матрицы из LAPACK, к которому она подключена, что приводит к тому, что Generator.multivariate_normal возвращает совершенно разные (но одинаково допустимые!) результаты. Мы стремимся отдавать предпочтение алгоритмам, которые более устойчивы к этим эффектам, но это всегда несовершенно.

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

Нарушение совместимости потока для внедрения новых функций или повышения производительности в Generator или default_rng будет допускаться с осторожностью. Такие изменения будут рассматриваться как функции и, как таковые, не будут быстрее стандартного темпа выпуска функций (то есть на X.Y выпусках, никогда не на X.Y.Z). Медленность не будет считаться ошибкой в этих целях. Исправления ошибок, нарушающих совместимость потока, могут произойти на выпусках с исправлениями ошибок, как обычно, но разработчики должны подумать, могут ли они подождать следующего выпуска функций. Мы рекомендуем разработчикам сильно учитывать страдания пользователей от разрыва совместимости потока по сравнению с улучшениями. Примером полезного улучшения является изменение алгоритмов для значительного повышения производительности, например, переход от метода преобразования Бокса—Мюллера для генерации гауссовых величин к более быстрому алгоритму Зиггурата.

В целом, классы BitGenerator имеют более сильные гарантии совместимости потоков от версии к версии. Это позволяет им быть более надёжной основой для пользователей последующих уровней, которым это нужно. Ограниченная поверхность API делает их более лёгкими для поддержания этой совместимости от версии к версии. См. строки документации каждого класса BitGenerator для гарантий совместимости каждой отдельной версии.

Устаревшие RandomState и сопутствующие удобные функции имеют более строгую гарантию совместимости от версии к версии. По причинам, изложенным в NEP 19, мы дали более сильные обещания о стабильности их версии к версии на ранних этапах разработки NumPy. До сих пор есть некоторые ограниченные случаи использования для этого вида совместимости (например, генерация данных для тестов), поэтому мы поддерживаем максимальную совместимость. Больше никаких изменений в RandomState, даже для исправления ошибок. Есть несколько «серых зон», где мы можем внести небольшие исправления, чтобы сохранить работу RandomState без сегментирующего нарушения, когда меняются внутренности NumPy, и некоторые исправления документации. Однако ранее упомянутые оговорки о вариативности от машины к машине и от сборки к сборке по-прежнему относятся к RandomState в той же мере, как и к Generator.