Numpy: ダックアレイ強制のサポート

提案された実装は次のようになります。

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)

使用例：

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

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

ここでは、プレースホルダーとしてnp.duckarrayと__duckarray__を使用しましたが、これらの名前の方がおそらくうまくいく可能性があります。 NEP22の用語を参照してください。

「ダック配列」は今のところプレースホルダーとしては問題なく機能しますが、かなり専門用語であり、新しいユーザーを混乱させる可能性があるため、実際のAPI関数用に別のものを選択することをお勧めします。 残念ながら、「配列のような」は「配列に強制できるもの」（リストオブジェクトなどを含む）の概念にすでに採用されており、「anyarray」は「ndarrayの実装を共有するもの」の概念にすでに採用されていますが、 「異なるセマンティクスがあります」。これは、ダック配列の反対です（たとえば、np.matrixは「anyarray」ですが、「ダック配列」ではありません）。 これは古典的な自転車小屋なので、今のところは「ダックアレイ」を使用しています。 ただし、考えられるオプションには、arrayish、pseudoarray、nominalarray、ersatzarray、arraymimic、…などがあります。

他の名前のアイデア： np.array_compatible() 、 np.array_api() ...。

np.array_compatibleは機能する可能性がありますが、 duckarrayよりも気に入っているかどうかはわかりません。 np.array_api私は好きではありません、間違った考えを私見に与えます。

久しぶりにいい名前が出てこなかったので、「アヒルの配列」という名前を祝福したほうがいいかも……。

私は互換性のある単語が好きです。おそらく、その行に沿ったバリエーションも考えられますas_compatible_array （互換性のあるすべてのオブジェクトが配列であることを意味します）。 asはおそらく煩わしいものです（一部、すべてのas関数にスペースがないため）。 「アヒル」は図書館ではいいように見えますが、ランダムな人がそれを見るのは少し奇妙だと思います。 したがって、「ダック」は、ダウンストリームユーザーに頻繁に使用してもらいたい場合にのみ（つまり、自分用の小さなツールや小さなラボを書き始めた場合でも）嫌いだと思います。

多分quack_array :)

このトピックについて少し詳しく説明すると、 np.duckarrayでカバーされていないもう1つのケースがあります。これは、 np.empty_likeなどの関数と同様に、既存の型に基づく型で新しい配列を作成することです。

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

一方、NumPyのAPIを介してCuPy配列を作成したいarray_likeある場合、それは不可能です。 次のようなものがあると便利だと思います。

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

これに関するアイデア/提案はありますか？

多分np.copy_like？ どのプロパティを注意深く定義したいと思います
（たとえば、dtypeを含むかどうか）他の配列からコピーされます。

2019年7月1日月曜日午前5時40分PeterAndreas Entschev <
[email protected]>書き込み：

このトピックについて少し詳しく説明すると、カバーされていないケースがもう1つあります。
np.duckarrayを使用します。これは、タイプベースの新しい配列の作成です。
np.empty_likeなどの関数が実行するのと同様に、既存の型で。
現在、次のようなことができます。

numpyをnpとして、cupyをcpとしてインポート>>> a = cp.array（[1、2]）>>> b = np.ones_like（a）>>> type（b）

一方、作成したいarray_likeがある場合
NumPyのAPIを介したCuPy配列、それは不可能です。 私はそれが
次のようなものがあると便利です：

numpyをnpとして、cupyをcpとしてインポートします
a = cp.array（[1、2]）
b = [1、2]
c = np.asarray（b、like = a）

これに関するアイデア/提案はありますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13831?email_source=notifications&email_token=AAJJFVRCWDHRAXHHRDHXXM3P5H3LRA5CNFSM4H3HQWAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAJJFVRSYHUYHMPWQTW2NLLP5H3LRANCNFSM4H3HQWAA
。

np.copy_likeもいいですね。 私は同意します、私たちはおそらくdtypeようなものを制御する方法を持っているべきです。

初心者の質問で申し訳ありませんが、 np.copy_likeようなものをNEP-22の修正にする必要がありますか、それをメーリングリストで議論する必要がありますか、それともそれに対する最も適切なアプローチは何でしょうか？

これについて厳密なルールはありませんが、 np.copy_likeとnp.duckarray （または私たちが呼んでいるもの）を組み合わせて、アヒルの配列を強制/作成する新しいNEPを作成することに傾倒します。これは、NEP 22のような「情報」ではなく、NEP 18のように規範的です。長くする必要はありません。ほとんどの動機は、NEP18 / 22を参照することですでに明らかです。

