Numpy: Unterstützung des Entenarray-Zwangs

Die vorgeschlagene Implementierung würde ungefähr so ​​aussehen:

import numpy as np

# hypothetical np.duckarray() function
def duckarray(array_like):
  if hasattr(array_like, '__duckarray__'):
    # return an object that can be substituted for np.ndarray
    return array_like.__duckarray__()
  return np.asarray(array_like)

Anwendungsbeispiel:

class SparseArray:
  def __duckarray__(self):
    return self
  def __array__(self):
    raise TypeError

np.duckarray(SparseArray())  # returns a SparseArray object
np.array(SparseArray())  # raises TypeError

Hier habe ich np.duckarray und __duckarray__ als Platzhalter verwendet, aber wir können es wahrscheinlich besser für diese Namen machen. Siehe die Terminologie aus NEP 22:

"Duck Array" funktioniert im Moment gut als Platzhalter, ist aber ziemlich umständlich und kann neue Benutzer verwirren. Daher möchten wir möglicherweise etwas anderes für die eigentlichen API-Funktionen auswählen. Leider wird "Array-like" bereits für das Konzept von "alles, was in ein Array gezwungen werden kann" (einschließlich z. B. Listenobjekte) verwendet, und "anyarray" wird bereits für das Konzept von "etwas, das die Implementierung von ndarray teilt" verwendet hat eine andere Semantik “, was das Gegenteil eines Entenarrays ist (z. B. ist np.matrix ein„ Anyarray “, aber kein„ Entenarray “). Dies ist ein klassischer Fahrradschuppen, daher verwenden wir im Moment nur "Entenarray". Einige mögliche Optionen sind jedoch: Arrayish, Pseudoarray, Nominalarray, Ersatzarray, Arraymimic,…

Einige andere Namensideen: np.array_compatible() , np.array_api() ....

np.array_compatible könnte funktionieren, obwohl ich nicht sicher bin, ob es mir besser gefällt als duckarray . np.array_api Ich mag nicht, gibt imho die falsche Idee.

Da wir uns nach langer Zeit keinen besseren Namen ausgedacht haben, sollten wir vielleicht einfach den Namen "duck-array" segnen ......

Ich mag das kompatible Wort, vielleicht können wir uns auch Variationen in dieser Richtung vorstellen as_compatible_array (impliziert etwas, dass alle kompatiblen Objekte Arrays sind). Das as ist vielleicht ärgerlich (teilweise, weil alle as -Funktionen keine Leerzeichen haben). "Ente" scheint in Bibliotheken nett zu sein, aber ich finde es etwas seltsam für zufällige Leute, die es sehen. Daher denke ich, dass ich "Ente" nicht mag, wenn und nur wenn wir möchten, dass nachgeschaltete Benutzer es häufig verwenden (dh selbst wenn ich anfange, ein kleines Tool für mich selbst / ein kleines Labor zu schreiben).

Vielleicht quack_array :)

Um das Thema ein wenig zu erweitern, gibt es einen anderen Fall, der nicht mit np.duckarray wird. Hierbei handelt es sich um die Erstellung neuer Arrays mit einem Typ, der auf einem vorhandenen Typ basiert, ähnlich wie Funktionen wie np.empty_like tun. Derzeit können wir Folgendes tun:

>>> import numpy as np, cupy as cp
>>> a  = cp.array([1, 2])
>>> b = np.ones_like(a)
>>> type(b)
<class 'cupy.core.core.ndarray'>

Wenn wir dagegen ein array_like , aus dem wir über die NumPy-API ein CuPy-Array erstellen möchten, ist dies nicht möglich. Ich denke, es wäre hilfreich, etwas zu haben wie:

import numpy as np, cupy as cp
a  = cp.array([1, 2])
b = [1, 2]
c = np.asarray(b, like=a)

Irgendwelche Ideen / Vorschläge dazu?

Vielleicht np.copy_like? Wir möchten sorgfältig definieren, welche Eigenschaften
(z. B. einschließlich dtype oder nicht) werden aus dem anderen Array kopiert.

Am Montag, 1. Juli 2019 um 05:40 Uhr Peter Andreas Entschev <
[email protected]> schrieb:

Um das Thema etwas zu erweitern, gibt es einen anderen Fall, der nicht behandelt wird
mit np.duckarray, bei dem neue Arrays mit einem Typ erstellt werden
auf einem vorhandenen Typ, ähnlich wie Funktionen wie np.empty_like.
Derzeit können wir Folgendes tun:

