相容性政策

numpy.random 的相容性政策比 NumPy 的其他部分稍微嚴格。偽隨機性的使用者通常有需要在給定相同種子時，能夠精細地重現運行的用例（所謂的「流相容性」），因此我們嘗試在這些需求與增強演算法的彈性之間取得平衡。NEP 19 描述了此政策的演進。

我們強制執行的主要相容性類型是在特定條件下，每次運行之間的流相容性。如果您使用相同的 BitGenerator 建立 Generator，使用相同的種子，在相同版本的 numpy 組建版本、相同的環境和相同的機器上，執行相同的方法呼叫序列並使用相同的引數，您應該會得到相同的數字流。請注意，這些條件非常嚴格。有許多 NumPy 無法控制的因素限制了我們保證更多內容的能力。例如，不同的 CPU 實作浮點運算的方式不同，這可能會在某些邊緣情況下造成差異，並向下影響到資料流的其餘部分。例如，Generator.multivariate_normal 使用來自 numpy.linalg 的矩陣分解。即使在相同的平台上，不同組建版本的 numpy 也可能使用來自它連結的 LAPACK 的不同版本矩陣分解演算法，導致 Generator.multivariate_normal 傳回完全不同（但同樣有效！）的結果。我們努力偏好更能抵抗這些影響的演算法，但這始終是不完美的。

注意

大多數 Generator 方法允許您從分佈中提取多個值作為陣列。此陣列的請求大小是一個參數，為了上述政策的目的。呼叫 rng.random() 5 次 *不保證* 會給出與 rng.random(5) 相同的數字。我們保留決定針對不同大小的區塊使用不同演算法的能力。實際上，這種情況很少發生。

與 NumPy 的其餘部分一樣，我們通常保持版本之間的 API 原始碼相容性。如果我們 *必須* 進行破壞 API 相容性的變更，那麼我們只會在適當的棄用期和警告下，根據 一般 NumPy 政策 進行。

為了在 Generator 或 default_rng 中引入新功能或提高效能而破壞流相容性是 *允許的*，但需 *謹慎*。此類變更將被視為功能，因此其發布速度不會快於標準功能發布週期（即在 X.Y 版本上，絕不在 X.Y.Z 版本上）。為此目的，速度慢不會被視為錯誤。修復會破壞流相容性的正確性錯誤可以在錯誤修復版本上發生，與往常一樣，但開發人員應考慮是否可以等到下一個功能發布版本。我們鼓勵開發人員權衡使用者因流相容性中斷而產生的痛苦與改進的程度。一個值得的改進範例是更改演算法以顯著提高效能，例如，從高斯變數生成的 Box-Muller 轉換 方法改為更快的 Ziggurat 演算法。一個不鼓勵的改進範例是稍微調整 Ziggurat 表格以獲得微小的效能提升。

注意

特別是，default_rng 允許變更其使用的預設 BitGenerator（同樣，需 *謹慎* 並提前充分警告）。

一般而言，BitGenerator 類別具有更強的版本間流相容性保證。這使其可以成為需要它的下游使用者的更堅實的建構區塊。它們有限的 API 介面使它們更容易在版本之間保持這種相容性。請參閱每個 BitGenerator 類別的文件字串，以了解它們各自的相容性保證。

舊版的 RandomState 和 相關的便利函式 具有更嚴格的版本間相容性保證。由於 NEP 19 中概述的原因，我們在 NumPy 開發初期就對其版本間穩定性做出了更強的承諾。對於這種相容性仍然有一些有限的用例（例如為測試生成資料），因此我們盡可能保持相容性。不會再對 RandomState 進行修改，即使是為了修復正確性錯誤也不會。有一些灰色地帶，我們可以在這些灰色地帶進行小的修復，以保持 RandomState 在 NumPy 內部結構變更時繼續運作而不會發生區段錯誤，以及一些文件字串修復。然而，先前關於機器與機器之間以及組建版本與組建版本之間變異性的警告仍然適用於 RandomState，就像它適用於 Generator 一樣。