Detailed SciPy Roadmap#
此 roadmap 的主要目的是提供關於每個 SciPy 子模組在新增功能、錯誤修復等方面最需要的概觀。除了重要的「例行公事」變更之外,它還包含主要新功能的想法 - 這些功能已標記,並且預計需要投入大量專門的精力。此 roadmap 中未提及的事項不一定不重要或超出範圍,但我們(SciPy 開發人員)希望向我們的使用者和貢獻者清楚地說明 SciPy 的發展方向以及最需要協助的地方。
Note
這是詳細的 roadmap。只有最重要的想法的非常高階的概述,請參閱SciPy Roadmap。
General#
此 roadmap 將隨著 SciPy 一起演進。更新可以作為 pull request 提交。對於大型或破壞性變更,您可能需要先在 scipy-dev 論壇上討論這些變更。
API changes#
一般而言,我們希望發展 API,盡可能消除已知的瑕疵,但在盡可能不破壞向後相容性的情況下。
Test coverage#
過去幾年新增程式碼的測試覆蓋率相當不錯,我們的目標是為所有新增程式碼達到高覆蓋率。但是,仍然有大量舊程式碼的覆蓋率很差。將其提升到目前的標準可能不切實際,但我們應該彌補最大的漏洞。
除了覆蓋率之外,還有正確性的問題 - 舊程式碼可能有一些測試提供良好的陳述覆蓋率,但這不一定能說明程式碼是否執行其應有的功能。因此,有必要對某些部分的程式碼(特別是 stats
、signal
和 ndimage
)進行程式碼審查。
Documentation#
文件狀況良好。應繼續擴展目前的文件字串 - 新增範例、參考資料和更好的說明。大多數模組在參考指南中也有一個很好的入門教學,但是有一些教學遺失或不完整 - 這應該修正。
Benchmarks#
基於 asv
的基準測試系統狀況尚可。新增基準測試非常容易,但是執行基準測試不是很直觀。讓這變得更容易是當務之急。
Use of Cython#
Cython 使用 NumPy 陣列的舊語法應移除,並替換為 Cython memoryview。
從 Cython 程式碼建置的擴充模組的二進制檔大小很大,而且編譯時間很長。我們應該盡可能合併擴充模組(例如,stats._boost
現在包含許多擴充模組),並將 Cython 的使用限制在它是最佳選擇的地方。請注意,scipy.special
中正在進行 Cython 到 C++ 的轉換。
Use of Pythran#
Pythran 仍然是可選的建置相依性,可以使用 -Duse-pythran=false
停用。目標是使其成為硬性相依性 - 為實現這一目標,必須明確維護負擔足夠低。
Use of venerable Fortran libraries#
SciPy 的成功很大程度上歸功於依賴於包裝完善的 Fortran 程式庫(QUADPACK、FITPACK、ODRPACK、ODEPACK 等)。其中一些程式庫老化良好,另一些則不然。我們應該針對維護工作、功能以及(可能部分)替代方案的存在,包括 SciPy 內部的替代方案,來稽核我們對這些程式庫的使用。
Continuous integration#
持續整合目前涵蓋 32/64 位元 Windows、x86-64/arm 上的 macOS、x86 上的 32/64 位元 Linux 和 aarch64 上的 Linux - 以及一系列版本的相依性和建置發行品質 wheel。由於要支援大量組態,以及某些 CI 作業需要徹底檢修,因此 CI 的可靠性最近(2023 年上半年)不佳。我們的目標是透過在我們捨棄該建置系統時移除剩餘的基於 distutils 的作業,並使 CI 作業中的組態設定更正交,來縮短建置時間。
Size of binaries#
SciPy 二進制檔相當大(例如,1.7.3 的未壓縮 manylinux wheel 在 PyPI 上為 39 MB,安裝後為 122 MB),這可能會帶來問題 - 例如在 AWS Lambda 中使用,AWS Lambda 的大小限制為 250 MB。我們的目標是盡可能保持二進制檔大小較小;新增已編譯的擴充功能時,需要檢查這一點。multibuild
中偵錯符號的剝離或許可以改進(請參閱此 issue)。應盡力縮減大小,並且不要新增新的大型檔案。未來,正在考慮(非常初步地)並且可能有助於分離捆綁的 `libopenblas
並移除對 long double
的支援。
Modules#
cluster#
dendrogram
需要重寫,它有許多難以修復的未解決 issue 和功能請求。
constants#
此模組基本上已完成,維護成本低且沒有未解決的 issue。
fft#
此模組狀況良好。
integrate#
ODE 求解器需要
文件非常糟糕,需要修正
新的 ODE 求解器介面 (
solve_ivp
) 已在 SciPy 1.0.0 中新增。未來我們可以考慮(軟)棄用較舊的 API。
數值積分函數狀況良好。可以新增支援積分複數值函數和積分多個區間(請參閱 gh-3325)。
interpolate#
Spline 擬合:我們需要具有更好使用者控制的 spline 擬合常式。這包括
用於平滑準則的使用者可選替代方案(手動、交叉驗證等);gh-16653 朝著這個方向邁出了第一步;
用於節點放置的幾種策略,包括手動和自動(使用 Dierckx、de Boor 以及可能其他人的演算法)。
一旦我們擁有功能相當完整的集合,我們就可以開始長期關注歷史悠久的 FITPACK Fortran 程式庫的未來,該程式庫目前是在 SciPy 中建構平滑 spline 的唯一方法。
可擴展性和效能:對於基於 FITPACK 的功能,資料大小受 32 位元 Fortran 整數大小(對於非 ILP64 建置)的限制。對於 N 維散佈內插器(基於 QHull)和 N 維規則網格內插器,我們需要檢查大型資料集上的效能,並在不足之處進行改進(gh-16483 朝著這個方向取得了進展)。
新功能的想法:可以新增 NURBS 支援。
io#
wavfile
將支援 PCM float,對於其他任何內容,請使用
audiolab
或其他專用程式庫。如果資料無法理解,則引發錯誤而不是警告。
其他子模組(matlab、netcdf、idl、harwell-boeing、arff、matrix market)狀況良好。
linalg#
scipy.linalg
狀況良好。
Needed
減少與
numpy.linalg
的函數重複,使 API 保持一致。get_lapack_funcs
應始終使用flapack
包裝更多 LAPACK 函數
LU 分解的函數太多,移除一個
新功能的想法
在 Cython BLAS 和 LAPACK 中新增型別泛型包裝器
將許多線性代數常式轉換為 gufunc
BLAS 和 LAPACK
scipy.linalg
中的 Python 和 Cython 介面是 SciPy 提供最重要的功能之一。一般而言,scipy.linalg
狀況良好,但我們可以進行一些改進
程式庫支援。我們發佈的 wheel 現在隨附 OpenBLAS,這是目前唯一可行的效能選項(ATLAS 太慢,由於授權問題,MKL 無法成為預設選項,由於 Apple 不再更新 Accelerate,因此已捨棄 Accelerate 支援)。但是,OpenBLAS 並不是很穩定,有時它的發行版本會破壞某些功能,並且存在執行緒問題(目前是將 SciPy 與 PyPy3 一起使用的唯一問題)。我們至少需要更好地支援偵錯 OpenBLAS 問題,以及更好地說明如何使用它建置 SciPy。一種選擇是使用 BLIS 作為 BLAS 介面(請參閱 numpy gh-7372)。
支援較新的 LAPACK 功能。在 SciPy 1.2.0 中,我們將 LAPACK 的最低支援版本提高到 3.4.0。現在我們已經捨棄了 Python 2.7,我們可以進一步提高該版本(MKL + Python 2.7 以前是 >3.4.0 的阻礙),並開始新增對 LAPACK 中新功能的支援。
misc#
scipy.misc
將作為公用模組移除。其中的大多數函數已移至另一個子模組或已棄用。剩下的幾個
derivative
、central_diff_weight
:移除,可能會用更廣泛的數值微分功能取代它們。ascent
、face
、electrocardiogram
:移除或移動到適當的子套件(例如scipy.ndimage
、scipy.signal
)。
ndimage#
底層的 ndimage
是一個強大的內插引擎。使用者期望兩種模型之一:像素模型,其中 (1, 1)
元素具有中心 (0.5, 0.5)
,或資料點模型,其中值定義在網格上的點。隨著時間的推移,我們越來越相信資料點模型定義得更好且更易於實作,但這應該在文件中清楚地傳達。
更重要的是,SciPy 仍然實作此資料點模型的變體,其中軸上任何兩個極端位置的資料點在週期性包裝模式下共用空間位置。例如,在 1 維陣列中,您將具有 x[0]
和 x[-1]
共位。但是,一個非常常見的用例是訊號是週期性的,軸上第一個和最後一個元素之間具有相等的間距(而不是零間距)。此用例的包裝模式已在 gh-8537 中新增,接下來應更新內插常式以使用這些模式。這應該解決幾個 issue,包括 gh-1323、gh-1903、gh-2045 和 gh-2640。
形態介面需要標準化
二進制膨脹/腐蝕/開啟/關閉採用「structure」引數,而它們的灰度等效項採用 size(必須是元組,而不是純量)、footprint 或 structure。
純量對於 size 應該是可以接受的,相當於為每個軸提供相同的值。
對於二進制膨脹/腐蝕/開啟/關閉,結構元素是可選的,而對於灰度,它是強制性的。灰度形態操作應獲得相同的預設值。
其他篩選器也應在可能的情況下採用該預設值。
odr#
此模組狀況尚可,儘管它可以使用更多的維護。這裡沒有主要的計畫或願望。
optimize#
總體而言,此模組狀況良好。1.2.0 中新增了兩個良好的全域最佳化器;大規模最佳化器仍然是可以填補的空白。其他需要的東西
linprog
中用於額外功能的許多想法(例如整數約束),請參閱 gh-9269。在基準測試套件中新增功能,以便更輕鬆地比較結果(例如使用摘要圖)。
在文件中棄用
fmin_*
函數,建議使用minimize
。scipy.optimize
具有針對全域最佳化器的準確性和速度的廣泛基準測試集。這使得可以新增新的最佳化器(shgo
和dual_annealing
),其效能明顯優於現有的最佳化器。但是,optimize
基準測試系統本身速度很慢且難以使用;我們需要使其更快,並使其更容易透過繪製效能設定檔來比較最佳化器的效能。
signal#
卷積和相關性:(相關函數為 convolve、correlate、fftconvolve、convolve2d、correlate2d 和 sepfir2d。)消除與 ndimage(和其他地方)的重疊。從 numpy
、scipy.signal
和 scipy.ndimage
(以及我們找到它們的任何其他地方),為 1 維、2 維和 n 維卷積和相關性選擇「最佳類別」,將實作放在某個地方,並在整個 SciPy 中一致地使用它。
B-spline:(相關函數為 gauss_spline、cspline1d、qspline1d、cspline2d、qspline2d、cspline1d_eval 和 spline_filter。)將好的東西移動到 interpolate(進行適當的 API 變更以符合 interpolate 中的操作方式),並消除任何重複。
篩選器設計:合併 firwin 和 firwin2,以便可以移除 firwin2。
連續時間線性系統:進一步提高 ltisys
的效能(減少不同表示形式之間的內部轉換)。填補 lti 系統轉換函數中的空白。
二階區段:使 SOS 篩選與現有方法一樣強大。這包括 ltisys 物件、lfiltic 等效項,以及與其他篩選器表示形式之間數值穩定的轉換。SOS 篩選器可以被視為 ltisys 物件的預設篩選方法,以提高其數值穩定性。
sparse#
稀疏矩陣格式在很大程度上已完成功能,但主要問題是它們的作用類似於 numpy.matrix
(這將在 NumPy 中的某個時候棄用)。
我們想要的是作用類似於 numpy.ndarray
的稀疏陣列。SciPy 1.8.0
中新增了對一組新類別(csr_array
等)的初始支援,並在新增陣列的建構函數時在 1.12.0
中穩定下來。預計在 1.13.0
中支援 1 維陣列。
支援稀疏陣列的後續步驟
- 將稀疏陣列 API 擴展到 1 維陣列。
支援 COO、CSR 和 DOK 格式。
CSR 1 維支援最小值-最大值、索引、算術。
協助其他程式庫將稀疏矩陣轉換為稀疏陣列。建立轉換指南和有用的腳本,以標記需要進一步檢查的程式碼。NetworkX、scikit-learn 和 scikit-image 正在進行或已完成轉換為稀疏陣列。
在稀疏陣列程式碼成熟後(約 1 個發行週期?),為稀疏矩陣新增棄用警告。
與 NumPy 合作,棄用/移除
numpy.matrix
。棄用然後移除稀疏矩陣,改用稀疏陣列。
- 開始建構函數名稱的 API 轉換(
diags
、block
等) 注意:整體而言,建構函數經歷了兩次名稱轉換。第一次是從矩陣建立移動到用於陣列建立的新函數(即
eye
->eye_array
)。然後是第二次移動,在移除稀疏矩陣後,將名稱更改為與array_api
名稱(即eye_array
到eye
)相符。我們將長期保留*_array
版本作為(可能是隱藏的)別名。
- 開始建構函數名稱的 API 轉換(
新增與
array_api
名稱相符的建構函數名稱。棄用轉換建構函數名稱。
替代(更雄心勃勃,且不清楚是否會實現)計畫正在 pydata/sparse 中制定。為了支援該工作,我們的目標是在接受稀疏陣列的所有函數中支援 PyData Sparse。scipy.sparse.linalg
和 scipy.sparse.csgraph
中對 pydata/sparse
的支援已基本完成。
關於不同的稀疏矩陣格式:有很多種。這些應保留,但改進/最佳化應轉向 CSR/CSC,這是首選格式。LIL 可能是例外,它本質上是低效的。如果 DOK 擴展為支援 LIL 目前提供的所有操作,則可以捨棄它。
sparse.csgraph#
此模組狀況良好。
sparse.linalg#
_arpack
和 lobpcg
有大量未解決的 issue。_propack
在 1.8.0 中是新的,TBD 它最終會變得多麼穩健。
_isolve
:
callback 關鍵字不一致
tol 關鍵字已損壞,應為相對 tol
Fortran 程式碼不可重入(但我們不求解,可能會從 PyKrilov 重用)
_dsolve
:
新增授權相容的稀疏 Cholesky 或不完全 Cholesky
新增授權相容的稀疏 QR
改進 SuiteSparse UMFPACK 的介面
新增 SuiteSparse CHOLMOD 和 SPQR 的介面
spatial#
QHull 包裝器狀況良好,KDTree
也是如此。
C++ 中正在進行 spatial.distance
指標的重寫 - 這應該可以提高效能,使行為(例如,對於各種非 float64 輸入 dtype)更加一致,並修復一些剩餘的 issue,這些 issue 與少數指標實作的數學定義有關。
special#
儘管仍有許多函數需要提高精度,但可能唯一的阻礙是超幾何函數、拋物柱面函數和球狀波函數。處理此問題的三種可能方法
取得良好的雙精度實作。這對於拋物柱面函數是可行的(正在進行中)。我認為超幾何函數是可能的,儘管可能來不及。對於球狀波函數,目前的理論無法實現。
移植 Boost 的任意精度程式庫,並在底層使用它以獲得雙精度準確度。這可能是超幾何函數的權宜之計;@nmayorov 和 gh-5349 之前曾建議使用任意精度的想法。對於球狀波函數可能是必要的,這可以重複使用:radelman/scattering。
在文件中新增關於現有實作限制的明確警告。
stats#
scipy.stats
子套件旨在提供基本統計方法,這些方法可能涵蓋在標準統計學教科書中,例如 Johnson 的「工程師的 Miller & Freund 概率與統計」、Sokal & Rohlf 的「生物統計學」或 Zar 的「生物統計分析」。它不尋求複製下游套件(例如 StatsModels、LinearModels、PyMC3)的進階功能;相反,它可以提供一個穩固的基礎,讓它們可以在此基礎上建構。(請注意,這些是粗略的指導方針,而不是嚴格的規則。「進階」是一個定義不明確且主觀的術語,「進階」方法也可能包含在 SciPy 中,尤其是在沒有其他廣泛使用且良好支援的套件涵蓋該主題的情況下。另請注意,與下游專案的某些重複是不可避免的,而且不一定是壞事。)
除了 SciPy Roadmap 中描述的項目外,以下改進將有助於 SciPy 更好地發揮此作用。
新增基本且廣泛使用的假設檢定,例如
事後檢定(例如 Dunnett 檢定)
各種變異數分析 (ANOVA)
雙因子 ANOVA(單一重複、重複次數一致、重複次數可變)
多因子 ANOVA(即推廣雙因子 ANOVA)
巢狀 ANOVA
共變數分析 (ANCOVA)
此外,提供用於實作假設檢定的基礎結構。
新增用於統合分析的其他工具
新增用於生存分析的工具
加速分佈的隨機變數取樣(方法
rvs
),在適當情況下利用scipy.stats.sampling
擴展 QMC 功能和效能
增強連續機率分佈的 fit 方法
擴展擬合選項以包括
最大乘積間距
L-動差方法/機率加權動差
在結果中包含適合度衡量標準
處理截尾資料(例如合併 gh-13699)
實作其他廣泛使用的連續和離散機率分佈,例如混合分佈。
改進 SciPy 機率分佈提供的核心計算,以便它們可以穩健地處理廣泛的參數值。具體來說,將
scipy.special
中使用的 Fortran 程式庫 CDFLIB 中的許多 PDF 和 CDF 方法替換為 Boost 實作,如 gh-13328 中所示。
此外,我們應該
繼續努力使
stats
和stats.mstats
的函數簽名更加一致,並新增測試以確保這種情況保持不變。改進統計檢定:傳回檢定統計量的信賴區間,並在計算上可行時實作精確的 p 值計算 - 考慮到 ties 的可能性。