Detaillierte SciPy Roadmap#

Der Großteil dieser Roadmap soll einen High-Level-Überblick darüber geben, was pro SciPy-Untermodul am dringendsten in Bezug auf neue Funktionalität, Fehlerbehebungen usw. benötigt wird. Neben wichtigen "Business as usual"-Änderungen enthält sie Ideen für größere neue Features – diese sind entsprechend gekennzeichnet und erfordern voraussichtlich erhebliche dedizierte Anstrengungen. Dinge, die in dieser Roadmap nicht erwähnt werden, sind nicht unbedingt unwichtig oder außerhalb des Geltungsbereichs. Wir (die SciPy-Entwickler) möchten unseren Benutzern und Mitwirkenden jedoch ein klares Bild davon vermitteln, wohin sich SciPy entwickelt und wo Hilfe am dringendsten benötigt wird.

Hinweis

Dies ist die detaillierte Roadmap. Eine sehr hochrangige Übersicht mit nur den wichtigsten Ideen finden Sie unter SciPy Roadmap.

Allgemein#

Diese Roadmap wird sich parallel zu SciPy weiterentwickeln. Aktualisierungen können als Pull-Anfragen eingereicht werden. Bei großen oder disruptiven Änderungen sollten Sie diese zuerst im scipy-dev-Forum besprechen.

API-Änderungen#

Im Allgemeinen möchten wir die API weiterentwickeln, um bekannte "Warts" (Schönheitsfehler) so weit wie möglich zu entfernen, *jedoch so weit wie möglich ohne Bruch der Abwärtskompatibilität*.

Testabdeckung#

Die Testabdeckung des in den letzten Jahren hinzugefügten Codes ist ziemlich gut, und wir streben eine hohe Abdeckung für allen neu hinzugefügten Code an. Es gibt jedoch immer noch einen erheblichen Teil alten Codes, dessen Abdeckung schlecht ist. Dies auf den aktuellen Standard zu bringen, ist wahrscheinlich nicht realistisch, aber wir sollten die größten Lücken schließen.

Neben der Abdeckung gibt es auch die Frage der Korrektheit – älterer Code hat möglicherweise einige Tests, die eine ordentliche Statement-Abdeckung bieten, aber das sagt nicht unbedingt viel darüber aus, ob der Code das tut, was er vorgibt zu tun. Daher ist eine Code-Überprüfung einiger Teile des Codes (insbesondere stats, signal und ndimage) notwendig.

Dokumentation#

Die Dokumentation ist in einem guten Zustand. Die Erweiterung bestehender Docstrings – Hinzufügen von Beispielen, Referenzen und besseren Erklärungen – sollte fortgesetzt werden. Die meisten Module haben auch ein Tutorial im Referenzhandbuch, das eine gute Einführung darstellt, jedoch fehlen oder sind einige Tutorials unvollständig – dies sollte behoben werden.

Benchmarks#

Das auf asv basierende Benchmark-System ist in einem vernünftigen Zustand. Es ist ziemlich einfach, neue Benchmarks hinzuzufügen, aber das Ausführen der Benchmarks ist nicht sehr intuitiv. Dies zu vereinfachen ist eine Priorität.

Verwendung von Cython#

Die alte Cython-Syntax für die Verwendung von NumPy-Arrays sollte entfernt und durch Cython-Speicheransichten ersetzt werden.

Die Binärgrößen von aus Cython-Code erstellten Erweiterungen sind groß und die Kompilierzeiten sind lang. Wir sollten versuchen, Erweiterungsmodule zu kombinieren, wo möglich (z. B. enthält stats._boost jetzt viele Erweiterungsmodule) und die Verwendung von Cython auf Orte zu beschränken, an denen es die beste Wahl ist. Beachten Sie, dass die Konvertierung von Cython nach C++ in scipy.special fortlaufend ist.

Verwendung von Pythran#

