Warum hat numpy für viele ndarray-Methoden eine entsprechende Funktion?

8

Einige Beispiele:

%Vor%

... und noch einige mehr. Ist es die Unterstützung von Legacy-Code oder gibt es einen besseren Grund dafür? Und wähle ich nur auf der Grundlage, wie mein Code "aussieht", oder ist einer der beiden Wege besser als der andere?

Ich kann mir vorstellen, dass numpy.dot() reduce verwenden soll (z. B. reduce(numpy.dot, A, B, C, D) ), aber ich denke nicht, dass dies für etwas wie numpy.sum() so nützlich wäre.

    
Roberto 18.03.2015, 11:22
quelle

3 Antworten

6

Wie bereits erwähnt, sind die gleichnamigen NumPy-Funktionen und Array-Methoden oft äquivalent (sie rufen den gleichen zugrunde liegenden Code auf). Man könnte gegenüber dem anderen bevorzugt werden, wenn es das Lesen erleichtert.

In einigen Fällen verhalten sich die beiden jedoch etwas anders. Insbesondere betont die Verwendung der Methode ndarray manchmal die Tatsache, dass die Methode das Array an Ort und Stelle ändert.

Zum Beispiel gibt np.resize ein neues Array mit der angegebenen Form. Auf der anderen Seite ändert ndarray.resize die Form des Arrays an Ort und Stelle. Die jeweils verwendeten Füllwerte sind ebenfalls unterschiedlich.

Auf ähnliche Weise sortiert a.sort() das Array a direkt, während np.sort(a) eine sortierte Kopie zurückgibt.

    
Alex Riley 18.03.2015, 13:31
quelle
4

In den meisten Fällen ist die Methode die grundlegende kompilierte Version. Die Funktion verwendet diese Methode, wenn sie verfügbar ist, hat aber auch eine Art von Sicherung, wenn das Argument kein Array ist. Es hilft, den Code und / oder die Dokumente der Funktion oder Methode zu betrachten.

Wenn ich zum Beispiel in Ipython nach dem Code für die sum-Methode suche, sehe ich, dass es kompilierter Code ist

%Vor%

Mach das gleiche auf np.sum Ich bekomme viele Zeilen Dokumentation und etwas Python-Code:

%Vor%

Wenn ich np.sum(x) anrufe, wobei x ein Array ist, ruft es x.sum() :

auf %Vor%

np.amax ähnlich (aber einfacher). Beachten Sie, dass das Formular np. ein Objekt behandeln kann, das kein Array ist (das die Methode nicht hat), z. eine Liste: np.amax([1,2,3]) .

np.dot und x.dot werden beide als 'eingebaute' Funktion angezeigt, daher können wir nichts über Priorität sagen. Sie rufen wahrscheinlich beide eine zugrundeliegende C-Funktion auf.

np.reshape ist ein weiterer, der, wenn möglich, delegiert:

%Vor%

So np.reshape(x,(2,3)) ist in der Funktionalität identisch mit x.reshape((2,3)) . Der Ausdruck _wrapit ermöglicht jedoch np.reshape([1,2,3,4],(2,2)) .

np.sort gibt eine Kopie zurück, indem eine Inplace-Sortierung für eine Kopie durchgeführt wird:

%Vor%

x.resize ist eingebaut, während np.resize eine np.concatenate und reshape erledigt.

Wenn Ihr Array eine Unterklasse ist, wie Matrix oder maskiert, kann es eine eigene Variante haben. Die Aktion einer Matrix .sum ist:

%Vor%     
hpaulj 18.03.2015 15:36
quelle
0

Ausarbeitung von Peters Kommentar zur Sichtbarkeit:

  

Wir könnten es konsistenter machen, indem wir Methoden aus NDarray entfernen und uns nur auf Funktionen beschränken. Aber das ist unmöglich, weil es den vorhandenen Code, der Methoden verwendet, durchbrechen würde.

     

Oder wir könnten alle Funktionen auch als Methoden verwenden. Dies ist jedoch nicht möglich, da neue Benutzer und Pakete ständig neue Funktionen definieren. Darüber hinaus verstößt die weitere Multiplikation dieser doppelten Methoden gegen "es sollte einen offensichtlichen Weg geben, dies zu tun".

     

Wenn wir in der Zeit zurückgehen könnten, würde ich wahrscheinlich dafür plädieren, diese Methoden überhaupt nicht zu verwenden und ausschließlich Funktionen zu verwenden. ... All dies spricht dafür, ausschließlich Funktionen zu verwenden

numpiges Problem: mehr Konsistenz mit Array-Methoden # 7452

    
endolith 02.07.2017 21:19
quelle