約ノートnp.copy_like() ：それは間違いで派遣行う必要があります__array_function__のように操作して、（またはそれのようなもの） np.copy_like(sparse_array, like=dask_array)いずれかの配列型のいずれかで定義することができます。

情報をありがとうございます。発送の提案に同意します。 np.duckarrayとnp.copy_likeの両方を実装するためのNEPに取り組み、今週はそのためのドラフトPRを提出します。

素晴らしい、ありがとうピーター！

2019年7月1日月曜日午前9時29分PeterAndreas Entschev <
[email protected]>書き込み：

情報をありがとうございます。発送の提案に同意します。 私
np.duckarrayとの両方を実装するためのNEPで動作します
np.copy_likeし、そのために今週ドラフトPRを提出してください。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/numpy/numpy/issues/13831?email_source=notifications&email_token=AAJJFVW2YUBNUCJZK6JWDBTP5IWHNA5CNFSM4H3HQWAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAJJFVR2KTPAZ4JPWDYYMFLP5IWHNANCNFSM4H3HQWAA
。

私の喜び、そしてこの仕事のアイデアとサポートに感謝します！

array_like関数とcopy_like関数は、デフォルトの実装を設定できないため、メインの名前空間に含めるのは少し奇妙だと思います（少なくとも、キューピー/ダスク/スパース/など）、そうですか？ これらは、オーバーライドされた場合にのみ役立ちます。 または、ここで任意の非numpy配列オブジェクトを作成する方法がありませんか？

確かに、これらはダックタイピングをサポートしたい場合にのみ本当に役立ちます。 しかし、確かにnp.duckarrayとnp.copy_likeは、引数がNumPy配列のみであっても機能します。これらは、 np.array / np.copyと同等です。

すべての配列実装にはcopyメソッドがありますよね？ copy_like代わりにそれを使用すると機能するはずですが、なぜ新しい関数を追加するのですか？

array_like必要性はわかりますが、どこに置くかについて話し合いたいと思うかもしれません。

np.duckarrayは私には理にかなっています。

私は、np.copy_likeとnp.duckarray（または私たちがそれを呼ぶもの）を組み合わせて、アヒルの配列を強制/作成する新しいNEPに傾倒します。これは、NEP 22のような「情報」ではなく、NEP18のような規範的なものです。

+1

array_likeの必要性はわかりますが、どこに配置するかについて話し合いたいと思うかもしれません。

それは実際に私がnp.copy_likeようなもので対処したいケースです。 私はテストしていませんが、配列がNumPy以外の場合、おそらくnp.copyすでに正しくディスパッチされています。

明確にするために、関数np.array_likeも参照していますか？ array_like配列への既存のすべての参照を混乱させる可能性があると考えたため、このような名前は意図的に避けました。 ただし、 np.copy_likeが必要なコピーを意味する可能性があることを認識しました。コピーがまだNumPyでない場合にのみ発生する、 np.asarrayと同様の動作を行うとよいと思います。アレイ。 ここで説明するケースでは、 aがnp.copy_like(a, like=b)などの呼び出しでbと同じタイプでない場合にのみ、コピーを作成するのが最善です。

私はテストしていませんが、配列がNumPy以外の場合、おそらくnp.copyすでに正しくディスパッチされています。

__array_function__をサポートするように装飾されている必要があります。

明確にするために、関数np.array_likeも参照していますか？ array_like-arraysへの既存のすべての参照を混乱させる可能性があると考えたため、このような名前は意図的に避けました。

はい。 そして、はい、それが混乱する可能性があることに同意します。

しかし、私は今、 np.copy_likeが必要なコピーを意味するかもしれないことに気づきました。

はい、その名前はデータのコピーを意味します。

必要なコピーを意味するかもしれません、そして私はnp.asarrayような振る舞いをするのが良いと思います、

それはnp.duckarrayだと思いました。

上記のピーターの例は、これを明確にするのに役立つかもしれないと思います。 以下にコピーし、簡単にするためにnp.copy_likeで下塗りしました。

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

それはnp.duckarrayだと思いました。

実際、 np.duckarrayは基本的に何もせず、配列自体を返すだけです（オーバーライドされている場合）。それ以外の場合はnp.asarray返します（NumPy配列になります）。 たとえば、PythonリストからCuPy配列を取得することはできません。 array_like CuPy（または他のlike=配列）にディスパッチできる関数がまだ必要です。