Pythran ist immer noch eine optionale Build-Abhängigkeit und kann mit -Duse-pythran=false deaktiviert werden. Ziel ist es, es zu einer harten Abhängigkeit zu machen – dazu muss klar sein, dass der Wartungsaufwand niedrig genug ist.

Verwendung von Fortran-Bibliotheken#

SciPy verdankt viel von seinem Erfolg der Abhängigkeit von gut etablierten Fortran-Bibliotheken (QUADPACK, FITPACK, ODRPACK, ODEPACK usw.). Das Fortran 77, in dem diese Bibliotheken geschrieben sind, ist schwer zu warten, und die Verwendung von Fortran ist aus vielen Gründen problematisch; z. B. erschwert es die Wartung unserer Wheel-Builds erheblich, es gab wiederholt Probleme bei der Unterstützung neuer Plattformen wie macOS arm64 und Windows auf Arm, und es ist äußerst problematisch für die Pyodide-Unterstützung von SciPy. Unser Ziel ist es, allen Fortran-Code aus SciPy zu entfernen, indem die Funktionalität durch in anderen Sprachen geschriebenen Code ersetzt wird. Der Fortschritt in diese Richtung wird unter gh-18566 verfolgt.

Kontinuierliche Integration#

Die kontinuierliche Integration deckt derzeit 32/64-Bit-Windows, macOS auf x86-64/arm, 32/64-Bit-Linux auf x86 und Linux auf aarch64 ab – sowie eine Reihe von Versionen unserer Abhängigkeiten und den Aufbau von Build-Qualitäts-Wheels. Die Zuverlässigkeit der CI war in letzter Zeit nicht gut (H1 2023), aufgrund der großen Menge an zu unterstützenden Konfigurationen und einiger CI-Jobs, die überarbeitet werden müssen. Wir streben danach, die Build-Zeiten zu reduzieren, indem wir die verbleibenden distutils-basierten Jobs entfernen, wenn wir dieses Build-System fallen lassen, und die Menge der Konfigurationen in CI-Jobs orthogonaler gestalten.

Größe von Binärdateien#

SciPy-Binärdateien sind ziemlich groß (z. B. ist ein entpacktes manylinux-Wheel für 1.7.3 39 MB auf PyPI und 122 MB nach der Installation), und dies kann problematisch sein – beispielsweise für die Verwendung in AWS Lambda, das eine Größenbeschränkung von 250 MB hat. Wir streben danach, die Binärgröße so gering wie möglich zu halten; beim Hinzufügen neuer kompilierter Erweiterungen muss dies überprüft werden. Das Strippen von Debug-Symbolen in multibuild kann vielleicht verbessert werden (siehe dieses Issue). Es sollte Anstrengungen unternommen werden, wo möglich zu verschlanken und keine neuen großen Dateien hinzuzufügen. In Zukunft sind Dinge (sehr zögerlich) in Erwägung gezogen, die helfen könnten: die Trennung der gebündelten libopenblas und die Entfernung der Unterstützung für long double.

Module#

cluster#

dendrogram muss neu geschrieben werden, es hat eine Reihe von schwer zu behebenden offenen Problemen und Funktionswünschen.

constants#

Dieses Modul benötigt nur periodische Aktualisierungen der numerischen Werte.

differentiate#

Dieses Modul wurde mit dem Verständnis hinzugefügt, dass sein Umfang begrenzt sein würde. Das Ziel ist, grundlegende Ableitungen von Black-Box-Funktionen bereitzustellen, nicht alle Funktionen bestehender Ableitungswerkzeuge zu replizieren. Vor diesem Hintergrund umfassen zukünftige Arbeiten:

  • Verbesserung der Unterstützung für aufrufbare Funktionen, die zusätzliche Argumente akzeptieren (z. B. Hinzufügen von *args zu jacobian und hessian). Beachten Sie, dass dies aufgrund der Art und Weise, wie Elemente von Arrays eliminiert werden, wenn ihre entsprechenden Berechnungen konvergiert sind, nicht trivial ist.

  • Verbesserung der Implementierung von scipy.differentiate.hessian: Anstatt Ableitungen erster Ordnung zu verketten, sollte eine Ableitungs-Schablone zweiter Ordnung verwendet werden.

  • Erwägen Sie die Hinzufügung einer Option zur Verwendung relativer Schrittgrößen.

  • Erwägen Sie die Verallgemeinerung des Ansatzes zur Verwendung von "Polynom-Extrapolation"; d.h. anstatt Ableitungen einer bestimmten Ordnung aus der minimalen Anzahl von Funktionsaufrufen zu schätzen, sollte ein Ansatz der kleinsten Quadrate verwendet werden, um die Robustheit gegenüber numerischem Rauschen zu verbessern.