importiere numpy als np, cupy als cp >>> a = cp.array ([1, 2]) >>> b = np.ones_like (a) >>> type (b)

Auf der anderen Seite, wenn wir ein Array haben, das wir erstellen möchten
Ein CuPy-Array über die NumPy-API ist nicht möglich. Ich denke es wäre
hilfreich, um etwas zu haben wie:

importiere numpy als np, cupy als cp
a = cp.array ([1, 2])
b = [1, 2]
c = np.asarray (b, wie = a)

Irgendwelche Ideen / Vorschläge dazu?

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/13831?
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAJJFVRSYHUYHMPWQTW2NLLP5H3LRANCNFSM4H3HQWAA
.

np.copy_like klingt auch gut. Ich stimme zu, wir sollten höchstwahrscheinlich Möglichkeiten haben, Dinge wie dtype zu kontrollieren.

Entschuldigen Sie die Frage des Anfängers, aber sollte so etwas wie np.copy_like eine Änderung von NEP-22 sein, sollte es in der Mailingliste besprochen werden, oder was wäre der am besten geeignete Ansatz dafür?

Wir haben nicht wirklich strenge Regeln dafür, aber ich würde mich dazu neigen, np.copy_like und np.duckarray (oder wie auch immer wir es nennen) in einem neuen NEP zum Erzwingen / Erstellen von Entenarrays zusammenzufassen Das ist präskriptiv wie NEP 18 und nicht "informativ" wie NEP 22. Es muss nicht lange dauern, der größte Teil der Motivation ergibt sich bereits aus der Bezugnahme auf NEP 18/22.

Ein Hinweis zu np.copy_like() : Es sollte auf jeden Fall mit __array_function__ (oder ähnlichem) versendet werden, sodass Operationen wie np.copy_like(sparse_array, like=dask_array) entweder für jeden Array-Typ definiert werden können.

Großartig, danke für die Info, und ich stimme Ihrem Versandvorschlag zu. Ich werde an einem NEP für die Implementierung von np.duckarray und np.copy_like und diese Woche einen PR-Entwurf dafür einreichen.

Super, danke Peter!

Am Montag, 1. Juli 2019 um 9:29 Uhr Peter Andreas Entschev <
[email protected]> schrieb:

Großartig, danke für die Info, und ich stimme Ihrem Versandvorschlag zu. ich
wird an einem NEP für die Implementierung von np.duckarray und arbeiten
np.copy_like und reiche diese Woche einen PR-Entwurf dafür ein.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/numpy/numpy/issues/13831?email_source=notifications&email_token=AAJJFFWW
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAJJFVR2KTPAZ4JPWDYYMFLP5IWHNANCNFSM4H3HQWAA
.

Es ist mir ein Vergnügen und vielen Dank für die Ideen und die Unterstützung bei dieser Arbeit!

Die Funktionen array_like und copy_like wären meiner Meinung nach etwas seltsam im Haupt-Namespace, da wir keine Standardimplementierung haben können (zumindest keine, die das Richtige wäre cupy / dask / sparse / etc), richtig? Sie sind nur nützlich, wenn sie überschrieben werden. Oder fehlt mir eine Möglichkeit, hier beliebige Nicht-Numpy-Array-Objekte zu erstellen?

Es ist wahr, diese wären nur dann wirklich nützlich, wenn Sie das Tippen von Enten unterstützen möchten. Aber sicherlich würden np.duckarray und np.copy_like funktionieren, selbst wenn die Argumente nur NumPy-Arrays sind - sie würden nur np.array / np.copy .

Alle Array-Implementierungen haben eine copy -Methode, oder? Die Verwendung dieser Funktion anstelle von copy_like sollte funktionieren. Warum also eine neue Funktion hinzufügen?

array_like Ich kann die Notwendigkeit erkennen, aber wir möchten vielleicht diskutieren, wo es platziert werden soll.

np.duckarray macht für mich Sinn.

Ich würde mich dazu neigen, np.copy_like und np.duckarray (oder wie auch immer wir es nennen) zu einem neuen NEP zusammenzufassen, um Enten-Arrays zu erzwingen / zu erstellen, das wie NEP 18 vorgeschrieben ist und nicht wie NEP 22 "informativ".

+1