更新された例を@jakirkhamに感謝します。

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

それで、それはa.__array_function__を介してCuPyにディスパッチし、その属性が存在しない場合は失敗します（たとえば、 a=<scipy.sparse matrix>は機能しません）？ そのようなことのために、新しい名前空間または新しい相互運用性ユーティリティパッケージが必要なように感じます。 それか、より完全な機能を備えた将来のディスパッチメカニズムに任せてください。

with cupy_backend:
   np.array(b)

NumPy自体が__array_function__制限の回避をサポートするのに意味がない新しい関数をメインの名前空間に導入することは、少し不健康に思えます...。

それで、それはa.__array_function__を介してCuPyにディスパッチし、その属性が存在しない場合は失敗します（たとえば、 a=<scipy.sparse matrix>は機能しません）？

必ずしも失敗しなければならないとは言いません。 たとえば、デフォルトでNumPyを使用して警告を発する（またはまったく発生させない）ことができます。

そのようなことのために、新しい名前空間または新しい相互運用性ユーティリティパッケージが必要なように感じます。 それか、よりフル機能の将来のディスパッチメカニズムに任せてください

確かに、フル機能のディスパッチメカニズムがあればいいのですが、その複雑さと下位互換性の問題のために、これは以前は行われていなかったと思いますか？ 話し合いがあったときは周りにいなかったので、推測するだけです。

NumPy自体が__array_function__の制限の回避をサポートするのに意味のない新しい関数をメインの名前空間に導入することは、少し不健康に思えます...。

確かにあなたの主張はわかりますが、メインの名前空間から離れすぎると、ユーザーを怖がらせる可能性があると思います。 多分私は間違っていて、これはただの印象です。 いずれにせよ、私はNumPyで動作しない関数を実装することをまったく提案していませんが、NumPyを単独で使用する場合は絶対に必要というわけではありません。

NumPy自体が__array_function__の制限の回避をサポートするのに意味のない新しい関数をメインの名前空間に導入することは、少し不健康に思えます...。

実際、この意味では、 np.duckarrayもメインの名前空間に属していません。

実際、この意味では、 np.duckarrayもメインの名前空間に属していません。

1つはより防御可能だと思います（ asarray類似しており、基本的に「これはndarrayのようなダックタイプの定義を満たしていますか」をチェックします）が、そうです。 array_function_dispatchも公開したいが、 np.lib.mixins.NDArrayOperatorsMixinあり、さらにミックスインを作成する予定がある場合は、相互運用性に関連するすべてのものに対応する賢明な新しいサブモジュールが理にかなっています。

確かに、フル機能のディスパッチメカニズムがあればいいのですが、その複雑さと下位互換性の問題のために、これは以前は行われていなかったと思いますか？ 話し合いがあったときは周りにいなかったので、推測するだけです。

複数の理由があると思います。 __array_function__は私たちがすでに持っていたものと似ているので、推論するのは簡単です。 オーバーヘッドが少ないです。 それは最大6か月のタイムスケールで設計および実装でき、

相互運用性に関連するすべてのもののための賢明な新しいサブモジュールは理にかなっているかもしれません。

私からの本当の異議はありません。どこにもないよりもどこかに機能がある方が良いと思います。 :)

複数の理由があると思います。 __array_function__は私たちがすでに持っていたものに似ているので、推論するのは簡単です。 オーバーヘッドが少ないです。 それは最大6か月のタイムスケールで設計および実装でき、

しかし、 __array_function__より広く活用したい場合は、 np.duckarrayやnp.copy_like （またはそれと呼ぶことにした他の何か）のようなものを実装する他の選択肢がありますか？ 私はすべての選択肢を受け入れていますが、もちろん、フル機能のディスパッチ方法を採用するのではなく、今のところ何も表示されていません。これには長い時間がかかり、 __array_function__範囲が制限される可能性があります。

しかし、 __array_function__より広く活用したい場合は、 np.duckarrayやnp.copy_like （またはそれと呼ぶことにした他の何か）のようなものを実装する他の選択肢がありますか？

ユースケースの一部をカバーすることから、ユースケースの80％を超えることまで、そのような一連のユーティリティ機能が実際に必要だと思います。 それを回避する方法はないと思います。 メインの名前空間を乱雑にするのは好きではないので、それらのためのより良い場所を見つけることを提案します。