fft#

Dieses Modul ist in einem guten Zustand.

integrate#

  • Vervollständigen Sie den Funktionsumfang der neuen Funktion cubature und fügen Sie eine Schnittstelle hinzu, die auf eindimensionale Integrale zugeschnitten ist.

  • Migrieren Sie Funktionen zur Erzeugung von Quadraturregelpunkten und -gewichten aus special, verbessern Sie deren Zuverlässigkeit und fügen Sie Unterstützung für andere wichtige Regeln hinzu.

  • Vervollständigen Sie den Funktionsumfang von solve_ivp, einschließlich aller Funktionalitäten der odeint-Schnittstelle.

  • Schließen Sie überholte Funktionen und Klassen ordnungsgemäß ab.

interpolate#

FITPACK-Ersetzungen

Wir müssen funktionale Äquivalente der FITPACK-Fortran-Bibliothek fertigstellen. Ziel ist es, den algorithmischen Inhalt des FITPACK-Monolithen modular neu zu implementieren, um eine bessere Benutzerkontrolle und Erweiterbarkeit zu ermöglichen. Zu diesem Zweck benötigen wir:

  • 1D-Splines: Fügen Sie die periodische Spline-Anpassung zur Funktion make_splrep hinzu.

  • 2D-Splines: Stellen Sie funktionale Ersetzungen für die Klasse BivariateSpline für gestreute und gegitterte Daten bereit.

Sobald wir eine funktionsvollständige Reihe von Ersetzungen haben, können wir die Verwendung von FITPACK ordnungsgemäß einstellen.

Ideen für neue Features

  • Fügen Sie die Möglichkeit hinzu, Glättungs-Splines mit einer variablen Anzahl von Knoten zu make_smoothing_spline zu konstruieren. Derzeit verwendet make_smoothing_spline immer alle Datenpunkte für den Knotenvektor.

  • Experimentieren Sie mit vom Benutzer wählbaren Glättungskriterien: Fügen Sie die P-Spline-Strafform hinzu, um die Strafe der 2. Ableitung von make_smoothing_spline und Sprünge der 3. Ableitung von make_splrep zu ergänzen.

  • Untersuchen Sie Möglichkeiten, die Spline-Konstruktion für Stapel der unabhängigen Variablen zu vektorisieren. Diese Art von Funktionen wurde von den Entwicklern von scipy.stats angefordert.

  • Erlauben Sie die Angabe von Randbedingungen für die Spline-Anpassung.

  • Untersuchen Sie Probleme der Spline-Anpassung mit Nebenbedingungen, die die FITPACK-Bibliothek in Fortran bereitstellte, aber nie für die Python-Schnittstellen freigegeben wurden.

  • NURBS-Unterstützung kann hinzugefügt werden, wenn ausreichend Nutzerinteresse besteht.

Skalierbarkeit und Leistung

Wir müssen die Leistung auf großen Datensätzen überprüfen und gegebenenfalls verbessern. Dies ist relevant sowohl für N-D-Interpolatoren auf regelmäßigen Gittern als auch für QHull-basierte N-D-Interpolatoren für gestreute Daten. Für letztere müssen wir zusätzlich untersuchen, ob wir die 32-Bit-Integer-Beschränkungen der QHull-Bibliothek verbessern können.