array_like Ich kann die Notwendigkeit erkennen, aber wir möchten vielleicht diskutieren, wo es platziert werden soll.

Das ist eigentlich der Fall, den ich gerne mit so etwas wie np.copy_like angesprochen hätte. Ich habe nicht getestet, aber wahrscheinlich wird np.copy bereits korrekt versendet, wenn das Array nicht NumPy ist.

Um klar zu sein, beziehen Sie sich auch auf eine Funktion np.array_like ? Ich habe einen solchen Namen absichtlich vermieden, weil ich dachte, dass er für alle vorhandenen Verweise auf array_like -Arrays verwirrend sein könnte. Jetzt ist mir jedoch klar, dass np.copy_like eine notwendige Kopie implizieren kann, und ich denke, es wäre gut, ein ähnliches Verhalten wie np.asarray , bei dem die Kopie nur dann erfolgt, wenn es noch kein NumPy ist Array. In dem hier diskutierten Fall ist es am besten, die Kopie nur zu erstellen, wenn a nicht der gleiche Typ ist wie b in einem Anruf wie np.copy_like(a, like=b) .

Ich habe nicht getestet, aber wahrscheinlich wird np.copy bereits korrekt versendet, wenn das Array nicht NumPy ist.

Es sollte dekoriert sein, um __array_function__ .

Um klar zu sein, beziehen Sie sich auch auf eine Funktion np.array_like ? Ich habe einen solchen Namen absichtlich vermieden, weil ich dachte, er könnte alle vorhandenen Verweise auf array_like-arrays verwirren.

Ja. Und ja, ich stimme zu, es kann verwirrend sein.

Jetzt ist mir jedoch klar, dass np.copy_like eine notwendige Kopie implizieren kann.

Ja, dieser Name impliziert eine Datenkopie.

kann eine notwendige Kopie implizieren, und ich denke, es wäre gut, ein Verhalten ähnlich wie np.asarray ,

Ich dachte, das wäre np.duckarray .

Ich denke, das obige Beispiel von Peter könnte helfen, dies zu verdeutlichen. Unten kopiert und der Einfachheit halber in np.copy_like eingebettet.

import numpy as np, cupy as cp
a  = cp.array([1, 2])
b = [1, 2]
c = np.copy_like(b, like=a)

Ich dachte, das wäre np.duckarray.

Tatsächlich wird np.duckarray im Grunde nichts tun und nur das Array selbst zurückgeben (falls überschrieben), andernfalls np.asarray (was zu einem NumPy-Array führt). Wir können damit beispielsweise kein CuPy-Array aus einer Python-Liste abrufen. Wir benötigen noch eine Funktion, die für ein array_like an CuPy (oder ein anderes like= -Array) gesendet werden kann.

Vielen Dank an @jakirkham für das aktualisierte Beispiel.

c = np.copy_like(b, like=a)

Das wird also über a.__array_function__ an CuPy gesendet und schlägt fehl, wenn dieses Attribut nicht vorhanden ist (z. B. a=<scipy.sparse matrix> würde nicht funktionieren)? Es scheint, als bräuchten wir für diese Art von Dingen einen neuen Namespace oder ein neues Interoperabilitäts-Dienstprogrammpaket. Entweder das oder überlassen Sie es einem umfassenderen zukünftigen Versandmechanismus, bei dem man einfach Folgendes tun könnte:

with cupy_backend:
   np.array(b)

Die Einführung neuer Funktionen im Haupt-Namespace, die für NumPy selbst keinen Sinn ergeben, um die Umgehung einer Beschränkung von __array_function__ scheint etwas ungesund zu sein.

Das wird also über a.__array_function__ an CuPy gesendet und schlägt fehl, wenn dieses Attribut nicht vorhanden ist (z. B. a=<scipy.sparse matrix> würde nicht funktionieren)?

Ich würde nicht sagen, dass es unbedingt scheitern muss. Wir könnten beispielsweise standardmäßig NumPy verwenden und eine Warnung auslösen (oder sie überhaupt nicht auslösen).

Es scheint, als bräuchten wir für diese Art von Dingen einen neuen Namespace oder ein neues Interoperabilitäts-Dienstprogrammpaket. Entweder das oder überlassen Sie es einem umfassenderen zukünftigen Versandmechanismus

