Numpy: np.copy (maskiertes Array) hat ein unerwartetes Verhalten

Noch offen in 1.9-Entwicklung

Ich bin mir jedoch nicht sicher, wie ich dies ohne spezielle maskierte Arrays beheben kann.

Würde eine Änderung der Logik von np.copy, um subok=True in den Aufruf des Arrays aufzunehmen, dieses Problem beheben?
Von:

return array(a, order=order, copy=True)

Zu:

return array(a, order=order, subok=True, copy=True)

Wenn ja, sollte subok ein Parameter für np.copy und wie sollte der Standardwert True oder False sein? True gibt das erste bevorzugte Ergebnis zurück. False behält das aktuelle Verhalten bei, lässt jedoch das erwartete Verhalten zu, fügt jedoch ein Argument hinzu.

Ich bin nicht dafür, np.copy einen subok -Parameter hinzuzufügen, wenn wir bereits zwei vollständig realisierbare Lösungen haben:

• Verwenden Sie die Methode .copy()
• benutze np.array(a, subok=True) (standardmäßig kopiert)

Ich würde eigentlich das Gegenteil argumentieren, da ich denke, dass die meisten "Kopien" den Eindruck erwecken, dass man etwas zurückbekommt, das eigentlich eine Kopie ist und somit vom gleichen Typ. Ich sehe es auch als einen kleinen, aber nützlichen Beitrag, um die Gesamtheit der Numpys konsistenter in der Lage zu machen, mit Unterklassen umzugehen (genau wie ich es zuvor mit np.broadcast_arrays getan habe, wo kein guter Ersatz verfügbar war). Angesichts der Notwendigkeit, abwärtskompatibel zu bleiben, denke ich jedoch, dass wir an einem Standardwert von subok=False .

Wie auch immer, @jjhelmus , warum nicht schnell PR machen und sehen, was andere denken?

@shoyer : np.copy sollte wahrscheinlich auf Ihrer Liste der benötigten Funktionen stehen
Eine Art Entenarray-Unterstützung - für ein Entenarray denke ich, np.copy
und np.array sollte wahrscheinlich verschiedene Dinge tun. Vielleicht sollte es einfach anrufen
arr.copy?

Am Do, 15. Oktober 2015 um 7:00 Uhr, Marten van Kerkwijk <
[email protected]> schrieb:

Ich würde eigentlich das Gegenteil argumentieren, da ich denke, dass die meisten "Kopien" geben
der Eindruck, dass man etwas zurückbekommt, das eigentlich eine Kopie ist,
und damit vom gleichen Typ. Ich sehe es auch als kleinen, aber nützlichen Beitrag
um das ganze numpy konsequenter in der Lage zu machen, mit Unterklassen umzugehen
(Genau wie früher bei np.broadcast_arrays, wo es keinen guten Ersatz gibt
war verfügbar). Angesichts der Notwendigkeit, abwärtskompatibel zu bleiben, habe ich
Denken Sie, wir stecken mit der Standardeinstellung subok = False fest.

Wie auch immer, @jjhelmus https://github.com/jjhelmus , warum nicht eine schnelle PR machen
und sehen, was andere denken?

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/3474#issuecomment -148395201.

Nathaniel J. Smith - http://vorpus.org

Ja, ich würde +1 erhalten, wenn np.copy versucht, die Kopiermethode für Enten-Arrays aufzurufen.

Immer noch kein Grund, subok nicht ebenfalls zu unterstützen. Und natürlich kann man einfach __copy__ wenn es existiert.

Erstellt PR # 6509, der der Funktion einen Subok- Parameter mit dem Standardwert False hinzufügt. Ich vermute, dies wird eine Diskussion über das Thema eröffnen. Ich bin mir nicht sicher, ob dies normalerweise auf der PR, dem Problem oder der Mailingliste geschieht.

Die API-Diskussion sollte auf der Mailingliste stehen.
Am 18. Oktober 2015, 19:37 Uhr, "Jonathan J. Helmus" [email protected]
schrieb:

Erstellt PR # 6509 https://github.com/numpy/numpy/pull/6509, die a hinzufügt
_subok_ Parameter für die Funktion mit dem Standardwert _False_. Ich bin
Wenn Sie dies erraten, wird dies zu einer Diskussion über das Thema führen. Ich bin mir nicht sicher, ob das so ist
findet normalerweise auf der PR, dem Problem oder der Mailingliste statt.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/3474#issuecomment -149080511.

Ich werde morgen eine E-Mail an die Liste zum Thema senden.