io#

wavfile

  • PCM Float wird unterstützt, für alles andere verwenden Sie audiolab oder andere spezialisierte Bibliotheken.

  • Lösen Sie Fehler statt Warnungen aus, wenn Daten nicht verstanden werden.

Andere Untermodule (matlab, netcdf, idl, harwell-boeing, arff, matrix market) sind in einem guten Zustand.

linalg#

scipy.linalg ist in einem guten Zustand.

Benötigt

  • Reduzieren Sie die Duplizierung von Funktionen mit numpy.linalg, machen Sie APIs konsistent.

  • get_lapack_funcs sollte immer flapack verwenden.

  • Wickeln Sie mehr LAPACK-Funktionen ein.

  • Eine zu viel für die LU-Zerlegung, entfernen Sie eine.

Ideen für neue Features

  • Fügen Sie typen-generische Wrapper in der Cython BLAS und LAPACK hinzu.

  • Machen Sie viele der linearen Algebra-Routinen zu gufuncs.

  • Vervollständigen Sie die Unterstützung für Stapeloperationen (siehe gh-21466).

BLAS und LAPACK

Die Python- und Cython-Schnittstellen zu BLAS und LAPACK in scipy.linalg sind eines der wichtigsten Dinge, die SciPy bietet. Im Allgemeinen ist scipy.linalg in einem guten Zustand, wir können jedoch eine Reihe von Verbesserungen vornehmen.

  1. Fügen Sie Unterstützung für ILP64 (64-Bit) BLAS und LAPACK hinzu (siehe gh-21889).

  2. Vereinheitlichen Sie die beiden Sätze von Low-Level BLAS/LAPACK-Wrappern und lassen Sie wahrscheinlich die f2py-basierten fallen (siehe gh-20682).

  3. Verbessern und dokumentieren Sie die verschiedenen Arten, wie wir BLAS und LAPACK intern in SciPy von C- und C++-Code aus verknüpfen (siehe gh-20002 und gh-21130).

misc#

Alle Funktionen wurden aus scipy.misc entfernt, und der Namespace selbst wird schließlich entfernt werden.

ndimage#

Die zugrunde liegende Engine von ndimage ist eine leistungsstarke Interpolations-Engine. Benutzer erwarten eines von zwei Modellen: ein Pixelmodell mit Elementen (1, 1) mit Zentren (0.5, 0.5) oder ein Datenpunktmodell, bei dem Werte an Punkten eines Gitters definiert sind. Im Laufe der Zeit sind wir davon überzeugt, dass das Datenpunktmodell besser definiert und einfacher zu implementieren ist, dies sollte jedoch in der Dokumentation klar kommuniziert werden.

Wichtiger noch, SciPy implementiert eine *Variante* dieses Datenpunktmodells, bei dem Datenpunkte an beiden Extremen einer Achse unter dem Modus *periodische Umrandung* eine räumliche Position teilen. Z. B. in einem 1D-Array hätten Sie x[0] und x[-1] am selben Ort. Ein sehr häufiger Anwendungsfall ist jedoch, dass Signale periodisch sind, mit gleichem Abstand zwischen dem ersten und letzten Element entlang einer Achse (statt Null Abstand). Umrandungsmodi für diesen Anwendungsfall wurden in gh-8537 hinzugefügt, als nächstes sollten die Interpolationsroutinen aktualisiert werden, um diese Modi zu verwenden. Dies sollte mehrere Probleme lösen, darunter gh-1323, gh-1903, gh-2045 und gh-2640.