私はすべての選択肢を受け入れていますが、もちろん、フル機能のディスパッチ方法を採用するのではなく、今のところ何も表示されていません。これには長い時間がかかり、 __array_function__範囲が制限される可能性があります。

つまり、ここでいくつかの明らかな穴を塞いでいるだけですよね？ 「より複雑なケース」のすべてを網羅することは決してありません。 np.errstateまたはnp.dtypeをオーバーライドしたい場合、プロトコルベースのアプローチでは発生しません。

代替案については、 scipy.fftを作成するために試してみようとしています。 https ：

uarrayを使用したディスパッチアプローチは確かに興味深いものです。 メタ配列（Dask、xarrayなど）の処理方法についてはまだ心配ですが。 詳細はこちらのコメントをご覧ください。 これが対処されているかどうかは不明です（ただし、何かを見逃した場合は修正してください）。 SciPyの他の人と協力して、この問題をどのように解決するかを試してみたいと思います。

詳細はこちらのコメントをご覧ください。 これが対処されているかどうかは不明です（ただし、何かを見逃した場合は修正してください）。

先週の変更でそれは解決したと思いますが、確かではありません。別のスレッドに残しましょう。

SciPyの他の人と協力して、この問題をどのように解決するかを試してみたいと思います。

私はそこにいます、あなたに直接会うのは素晴らしいことです。

たぶんnp.coerce_like()またはnp.cast_like()はcopy_likeよりも良い名前なので、コピーが必ずしも必要ではないことは明らかです。 必要な機能は、配列型とdtypeを変換することを除いて、 .cast()メソッドと非常によく似ています。どちらの引数でも実装できるように、プロトコルではなく関数にする必要があります。

uarrayを使用したディスパッチアプローチは確かに興味深いものです。 メタ配列（Dask、xarrayなど）の処理方法についてはまだ心配ですが。

uarrayは複数のバックエンドをサポートしているため、このようなものが機能するはずです

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

これは、メタ配列がその実装内でua.skip_backend呼び出すようにするか、メタ配列のバックエンドが型の不一致でNotImplementedを返す場合に実行できます。

cc： @hameerabbasi

これについて詳しく説明します。原則として、 dask.array場合、 daを含むものはすべて、skip_backendなしで書き込まれます。 NumPyを使用するものには、skip_backendが必要です。

または、 da場合は、いつでもディスパッチをスキップして独自の実装を直接呼び出し、どこにでもskip_backend(dask.array)を置くことができます。

ones 、 castように、配列がアタッチされていない関数をディスパッチする場合は、バックエンドを設定するだけで完了します。 np.errstateとnp.dtypeについても同じです。 unumpy np.ufuncをカバーする例があります。

元の問題に関しては、 uarrayは__ua_convert__プロトコルを提供します。これはまさにこれを行います。 別の方法は、バックエンドがasarray直接オーバーライドすることです。

上のヘッドアップしてくれてありがとうuarray 、@rgommers、@ peterbell10、@hameerabbasi。

しかし、私が見るように、計算を開始する前に適切なバックエンドを設定する必要があります、それは正しいですか？ __array_function__の利点の1つは、ライブラリが他のライブラリに完全に依存しないことです。たとえば、DaskはCuPyの存在を知る必要がありません。

@pentschevこれは、バックエンドを「登録」する機能を追加した最近まで

了解しました。これは、 https://github.com/numpy/numpy/issues/13831#issuecomment-507432311で言及したものであり、 https： //github.com/Quansight-Labs/uarrayのバックエンドを指しています。 / tree / master / unumpy。

非常に多くの質問をして申し訳ありませんが、たとえば、NumPyとSparseの両方など、さまざまなバックエンドに依存している架空のアプリケーションがある場合はどうなりますか。ユーザー入力に応じて、すべてがNumPyのみ、Sparseのみ、または両方の組み合わせになります。 @ peterbell10は、複数のバックエンドがサポートされていると述べていますhttps://github.com/numpy/numpy/issues/13831#issuecomment -507458331ですが、バックエンドの選択を自動化できますか、それとも3つのケースを別々に処理する必要がありますか？

したがって、この場合、理想的にはNumPyを登録し、Sparseのコンテキストマネージャーを使用し、必要に応じてsparseからNotImplementedを返します。これにより、NumPyにフォールバックします。