Sicherlich wäre es schön, einen voll ausgestatteten Versandmechanismus zu haben, aber ich kann mir vorstellen, dass dies aufgrund seiner Komplexität und Abwärtskompatibilitätsprobleme noch nicht geschehen ist. Ich war nicht da, als Diskussionen stattfanden, also nur raten.

Die Einführung neuer Funktionen im Hauptnamespace, die für NumPy selbst keinen Sinn ergeben, um die Umgehung einer Einschränkung von __array_function__ zu unterstützen, scheint etwas ungesund zu sein.

Ich verstehe Ihren Standpunkt sicherlich, aber ich denke auch, dass es Benutzer abschrecken könnte, wenn wir zu viele Dinge vom Haupt-Namespace entfernen. Vielleicht irre ich mich und das ist nur ein Eindruck. In beiden Fällen schlage ich überhaupt nicht vor, Funktionen zu implementieren, die mit NumPy nicht funktionieren, aber möglicherweise nur nicht unbedingt erforderlich, wenn NumPy alleine verwendet wird.

Die Einführung neuer Funktionen im Hauptnamespace, die für NumPy selbst keinen Sinn ergeben, um die Umgehung einer Einschränkung von __array_function__ zu unterstützen, scheint etwas ungesund zu sein.

In diesem Sinne würde auch np.duckarray nicht in den Hauptnamespace gehören.

In diesem Sinne würde auch np.duckarray nicht in den Hauptnamespace gehören.

Ich denke, dass man besser verteidigt werden kann (analog zu asarray und es würde im Grunde prüfen, ob dies unserer Definition eines ndarray-ähnlichen Ententyps entspricht), aber ja. Wenn wir auch array_function_dispatch verfügbar machen möchten und Dinge np.lib.mixins.NDArrayOperatorsMixin und planen, mehr Mixins zu schreiben, könnte ein sinnvolles neues Submodul für alle Dinge, die mit Interoperabilität zu tun haben, sinnvoll sein.

Sicherlich wäre es schön, einen voll ausgestatteten Versandmechanismus zu haben, aber ich kann mir vorstellen, dass dies aufgrund seiner Komplexität und Abwärtskompatibilitätsprobleme noch nicht geschehen ist. Ich war nicht da, als Diskussionen stattfanden, also nur raten.

Ich denke, es gibt mehrere Gründe. __array_function__ ähnelt den Dingen, die wir bereits hatten, daher ist es einfacher, darüber nachzudenken. Es hat einen geringen Overhead. Es könnte in einem Zeitraum von ~ 6 Monaten entworfen und implementiert werden, und @shoyer machte ein starkes

Ein sinnvolles neues Submodul für alle Aspekte der Interoperabilität könnte sinnvoll sein.

Keine wirklichen Einwände von mir, ich denke, es ist besser, irgendwo Funktionalität zu haben, als nirgendwo. :) :)

Ich denke, es gibt mehrere Gründe. __array_function__ ähnelt den Dingen, die wir bereits hatten, daher ist es einfacher, darüber nachzudenken. Es hat einen geringen Overhead. Es könnte in einem Zeitraum von ~ 6 Monaten entworfen und implementiert werden, und @shoyer machte ein starkes

Aber wenn wir __array_function__ breiter nutzen wollen, haben wir jetzt andere Alternativen zur Implementierung von Dingen wie np.duckarray und np.copy_like (oder wie auch immer wir es nennen würden)? Ich bin offen für alle Alternativen, aber im Moment sehe ich natürlich keine, anstatt den Dispatching-Weg mit vollem Funktionsumfang zu wählen, was wahrscheinlich lange dauern und den Umfang von __array_function__ einschränken wird.

Aber wenn wir __array_function__ breiter nutzen wollen, haben wir jetzt andere Alternativen zur Implementierung von Dingen wie np.duckarray und np.copy_like (oder wie auch immer wir es nennen würden)?

Ich denke, Sie benötigen in der Tat eine Reihe solcher Dienstprogrammfunktionen, um von einem Teil der Anwendungsfälle zu> 80% der Anwendungsfälle zu gelangen. Ich glaube nicht, dass es einen Weg gibt, das zu umgehen. Ich mag es einfach nicht, den Haupt-Namespace zu überladen, also schlage vor, einen besseren Platz für diese zu finden.

Ich bin offen für alle Alternativen, aber im Moment sehe ich natürlich keine, anstatt den Dispatching-Weg mit vollem Funktionsumfang zu wählen, was wahrscheinlich lange dauern und den Umfang von __array_function__ einschränken wird.