Die Morphologie-Schnittstelle muss standardisiert werden.

  • Binäre Dilatation/Erosion/Öffnung/Schließung nehmen ein "structure"-Argument, während ihre Grauwert-Äquivalente Größe (muss ein Tupel sein, nicht ein Skalar), Footprint oder Structure nehmen.

  • Ein Skalar sollte als Größe akzeptiert werden, gleichbedeutend mit der Bereitstellung desselben Wertes für jede Achse.

  • Bei binärer Dilatation/Erosion/Öffnung/Schließung ist das Strukturelement optional, während es bei Grauwert-Operationen obligatorisch ist. Grauwert-Morphologieoperationen sollten den gleichen Standardwert erhalten.

  • Andere Filter sollten diesen Standardwert ebenfalls erhalten, wo immer möglich.

odr#

Dieses Modul ist in einem vernünftigen Zustand, obwohl es etwas mehr Wartung vertragen könnte. Keine großen Pläne oder Wünsche hier.

optimize#

Wir streben eine kontinuierliche Verbesserung der von diesem Modul bereitgestellten Optimierer an. Für große Probleme schreitet der Stand der Technik weiter voran, und wir streben danach, durch Nutzung von Implementierungen aus domänenspezifischen Bibliotheken wie HiGHS und PRIMA Schritt zu halten. Andere Bereiche für zukünftige Arbeiten umfassen Folgendes:

  • Verbessern Sie die Schnittstellen bestehender Optimierer (z. B. shgo).

  • Verbessern Sie die Benutzerfreundlichkeit des Benchmark-Systems und fügen Sie Funktionen zum einfacheren Vergleichen von Ergebnissen hinzu (z. B. Übersichtsgrafiken).

signal#

Faltung und Korrelation: (Relevante Funktionen sind convolve, correlate, fftconvolve, convolve2d, correlate2d und sepfir2d.) Eliminieren Sie die Überschneidung mit ndimage (und anderswo). Wählen Sie aus numpy, scipy.signal und scipy.ndimage (und überall sonst, wo wir sie finden), die "Best of Class" für 1-D, 2-D und n-D Faltung und Korrelation, platzieren Sie die Implementierung irgendwo und verwenden Sie diese konsequent in SciPy.

B-Splines: (Relevante Funktionen sind gauss_spline, cspline1d, qspline1d, cspline2d, qspline2d, cspline1d_eval und spline_filter.) Verschieben Sie die guten Teile nach interpolate (mit entsprechenden API-Änderungen, um den Vorgängen in interpolate zu entsprechen) und eliminieren Sie jegliche Duplikation.

Filterdesign: Führen Sie firwin und firwin2 zusammen, damit firwin2 entfernt werden kann.

Linearzeitsysteme: Verbessern Sie die Leistung von ltisys weiter (weniger interne Transformationen zwischen verschiedenen Darstellungen). Schließen Sie Lücken in den Konvertierungsfunktionen für lti-Systeme.

Zweite-Ordnung-Abschnitte: Machen Sie die SOS-Filterung genauso leistungsfähig wie bestehende Methoden. Dies beinhaltet ltisys-Objekte, ein lfiltic-Äquivalent und numerisch stabile Konvertierungen von und zu anderen Filterdarstellungen. SOS-Filter könnten für ihre numerische Stabilität als Standard-Filtermethode für ltisys-Objekte betrachtet werden.

sparse#

Die Sparse-Matrix-Formate sind weitgehend funktionsvollständig, das Hauptproblem ist jedoch, dass sie sich wie numpy.matrix verhalten (was in NumPy irgendwann als veraltet markiert wird).

Wir wollen Sparse-Arrays, die sich wie numpy.ndarray verhalten. Eine erste Unterstützung für eine neue Reihe von Klassen (csr_array usw.) wurde in SciPy 1.8.0 hinzugefügt und in 1.12.0 mit Konstruktionsfunktionen für Arrays stabilisiert, in 1.14.0 mit 1D-Array-Unterstützung und in 1.15.0 mit 1D-Indizierung. Die Sparse-Array-Codebasis unterstützt nun alle Sparse-Matrix-Funktionen und zusätzlich 1D-Arrays und die ersten Schritte in Richtung nD-Arrays. Es gibt eine Migrationsanleitung, die Benutzern und Bibliotheken hilft, ihren Code auf Sparse-Arrays umzustellen.