SciPy @ rgommers 、 @ danielballan 、そして私自身がこの問題について話しました。 duckarray （その名前を使用）の追加を続行することは価値があると結論付けました。 とはいえ、これは1.18に予定されているように聞こえました。 誤解されたら訂正してください。 これを考えると、PRを始めても大丈夫でしょうか？

duckarray （その名前を使用）の追加を続行することは価値があると結論付けました。 とはいえ、これは1.18に予定されているように聞こえました。 誤解されたら訂正してください。 これを考えると、PRを始めても大丈夫でしょうか？

これはすべて私には素晴らしいことのように聞こえますが、正確な提案を詳しく説明する短いNEPから始めるのがよいでしょう。 https://github.com/numpy/numpy/issues/13831#issuecomment-507334210を参照して

確かにそれは理にかなっています。 🙂

以前に取り上げたコピーポイントについては、既存のメカニズムでは解決できないのではないかと思います。 特にこれらの行はどうですか？

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

確かに、これを1行にまとめるとよいでしょう。 これがそのユースケースですでに機能しているかどうか、または不足しているものがあるかどうかだけを知りたい。

（その名前を使用して）duckarrayの追加を続行することは価値があると結論付けました。

これはすべて私には素晴らしいことのように聞こえますが、正確な提案を詳しく説明する短いNEPから始めるのがよいでしょう。 ＃13831（コメント）を参照

私はすでにそれを書き始めましたが、まだそれを完了することができませんでした（私の悪い計画https://github.com/numpy/numpy/issues/13831#issuecomment-507336302）。

以前に取り上げたコピーポイントについては、既存のメカニズムでは解決できないのではないかと思います。 特にこれらの行はどうですか？

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

確かに、これを1行にまとめるとよいでしょう。 これがそのユースケースですでに機能しているかどうか、または不足しているものがあるかどうかだけを知りたい。

それは可能ですが、特別なコピーロジックが必要になる場合があります（CuPy https://github.com/cupy/cupy/pull/2079など）。

とは言うものの、この種の追加コードが必要になるのを避けるために、コピー機能が最善かもしれません。

一方、これはasarray一種の代替品になります。 したがって、 copy_like新しい関数の代わりに、NEP-18によって提案された

これらには独自のプロトコルが必要です。
..。
arrayとasarrayは、実際のnumpy.ndarrayオブジェクトへの強制を明示的に意図しているためです。

それを再検討したい場合は、新しいスレッドを開始する方がよいでしょう。 アイデア、提案、異議はありますか？

上記の私のコメントを明確にするために、私自身、新しいプロトコルが素晴らしいアイデアであるかどうかはわかりません（おそらく、私が予測していない多くの厄介な詳細が含まれています）、本当にそれが私たちが再検討して議論する必要があるアイデアであるかどうか疑問に思っています。

SciPy'19での開発者会議とスプリントからのコンセンサスは次のとおりでした。次のステップに進む前に、1.17.0を公開して、実際の経験を積んでみましょう。

それが私たちが再検討して議論すべきアイデアであるかどうか本当に疑問に思っています。

おそらくそうですが、数か月で。

おそらくそうですが、数か月で。

返信ありがとうございます。

以前に取り上げたコピーポイントについては、既存のメカニズムでは解決できないのではないかと思います。 特にこれらの行はどうですか？

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

確かに、これを1行にまとめるとよいでしょう。 これがそのユースケースですでに機能しているかどうか、または不足しているものがあるかどうかだけを知りたい。

これに関する私の主な問題は、不変のアヒル配列では機能しないことです。これはそれほど珍しいことではありません。 また、NumPyの場合、配列を割り当ててからそれを埋める追加コストはほぼゼロになる可能性がありますが、それがすべてのアヒル配列に当てはまるかどうかはわかりません。

以前に取り上げたコピーポイントについては、既存のメカニズムでは解決できないのではないかと思います。 特にこれらの行はどうですか？

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

確かに、これを1行にまとめるとよいでしょう。 これがそのユースケースですでに機能しているかどうか、または不足しているものがあるかどうかだけを知りたい。

それは可能ですが、特別なコピーロジックが必要になる場合があります（CuPy cupy / cupy＃2079など）。

とは言うものの、この種の追加コードが必要になるのを避けるために、コピー機能が最善かもしれません。

一方、これはasarray一種の代替品になります。 したがって、 copy_like新しい関数の代わりに、NEP-18によって提案された