Ich meine, wir stopfen hier nur ein paar offensichtliche Löcher, oder? Wir werden niemals alle "komplexeren Fälle" behandeln. Angenommen, Sie möchten np.errstate oder np.dtype überschreiben, das wird mit dem protokollbasierten Ansatz einfach nicht passieren.

Was Alternativen betrifft, ist rückt näher und wir werden versuchen, das scipy.fft zu erstellen https://github.com/Quansight-Labs/uarray/tree/master/unumpy

Der Versandansatz mit uarray ist sicherlich interessant. Obwohl ich immer noch besorgt bin, wie wir mit Meta-Arrays umgehen (wie Dask, Xarray usw.). Bitte lesen Sie diesen Kommentar für Details. Es ist unklar, ob dies behoben wurde (bitte korrigieren Sie mich, wenn ich etwas verpasst habe). Ich würde gerne mit anderen bei SciPy zusammenarbeiten, um herauszufinden, wie wir dieses Problem lösen.

Bitte lesen Sie diesen Kommentar für Details. Es ist unklar, ob dies behoben wurde (bitte korrigieren Sie mich, wenn ich etwas verpasst habe).

Ich denke, die Änderungen der letzten Woche lösen das, aber nicht sicher - lassen wir das für einen anderen Thread.

Ich würde gerne mit anderen bei SciPy zusammenarbeiten, um herauszufinden, wie wir dieses Problem lösen.

Ich werde da sein, wäre toll, Sie persönlich zu treffen.

Vielleicht wären np.coerce_like() oder np.cast_like() bessere Namen als copy_like , so dass klar ist, dass Kopien nicht unbedingt erforderlich sind. Die gewünschte Funktionalität ist in der Tat der Methode .cast() ziemlich ähnlich, außer dass wir sowohl Array-Typen als auch d-Typen konvertieren möchten. Sie sollte eher eine Funktion als ein Protokoll sein, damit sie von beiden Argumenten implementiert werden kann.

Der Versandansatz mit uarray ist sicherlich interessant. Obwohl ich immer noch besorgt bin, wie wir mit Meta-Arrays umgehen (wie Dask, Xarray usw.).

uarray unterstützt mehrere Backends, so etwas sollte funktionieren

with ua.set_backend(inner_array_backend), ua.set_backend(outer_array_backend):
  s = unumpy.sum(meta_array)

Dies kann erreicht werden, indem das Meta-Array ua.skip_backend in seiner Implementierung aufruft oder wenn das Backend des Meta-Arrays bei Nichtübereinstimmung des Typs NotImplemented zurückgibt.

cc: @hameerabbasi

Ich werde darauf näher eingehen: In der Regel wird für dask.array alles mit da ohne ein skip_backend geschrieben. Alles mit NumPy würde ein skip_backend benötigen.

Oder für da Sie jederzeit den Versand überspringen und Ihre eigene Implementierung direkt aufrufen und haben überall skip_backend(dask.array) .

Für Dispatching-Funktionen, an die kein Array angehängt ist, wie ones , cast , müssen Sie nur ein Backend festlegen und fertig sein. Gleiches gilt für np.errstate und np.dtype . Es gibt ein Beispiel für np.ufunc in unumpy .

In der ursprünglichen Ausgabe bietet uarray das Protokoll __ua_convert__ , das genau dies tut. Eine Alternative wäre, dass Backends asarray direkt überschreiben.

Vielen Dank für die Hinweise zu uarray , @rgommers , @ peterbell10 , @hameerabbasi.

Aber wie ich sehe, müssen Sie das richtige Backend einstellen, bevor Sie die Berechnung starten. Ist das richtig? Einer der Vorteile von __array_function__ ist, dass Bibliotheken völlig unabhängig von anderen Bibliotheken sein können, z. B. dass Dask beispielsweise nicht über die Existenz von CuPy Bescheid wissen muss.

@pentschev Dies war bis vor kurzem der Fall, als wir die Möglichkeit hinzugefügt haben, ein Backend zu „registrieren“. Wir empfehlen jedoch, dass nur NumPy (oder eine Referenzimplementierung) dies tut. Dann benötigen Benutzer, die Dask verwenden, nur ein einziges set_backend.

Ich denke, dies ist, was @rgommers in https://github.com/numpy/numpy/issues/13831#issuecomment -507432311 erwähnt hat und auf die Backends in https://github.com/Quansight-Labs/uarray verweist