Nächste Schritte zur Konvertierung von Sparse-Arrays

  • Erweitern Sie die Sparse-Array-API auf nD-Arrays.

    • Unterstützung für COO, CSR und DOK Formate.

    • Einige COO-Funktionen sind in 1.15 vorhanden.

  • Führen Sie Broadcasting-Unterstützung in Operationen ein, bei denen Sparse-Formate dies effektiv tun können.

  • Helfen Sie anderen Bibliotheken bei der Konvertierung von Sparse-Matrizen zu Sparse-Arrays. NetworkX, dipy, scikit-image, pyamg, cvxpy und scikit-learn sind in Bearbeitung oder haben die Konvertierung zu Sparse-Arrays abgeschlossen.

  • Fügen Sie Deprecation-Warnungen für Sparse-Matrizen hinzu.

  • Arbeiten Sie mit NumPy an der Deprecation/Entfernung von numpy.matrix.

  • Depreziere und entferne dann Sparse-Matrix zugunsten von Sparse-Array.

  • Beginnen Sie den API-Shift der Konstruktionsfunktionsnamen (diags, block usw.)

    • Hinweis: Insgesamt durchlaufen die Konstruktionsfunktionen zwei Namensverschiebungen. Erstens, um von der Matrixerstellung zu neuen Funktionen für die Array-Erstellung zu wechseln (d.h. eye -> eye_array). Dann eine zweite Verschiebung, um die Namen an den Namen der array_api anzupassen (d.h. eye_array zu eye), nachdem Sparse-Matrizen entfernt wurden. Wir werden die *_array-Versionen noch lange als (möglicherweise versteckte) Aliase beibehalten.

  • Fügen Sie Konstruktionsfunktionsnamen hinzu, die den array_api-Namen entsprechen.

  • Depreziere die Übergangsfunktionsnamen.

Ein alternativer (ambitionierterer und unklarer, ob er zustande kommen wird) Plan wird in pydata/sparse bearbeitet. Um diese Bemühungen zu unterstützen, streben wir an, PyData Sparse in allen Funktionen zu unterstützen, die Sparse-Arrays akzeptieren. Die Unterstützung für pydata/sparse in scipy.sparse.linalg und scipy.sparse.csgraph ist weitgehend abgeschlossen.

Bezüglich der verschiedenen Sparse-Matrix-Formate: Es gibt viele davon. Diese sollten beibehalten werden, aber Verbesserungen/Optimierungen sollten in CSR/CSC fließen, die die bevorzugten Formate sind. LIL könnte die Ausnahme sein, es ist von Natur aus ineffizient. Es könnte fallen gelassen werden, wenn DOK erweitert wird, um alle Operationen zu unterstützen, die LIL derzeit bietet.

sparse.csgraph#

Dieses Modul ist in einem guten Zustand.

sparse.linalg#

Es gibt eine beträchtliche Anzahl offener Issues für _arpack und lobpcg.

_isolve:

  • Das Callback-Schlüsselwort ist inkonsistent.

  • Das tol-Schlüsselwort ist fehlerhaft, sollte eine relative tol sein.

  • Fortran-Code ist nicht re-entrant (aber wir lösen nicht, vielleicht wiederverwenden aus PyKrilov).

_dsolve:

  • Lizenzkompatibles Sparse Cholesky oder inkrementelles Cholesky hinzufügen.

  • Lizenzkompatibles Sparse QR hinzufügen.

  • Schnittstelle zu SuiteSparse UMFPACK verbessern.

  • Schnittstellen zu SuiteSparse CHOLMOD und SPQR hinzufügen.

spatial#

QHull-Wrapper sind in einem guten Zustand, ebenso wie KDTree.

Eine Neufassung der Metriken für spatial.distance in C++ ist im Gange – dies sollte die Leistung verbessern, das Verhalten (z. B. für verschiedene Nicht-Float64-Input-Dtypes) konsistenter machen und einige verbleibende Probleme mit den mathematischen Definitionen, die von einigen der Metriken implementiert werden, beheben.