これらには独自のプロトコルが必要です。
..。
arrayとasarrayは、実際のnumpy.ndarrayオブジェクトへの強制を明示的に意図しているためです。

それを再検討したい場合は、新しいスレッドを開始する方がよいでしょう。 アイデア、提案、異議はありますか？

np.arrayまたはnp.asarrayを新しいプロトコルで変更するのは良い考えではないと思います。 それらの確立された意味は、NumPy配列にキャストすることです。これが、基本的にnp.duckarrayが必要な理由です。

そうは言っても、 like引数をduckarray追加することを検討できます。 それには、上記の簡略化された提案からプロトコルを変更する必要があります-多分__duckarray__ような専用プロトコルの代わりに__array_function__を使用するのですか？ 私はこれを本当に考えていません。

以前に取り上げたコピーポイントについては、既存のメカニズムでは解決できないのではないかと思います。 特にこれらの行はどうですか？

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

確かに、これを1行にまとめるとよいでしょう。 これがそのユースケースですでに機能しているかどうか、または不足しているものがあるかどうかだけを知りたい。

これに関する私の主な問題は、不変のアヒル配列では機能しないことです。これはそれほど珍しいことではありません。 また、NumPyの場合、配列を割り当ててからそれを埋める追加コストはほぼゼロになる可能性がありますが、それがすべてのアヒル配列に当てはまるかどうかはわかりません。

それは公正です。 実際、私たちはすでに物事を単純化することができます。 たとえば、これは現在CuPyとSparseで機能します。

a2 = np.copy(a1)

それは公正です。 実際、私たちはすでに物事を単純化することができます。 たとえば、これは現在CuPyとSparseで機能します。

a2 = np.copy(a1)

はい。ただし、「このduck-arrayをこの他のduck-arrayのタイプにコピーする」ことも必要です。

np.arrayまたはnp.asarrayを新しいプロトコルで変更するのは良い考えではないと思います。 それらの確立された意味は、NumPy配列にキャストすることです。これが、基本的にnp.duckarrayが必要な理由です。

私もこれについて確信が持てず、この質問をすることすら気が進まなかったので、今日までそうしなかったのです。

そうは言っても、duckarrayに同様の引数を追加することを検討できます。 そのためには、上記の簡略化された提案からプロトコルを変更する必要があります。おそらく、__ duckarray__のような専用プロトコルの代わりに__array_function__を使用しますか？ 私はこれを本当に考えていません。

それで何か問題があるかどうかはわかりませんが、おそらく注意が必要ですが、私はこのアイデアが好きになる傾向があります。 これはさまざまなレベルで冗長に見えるかもしれませんが、 likeパラメータを追加する代わりに、既存のパターンに従うと、 duckarrayとduckarray_likeますか？

はい。ただし、「このduck-arrayをこの他のduck-arrayのタイプにコピーする」ことも必要です。

これをnp.copyto基づいて行うのはどうですか？

これをnp.copyto基づいて行うのはどうですか？

私が間違っている場合は、遠慮なく訂正してください。ただし、次のような意味であると想定しています。

np.copyto(cupy_array, numpy_array)

NumPyが現在の動作を変更する意思があると仮定すると、これは機能する可能性があります。たとえば、 asarray常に宛先がNumPy配列であることを意味しますが、 copytoは同じ仮定をしますか？

np.copytoすでに__array_function__でのディスパッチをサポートしていますが、これはほぼ同等です。

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

以下と同等のものが必要です。

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

np.copytoすでに__array_function__でのディスパッチをサポートしていますが、これはほぼ同等です。

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

以下と同等のものが必要です。

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

正解です、これが私たちが望んでいることです。 copytoがディスパッチされ、ソースと宛先が同じタイプの場合に機能します。宛先配列のライブラリにディスパッチできるものが必要です。

ええと、 copytoは、私たちの考え方によっては、まだ意味があります。 たとえば、次のユースケースを考えてみましょう。

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

これは、前述のように、データの割り当てとコピーのようなものに変換される可能性があります。 dst （この場合はcp.ndarray ）をディスパッチすると、不変の配列を持つライブラリもこれを適切な方法で実装できます。 また、懸念事項と思われる新しいAPI（NumPyが提供するだけで、使用しない）を追加する手間も省けます。

最近私に起こった別の考えを浮き彫りにするために、これらのAPIが他のライブラリ間のダウンストリームで何を意味するか（たとえば、DaskとXarrayがどのように相互作用するか）について考える価値があります。