Entschuldigen Sie so viele Fragen, aber was ist, wenn eine hypothetische Anwendung auf verschiedenen Backends basiert, z. B. sowohl NumPy als auch Sparse, wobei je nach Benutzereingabe möglicherweise alles nur NumPy, nur Sparse oder eine Mischung aus beiden ist. @ peterbell10 erwähnt, dass mehrere Backends unterstützt werden https://github.com/numpy/numpy/issues/13831#issuecomment -507458331, aber kann die Auswahl des Backends automatisch erfolgen oder müssten die drei Fälle separat behandelt werden?

In diesem Fall würden Sie NumPy idealerweise registrieren, einen Kontextmanager für Sparse verwenden und gegebenenfalls NotImplemented von sparse zurückgeben, wodurch NumPy zurückgreifen würde.

Bei SciPy haben @rgommers , @danielballan und ich über dieses Problem gesprochen. Wir kamen zu dem Schluss, dass es wertvoll wäre, mit dem Hinzufügen von duckarray (unter Verwendung dieses Namens) fortzufahren. Das heißt, es klang so, als ob dies für 1.18 geplant wäre. Bitte korrigieren Sie mich, wenn ich etwas falsch verstanden habe. Wäre es angesichts dessen in Ordnung, eine PR zu starten?

Wir kamen zu dem Schluss, dass es wertvoll wäre, mit dem Hinzufügen von duckarray (unter Verwendung dieses Namens) fortzufahren. Das heißt, es klang so, als ob dies für 1.18 geplant wäre. Bitte korrigieren Sie mich, wenn ich etwas falsch verstanden habe. Wäre es angesichts dessen in Ordnung, eine PR zu starten?

Das klingt alles gut für mich, aber es wäre gut, mit einer kurzen NEP zu beginnen, in der der genaue Vorschlag dargelegt wird. Siehe https://github.com/numpy/numpy/issues/13831#issuecomment -507334210

Klar macht das Sinn. 🙂

Was den zuvor angesprochenen Kopierpunkt betrifft, bin ich gespannt, ob dies nicht durch vorhandene Mechanismen gelöst wird. Was ist insbesondere mit diesen Zeilen?

a2 = np.empty_like(a1)
a2[...] = a1[...]

Zugegeben, es wäre schön, dies auf eine Zeile zu bringen. Nur neugierig, ob dies für diesen Anwendungsfall bereits funktioniert oder ob uns Dinge fehlen.

Wir kamen zu dem Schluss, dass es wertvoll wäre, mit dem Hinzufügen von duckarray (unter Verwendung dieses Namens) fortzufahren.

Das klingt alles gut für mich, aber es wäre gut, mit einer kurzen NEP zu beginnen, in der der genaue Vorschlag dargelegt wird. Siehe # 13831 (Kommentar)