special#

Obwohl es immer noch viele Funktionen gibt, die Verbesserungen bei der Genauigkeit benötigen, sind die wichtigsten Hinderungsgründe wahrscheinlich hypergeometrische Funktionen, parabolische Zylinderfunktionen und sphäroidale Wellenfunktionen. Drei mögliche Wege, dies zu handhaben:

  1. Gute Implementierungen für doppelte Genauigkeit erhalten. Dies ist für parabolische Zylinderfunktionen machbar (im Gange). Ich denke, es ist möglich für hypergeometrische Funktionen, wenn auch vielleicht nicht rechtzeitig. Für sphäroidale Wellenfunktionen ist dies mit der aktuellen Theorie nicht möglich.

  2. Portieren Sie die Arbitrary-Precision-Bibliothek von Boost und verwenden Sie sie intern, um doppelte Genauigkeit zu erreichen. Dies könnte als Übergangslösung für hypergeometrische Funktionen notwendig sein; die Idee, Arbitrary Precision zu verwenden, wurde bereits von @nmayorov und in gh-5349 vorgeschlagen. Wahrscheinlich notwendig für sphäroidale Wellenfunktionen, dies könnte wiederverwendet werden: radelman/scattering.

  3. Fügen Sie klare Warnungen in der Dokumentation über die Grenzen der bestehenden Implementierungen hinzu.

stats#

Das Unterpaket scipy.stats zielt darauf ab, grundlegende statistische Methoden bereitzustellen, wie sie in Standard-Statistiklehrbüchern wie Johnsons "Miller & Freund's Probability and Statistics for Engineers", Sokals & Rohlfs "Biometry" oder Zar's "Biostatistical Analysis" behandelt werden. Es versucht nicht, die fortgeschrittene Funktionalität von nachgelagerten Paketen (z. B. StatsModels, LinearModels, PyMC3) zu duplizieren; stattdessen kann es eine solide Grundlage bieten, auf der diese aufbauen können. (Beachten Sie, dass dies grobe Richtlinien sind, keine strengen Regeln. "Fortgeschritten" ist ein schlecht definierter und subjektiver Begriff, und "fortgeschrittene" Methoden können auch in SciPy enthalten sein, insbesondere wenn kein anderes weit verbreitetes und gut unterstütztes Paket das Thema abdeckt. Beachten Sie auch, dass *einige* Duplizierung mit nachgelagerten Projekten unvermeidlich und nicht unbedingt schlecht ist.)

Die folgenden Verbesserungen werden SciPy helfen, diese Rolle besser zu erfüllen.

  • Verbessern Sie statistische Tests: Fügen Sie Methoden zur Erzeugung von Konfidenzintervallen hinzu und implementieren Sie exakte und randomisierte p-Wert-Berechnungen – unter Berücksichtigung der Möglichkeit von Bindungen – wo rechnerisch machbar.

  • Erweitern Sie die neue Infrastruktur für univariate Verteilungen, fügen Sie Unterstützung für diskrete Verteilungen und zirkuläre kontinuierliche Verteilungen hinzu. Fügen Sie eine Auswahl der am weitesten verbreiteten statistischen Verteilungen unter der neuen Infrastruktur hinzu, führen Sie rigorose Genauigkeitstests durch und dokumentieren Sie die Ergebnisse. Ermöglichen Sie Benutzern die Erstellung benutzerdefinierter Verteilungen, die die neue Infrastruktur nutzen.

  • Verbessern Sie die Infrastruktur für multivariate Verteilungen, um eine konsistente API, gründliche Tests und eine vollständige Dokumentation zu gewährleisten.

  • Stellen Sie weiterhin sicher, dass die APIs von Funktionen konsistenter sind, mit Standardunterstützung für Stapelberechnungen, NaN-Richtlinien und Beibehaltung des Dtypes.