Ich habe bereits damit begonnen, das zu schreiben, konnte es aber noch nicht fertigstellen (Entschuldigung für meine schlechte Planung https://github.com/numpy/numpy/issues/13831#issuecomment-507336302).

Was den zuvor angesprochenen Kopierpunkt betrifft, bin ich gespannt, ob dies nicht durch vorhandene Mechanismen gelöst wird. Was ist insbesondere mit diesen Zeilen?

a2 = np.empty_like(a1)
a2[...] = a1[...]

Zugegeben, es wäre schön, dies auf eine Zeile zu bringen. Nur neugierig, ob dies für diesen Anwendungsfall bereits funktioniert oder ob uns Dinge fehlen.

Sie können dies tun, es ist jedoch möglicherweise eine spezielle Kopierlogik erforderlich (z. B. in CuPy https://github.com/cupy/cupy/pull/2079).

Eine Kopierfunktion ist jedoch am besten geeignet, um zu vermeiden, dass diese Art von zusätzlichem Code erforderlich ist.

Auf der anderen Seite wäre dies eine Art Ersatz für asarray . Ich habe mich also gefragt, ob wir anstelle einer neuen Funktion von copy_like die von NEP-18 vorgeschlagene Idee noch einmal überdenken möchten:

Diese benötigen ihre eigenen Protokolle:
...
Array und Asarray, da sie explizit für den Zwang zum tatsächlichen numpy.ndarray-Objekt vorgesehen sind.

Wenn es eine Chance gibt, dass wir das noch einmal überdenken möchten, ist es vielleicht besser, einen neuen Thread zu starten. Irgendwelche Ideen, Vorschläge, Einwände?

Um meinen obigen Kommentar klar zu machen, ich selbst weiß nicht, ob ein neues Protokoll eine großartige Idee ist (wahrscheinlich sind viele umständliche Details involviert, die ich nicht voraussehe), und frage mich wirklich nur, ob dies eine Idee ist, die wir überdenken und diskutieren sollten .

Der Konsens aus dem Entwicklertreffen und dem Sprint bei SciPy'19 war: Lassen Sie uns 1.17.0 aus der Tür holen und einige praktische Erfahrungen damit sammeln, bevor wir die nächsten Schritte unternehmen.

Ich frage mich wirklich nur, ob das eine Idee ist, die wir überdenken und diskutieren sollten.

wahrscheinlich ja, aber in ein paar Monaten.

wahrscheinlich ja, aber in ein paar Monaten.

Ok, danke für die Antwort!

Was den zuvor angesprochenen Kopierpunkt betrifft, bin ich gespannt, ob dies nicht durch vorhandene Mechanismen gelöst wird. Was ist insbesondere mit diesen Zeilen?

a2 = np.empty_like(a1)
a2[...] = a1[...]

Zugegeben, es wäre schön, dies auf eine Zeile zu bringen. Nur neugierig, ob dies für diesen Anwendungsfall bereits funktioniert oder ob uns Dinge fehlen.

Mein Hauptproblem dabei ist, dass es für unveränderliche Enten-Arrays nicht funktionieren würde, was nicht ungewöhnlich ist. Für NumPy können die zusätzlichen Kosten für das Zuweisen und anschließende Füllen eines Arrays nahezu Null betragen, aber ich bin mir nicht sicher, ob dies für alle Enten-Arrays gilt.

Was den zuvor angesprochenen Kopierpunkt betrifft, bin ich gespannt, ob dies nicht durch vorhandene Mechanismen gelöst wird. Was ist insbesondere mit diesen Zeilen?

a2 = np.empty_like(a1)
a2[...] = a1[...]

Zugegeben, es wäre schön, dies auf eine Zeile zu bringen. Nur neugierig, ob dies für diesen Anwendungsfall bereits funktioniert oder ob uns Dinge fehlen.

Sie können dies tun, es ist jedoch möglicherweise eine spezielle Kopierlogik erforderlich (z. B. in CuPy cupy / cupy # 2079 ).

Eine Kopierfunktion ist jedoch am besten geeignet, um zu vermeiden, dass diese Art von zusätzlichem Code erforderlich ist.

Auf der anderen Seite wäre dies eine Art Ersatz für asarray . Ich habe mich also gefragt, ob wir anstelle einer neuen Funktion von copy_like die von NEP-18 vorgeschlagene Idee noch einmal überdenken möchten:

Diese benötigen ihre eigenen Protokolle:
...
Array und Asarray, da sie explizit für den Zwang zum tatsächlichen numpy.ndarray-Objekt vorgesehen sind.

Wenn es eine Chance gibt, dass wir das noch einmal überdenken möchten, ist es vielleicht besser, einen neuen Thread zu starten. Irgendwelche Ideen, Vorschläge, Einwände?

Ich denke nicht, dass es eine gute Idee ist, das Verhalten von np.array oder np.asarray mit einem neuen Protokoll zu ändern. Ihre etablierte Bedeutung ist die Umwandlung in NumPy-Arrays, weshalb wir im Grunde np.duckarray benötigen

Das heißt, wir könnten erwägen, duckarray ein like Argument hinzuzufügen. Dazu müsste das Protokoll gegenüber dem oben genannten vereinfachten Vorschlag geändert werden - möglicherweise um __array_function__ anstelle eines dedizierten Protokolls wie __duckarray__ ? Ich habe das nicht wirklich durchdacht.

Was den zuvor angesprochenen Kopierpunkt betrifft, bin ich gespannt, ob dies nicht durch vorhandene Mechanismen gelöst wird. Was ist insbesondere mit diesen Zeilen?

a2 = np.empty_like(a1)
a2[...] = a1[...]

Zugegeben, es wäre schön, dies auf eine Zeile zu bringen. Nur neugierig, ob dies für diesen Anwendungsfall bereits funktioniert oder ob uns Dinge fehlen.

Mein Hauptproblem dabei ist, dass es für unveränderliche Enten-Arrays nicht funktionieren würde, was nicht ungewöhnlich ist. Für NumPy können die zusätzlichen Kosten für das Zuweisen und anschließende Füllen eines Arrays nahezu Null betragen, aber ich bin mir nicht sicher, ob dies für alle Enten-Arrays gilt.

Das ist fair. Eigentlich können wir die Dinge schon vereinfachen. Zum Beispiel funktioniert dies heute mit CuPy und Sparse.

a2 = np.copy(a1)

Das ist fair. Eigentlich können wir die Dinge schon vereinfachen. Zum Beispiel funktioniert dies heute mit CuPy und Sparse.

a2 = np.copy(a1)

Ja, aber wir möchten auch "dieses Entenarray in den Typ dieses anderen Entenarrays kopieren".

Ich halte es nicht für eine gute Idee, das Verhalten von np.array oder np.asarray mit einem neuen Protokoll zu ändern. Ihre etablierte Bedeutung ist die Umwandlung in NumPy-Arrays, weshalb wir im Grunde np.duckarray benötigen

Ich bin mir auch nicht sicher, und ich zögerte sogar, diese Frage zu stellen. Deshalb hatte ich es bis heute nicht getan.

Das heißt, wir könnten erwägen, duckarray ein ähnliches Argument hinzuzufügen. Dazu müsste das Protokoll gegenüber dem oben vereinfachten Vorschlag geändert werden - möglicherweise __array_function__ anstelle eines dedizierten Protokolls wie __duckarray__? Ich habe das nicht wirklich durchdacht.

Ich weiß nicht, ob es irgendwelche Komplikationen geben würde, wir brauchen wahrscheinlich etwas Vorsicht, aber ich neige dazu, diese Idee zu mögen. Das scheint auf verschiedenen Ebenen überflüssig zu sein, aber um dem vorhandenen Muster zu folgen, könnten wir statt eines like -Parameters duckarray und duckarray_like ?

Ja, aber wir möchten auch "dieses Entenarray in den Typ dieses anderen Entenarrays kopieren".

Was ist mit np.copyto ?

Was ist mit np.copyto ?

Fühlen Sie sich frei, mich zu korrigieren, wenn ich falsch liege, aber ich gehe davon aus, dass Sie etwas bedeuten wie:

np.copyto(cupy_array, numpy_array)

Dies könnte funktionieren, vorausgesetzt, NumPy ist bereit, das aktuelle Verhalten zu ändern. Beispiel: asarray impliziert immer, dass das Ziel ein NumPy-Array ist. Geht copyto derselben Annahme aus?

np.copyto unterstützt bereits den Versand mit __array_function__ , entspricht aber in etwa:

def copyto(dst, src):
    dst[...] = src

Wir wollen das Äquivalent von:

def copylike(src, like):
    dst = np.empty_like(like)
    dst[...] = src
    return dst

np.copyto unterstützt bereits den Versand mit __array_function__ , entspricht aber in etwa:

def copyto(dst, src):
    dst[...] = src

Wir wollen das Äquivalent von:

def copylike(src, like):
    dst = np.empty_like(like)
    dst[...] = src
    return dst

Richtig, das wollen wir. copyto wird versendet und funktioniert, wenn Quelle und Ziel denselben Typ haben. Wir benötigen etwas, das den Versand an die Bibliothek des Zielarrays ermöglicht.

Nun, copyto könnte immer noch Sinn machen, je nachdem, wie wir darüber denken. Nehmen Sie zum Beispiel den folgenden Anwendungsfall.

np.copyto(cp.ndarray, np.random.random((3,)))

Dies könnte dazu führen, dass die Daten, wie wir bereits besprochen haben, zugewiesen und kopiert werden. Wenn wir ungefähr dst versenden (in diesem Fall cp.ndarray ), könnten Bibliotheken mit unveränderlichen Arrays dies ebenfalls auf geeignete Weise implementieren. Es erspart uns auch das Hinzufügen einer neuen API (die NumPy lediglich bereitstellt, aber nicht verwendet), was ein Problem zu sein schien.

Um einen anderen Gedanken aufzudecken, der mir kürzlich in den Sinn gekommen ist, lohnt es sich zu überlegen, was diese APIs zwischen anderen Bibliotheken bedeuten (zum Beispiel, wie Dask und Xarray interagieren).