Numpy: Mendukung pemaksaan deretan bebek

Dibuat pada 25 Jun 2019  ·  55Komentar  ·  Sumber: numpy/numpy

Membuka masalah ini setelah berdiskusi dengan @shoyer , @pentschev , dan @mrocklin dalam masalah (https://github.com/dask/dask/issues/4883). AIUI ini telah dibahas di NEP 22 (jadi saya terutama meniru ide orang lain di sini untuk memperbarui diskusi dan memperbaiki kesalahpahaman saya sendiri;).

Ini akan berguna untuk berbagai pustaka array hilir memiliki fungsi untuk memastikan kita memiliki beberapa array bebek (seperti ndarray ). Ini akan mirip dengan np.asanyarray , tetapi tanpa persyaratan subclassing. Ini akan memungkinkan perpustakaan untuk mengembalikan tipe array (bebek) mereka sendiri . Jika tidak ada konversi yang sesuai yang didukung oleh objek, kita dapat melakukan fallback untuk menangani ndarray subclass, ndarray s, dan pemaksaan hal-hal lain (daftar bersarang) ke ndarray s.

cc @nrnnnnnnnnn (yang menulis bersama NEP 22)

01 - Enhancement numpy.core

Komentar yang paling membantu

Mungkin quack_array :)

Semua 55 komentar

Implementasi yang diusulkan akan terlihat seperti berikut:

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)

Contoh penggunaan:

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

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

Di sini saya telah menggunakan np.duckarray dan __duckarray__ sebagai placeholder, tetapi kami mungkin dapat melakukan yang lebih baik untuk nama-nama ini. Lihat Terminologi dari NEP 22:

"Duck array" berfungsi dengan baik sebagai placeholder untuk saat ini, tetapi ini cukup jargony dan mungkin membingungkan pengguna baru, jadi kami mungkin ingin memilih sesuatu yang lain untuk fungsi API yang sebenarnya. Sayangnya, "seperti larik" sudah diambil untuk konsep "apa pun yang dapat dipaksakan menjadi larik" (termasuk misalnya daftar objek), dan "anyarray" sudah diambil untuk konsep "sesuatu yang berbagi implementasi ndarray, tapi memiliki semantik yang berbeda ”, yang merupakan kebalikan dari deret bebek (misalnya, np.matrix adalah“ anyarray ”, tetapi bukan“ larik bebek ”). Ini adalah gudang sepeda klasik jadi untuk saat ini kami hanya menggunakan “duck array”. Beberapa opsi yang mungkin termasuk: arrayish, pseudoarray, nominalarray, ersatzarray, arraymimic,…

Beberapa ide nama lain: np.array_compatible() , np.array_api() ....

np.array_compatible dapat berfungsi, meskipun saya tidak yakin saya lebih menyukainya daripada duckarray . np.array_api Saya tidak suka, memberikan ide yang salah imho.

Karena setelah sekian lama kita belum menemukan nama yang lebih baik, mungkin kita harus memberkati nama "duck-array" ......

Saya suka kata yang kompatibel, mungkin kita bisa memikirkan variasi sepanjang baris itu juga as_compatible_array (agak menyiratkan bahwa semua objek yang kompatibel adalah array). as mungkin mengganggu (sebagian karena semua fungsi as tidak memiliki spasi). "bebek" sepertinya bagus di perpustakaan, tapi menurut saya agak aneh jika orang secara acak melihatnya. Jadi saya pikir saya tidak suka "bebek" jika dan hanya jika kami ingin pengguna hilir sering menggunakannya (yaitu bahkan ketika saya mulai menulis alat kecil untuk saya sendiri / laboratorium kecil).

Mungkin quack_array :)

Untuk sedikit memperluas topik, ada satu kasus lain yang tidak tercakup dengan np.duckarray , yang merupakan pembuatan array baru dengan tipe berdasarkan tipe yang ada, mirip dengan fungsi apa seperti np.empty_like lakukan. Saat ini kami dapat melakukan hal-hal seperti ini:

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

Di sisi lain, jika kita memiliki array_like yang ingin kita buat larik CuPy melalui API NumPy, itu tidak mungkin. Saya pikir akan sangat membantu jika memiliki sesuatu seperti:

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

Ada ide / saran tentang ini?

Mungkin np.copy_like? Kami ingin mendefinisikan dengan hati-hati properti yang mana
(misalnya, termasuk dtype atau tidak) disalin dari larik lain.

Pada hari Senin, 1 Juli 2019 jam 5:40 Peter Andreas Entschev <
[email protected]> menulis:

Untuk sedikit memperluas topik, ada satu kasus lain yang tidak tercakup
dengan np.duckarray, yang merupakan pembuatan array baru dengan berbasis tipe
pada tipe yang sudah ada, mirip dengan fungsi apa yang dilakukan np.empty_like.
Saat ini kami dapat melakukan hal-hal seperti ini:

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

Di sisi lain, jika kita memiliki array_like yang ingin kita buat
array CuPy dari melalui API NumPy, itu tidak mungkin. Saya pikir itu akan terjadi
sangat membantu untuk memiliki sesuatu seperti:

impor numpy sebagai np, cupy sebagai cp
a = cp.array ([1, 2])
b = [1, 2]
c = np.asarray (b, seperti = a)

Ada ide / saran tentang ini?

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/numpy/numpy/issues/13831?email_source=notifications&email_token=AAJJFVRCWDHRAXHHRDHXXM3P5H3LRA5CNFSM4H3HQWAKYY3PNVWWK3TUL5252HS4DFVREXG43VMVB57S4DFVREXG43VMVB57S4DFVREXG43VMVB57S4DFVREXG43VMVB57S4DFVREXG43VMVB57S4DFVREXG43VMVB57S4DFVREXG43VMVB57S4DFVRXG43
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAJJFVRSYHUYHMPWQTW2NLLP5H3LRANCNFSM4H3HQWAA
.

np.copy_like terdengar bagus juga. Saya setuju, kemungkinan besar kita harus memiliki cara untuk mengontrol hal-hal seperti dtype .

Maaf untuk pertanyaan pemula, tetapi haruskah sesuatu seperti np.copy_like menjadi amandemen NEP-22, haruskah itu dibahas di milis, atau pendekatan apa yang paling tepat untuk itu?

Kami tidak benar-benar memiliki aturan ketat tentang ini, tetapi saya akan condong ke menempatkan np.copy_like dan np.duckarray (atau apa pun yang kami sebut itu) bersama-sama ke dalam NEP baru untuk memaksa / membuat susunan bebek, satu yang bersifat preskriptif seperti NEP 18 daripada "Informasional" seperti NEP 22. Tidak perlu panjang, sebagian besar motivasinya sudah jelas dari mereferensikan NEP 18/22.

Satu catatan tentang np.copy_like() : itu pasti akan melakukan pengiriman dengan __array_function__ (atau semacamnya), jadi operasi seperti np.copy_like(sparse_array, like=dask_array) dapat didefinisikan baik pada tipe array manapun.

Bagus, terima kasih atas informasinya, dan saya setuju dengan proposal pengiriman Anda. Saya akan mengerjakan NEP untuk implementasi np.duckarray dan np.copy_like dan mengirimkan draf PR minggu ini untuk itu.

Luar biasa, terima kasih Peter!

Pada hari Senin, 1 Juli 2019 jam 9:29 Peter Andreas Entschev <
[email protected]> menulis:

Bagus, terima kasih atas informasinya, dan saya setuju dengan proposal pengiriman Anda. saya
akan mengerjakan NEP untuk implementasi np.duckarray dan
np.copy_like dan kirimkan draf PR minggu ini untuk itu.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/numpy/numpy/issues/13831?email_source=notifications&email_token=AAJJFVW2YUBNUCJZK6JWDBTP5IWHNA5CNFSM4H3HQWAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY6VM3Q#issuecomment-507336302 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAJJFVR2KTPAZ4JPWDYYMFLP5IWHNANCNFSM4H3HQWAA
.

Dengan senang hati, dan terima kasih banyak atas ide dan dukungannya dengan pekerjaan ini!

Fungsi array_like dan copy_like akan sedikit aneh untuk dimiliki di namespace utama saya pikir, karena kita tidak dapat memiliki implementasi default (setidaknya tidak ada yang akan melakukan pemikiran yang benar untuk cupy / dask / sparse / etc), bukan? Mereka hanya berguna saat diganti. Atau apakah saya kehilangan cara untuk membuat objek array non-numpy yang sewenang-wenang di sini?

Memang benar, ini hanya akan sangat berguna jika Anda ingin mendukung pengetikan bebek. Tapi tentu saja np.duckarray dan np.copy_like akan berfungsi bahkan jika argumennya hanya array NumPy - mereka hanya akan setara dengan np.array / np.copy .

Semua implementasi array memiliki metode copy kan? Menggunakan itu daripada copy_like seharusnya berfungsi, jadi mengapa menambahkan fungsi baru?

array_like Saya melihat kebutuhannya, tapi kita mungkin ingin mendiskusikan di mana harus menaruhnya.

np.duckarray memang masuk akal bagi saya.

Saya akan condong ke arah menempatkan np.copy_like dan np.duckarray (atau apa pun yang kita sebut itu) bersama-sama ke dalam NEP baru tentang pemaksaan / pembuatan susunan bebek, yang bersifat preskriptif seperti NEP 18 daripada "Informasi" seperti NEP 22.

+1

array_like Saya bisa melihat kebutuhannya, tapi kita mungkin ingin mendiskusikan di mana menaruhnya.

Itu sebenarnya kasus yang ingin saya tangani dengan sesuatu seperti np.copy_like . Saya belum menguji, tapi mungkin np.copy sudah terkirim dengan benar jika arraynya non-NumPy.

Untuk memperjelas, apakah Anda juga mengacu pada fungsi np.array_like ? Saya sengaja menghindari nama seperti itu karena saya pikir itu bisa membingungkan semua referensi yang ada ke array_like -arrays. Namun, sekarang saya menyadari bahwa np.copy_like mungkin menyiratkan salinan yang diperlukan, dan saya pikir akan lebih baik untuk memiliki perilaku yang mirip dengan np.asarray , di mana salinan hanya terjadi jika belum menjadi NumPy Himpunan. Dalam kasus yang didiskusikan di sini, yang terbaik adalah membuat salinan hanya jika a bukan tipe yang sama dengan b dalam panggilan seperti np.copy_like(a, like=b) .

Saya belum menguji, tapi mungkin np.copy sudah dikirim dengan benar jika arraynya non-NumPy.

Seharusnya, itu dihiasi untuk mendukung __array_function__ .

Untuk memperjelas, apakah Anda juga mengacu pada fungsi np.array_like ? Saya sengaja menghindari nama seperti itu karena saya pikir itu bisa membingungkan semua referensi yang ada ke array_like-arrays.

Iya. Dan ya setuju itu bisa membingungkan.

Namun, sekarang saya menyadari bahwa np.copy_like mungkin menyiratkan salinan yang diperlukan,

Ya, nama itu menyiratkan salinan data.

mungkin menyiratkan salinan yang diperlukan, dan saya pikir akan lebih baik jika memiliki perilaku yang mirip dengan np.asarray ,

Saya pikir itu np.duckarray .

Saya pikir contoh Petrus di atas dapat membantu menjelaskan hal ini. Disalin di bawah dan diganti dengan np.copy_like untuk kesederhanaan.

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

Saya pikir itu np.duckarray.

Sebenarnya, np.duckarray pada dasarnya tidak akan melakukan apa-apa dan hanya mengembalikan array itu sendiri (jika diganti), jika tidak mengembalikan np.asarray (mengarah ke array NumPy). Kami tidak bisa mendapatkan array CuPy dari daftar Python dengan itu, misalnya. Kita masih membutuhkan fungsi yang dapat dikirim ke CuPy (atau array like= ) untuk array_like .

Terima kasih @jakirkham untuk contoh yang diperbarui.

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

Jadi itu akan dikirim ke CuPy melalui a.__array_function__ dan gagal jika atribut itu tidak ada (mis. a=<scipy.sparse matrix> tidak akan berfungsi)? Rasanya seperti kita membutuhkan namespace baru atau paket utilitas interoperabilitas baru untuk hal semacam itu. Entah itu atau serahkan pada mekanisme pengiriman masa depan dengan fitur lengkap di mana seseorang dapat dengan mudah melakukan:

with cupy_backend:
   np.array(b)

Memperkenalkan fungsi baru di namespace utama yang tidak masuk akal bagi NumPy itu sendiri untuk mendukung bekerja dengan batasan __array_function__ tampaknya agak tidak sehat ....

Jadi itu akan dikirim ke CuPy melalui a.__array_function__ dan gagal jika atribut itu tidak ada (mis. a=<scipy.sparse matrix> tidak berfungsi)?

Saya tidak akan mengatakan itu harus gagal. Kita bisa default ke NumPy dan memunculkan peringatan (atau tidak menaikkannya sama sekali), misalnya.

Rasanya seperti kita membutuhkan namespace baru atau paket utilitas interoperabilitas baru untuk hal semacam itu. Entah itu atau serahkan pada mekanisme pengiriman masa depan dengan fitur lengkap

Tentu akan menyenangkan memiliki mekanisme pengiriman berfitur lengkap, tetapi saya membayangkan ini tidak dilakukan sebelumnya karena kompleksitas dan masalah kompatibilitasnya? Saya tidak ada saat diskusi terjadi, jadi hanya menebak-nebak.

Memperkenalkan fungsi baru di namespace utama yang tidak masuk akal bagi NumPy sendiri untuk mendukung bekerja di sekitar batasan __array_function__ tampaknya sedikit tidak sehat ....

Saya benar-benar mengerti maksud Anda, tetapi saya juga berpikir bahwa jika kita memindahkan terlalu banyak hal dari namespace utama, itu dapat membuat pengguna takut. Mungkin saya salah dan ini hanya kesan. Either way, saya sama sekali tidak mengusulkan untuk mengimplementasikan fungsi yang tidak akan berfungsi dengan NumPy, tetapi mungkin hanya tidak mutlak diperlukan saat menggunakan NumPy dengan sendirinya.

Memperkenalkan fungsi baru di namespace utama yang tidak masuk akal bagi NumPy sendiri untuk mendukung bekerja di sekitar batasan __array_function__ tampaknya sedikit tidak sehat ....

Sebenarnya, dalam pengertian ini, juga np.duckarray tidak akan termasuk dalam namespace utama.

Sebenarnya, dalam pengertian ini, juga np.duckarray tidak akan termasuk dalam namespace utama.

Saya pikir yang satu lebih dapat dipertahankan (analog dengan asarray dan pada dasarnya akan memeriksa "apakah ini memenuhi definisi kita tentang tipe bebek seperti ndarray"), tapi ya. Jika kita juga ingin mengekspos array_function_dispatch , dan kita memiliki np.lib.mixins.NDArrayOperatorsMixin dan berencana untuk menulis lebih banyak mixin, submodul baru yang masuk akal untuk semua hal terkait interoperabilitas dapat masuk akal.

Tentu akan menyenangkan memiliki mekanisme pengiriman berfitur lengkap, tetapi saya membayangkan ini tidak dilakukan sebelumnya karena kompleksitas dan masalah kompatibilitasnya? Saya tidak ada saat diskusi terjadi, jadi hanya menebak-nebak.

Saya pikir ada banyak alasan. __array_function__ mirip dengan barang-barang yang sudah kita miliki, jadi lebih mudah untuk bernalar. Ini memiliki overhead yang rendah. Itu dapat dirancang dan diimplementasikan dalam skala waktu ~ 6 bulan, dan @shoyer membuat alasan kuat bahwa kami membutuhkannya. Dan kami tidak punya alternatif konkret.

submodule baru yang masuk akal untuk semua hal yang terkait dengan interoperabilitas bisa masuk akal.

Tidak ada keberatan nyata dari saya, saya pikir lebih baik memiliki fungsionalitas di suatu tempat daripada di mana pun. :)

Saya pikir ada banyak alasan. __array_function__ mirip dengan hal-hal yang sudah kita miliki, jadi lebih mudah untuk bernalar. Ini memiliki overhead yang rendah. Itu dapat dirancang dan diimplementasikan dalam skala waktu ~ 6 bulan, dan @shoyer membuat alasan kuat bahwa kami membutuhkannya. Dan kami tidak punya alternatif konkret.

Tetapi jika kita ingin memanfaatkan __array_function__ secara lebih luas, apakah kita sekarang memiliki alternatif lain untuk menerapkan hal-hal seperti np.duckarray dan np.copy_like (atau apa pun yang akan kita putuskan untuk menyebutnya)? Saya terbuka untuk semua alternatif, tetapi saat ini saya tidak melihat satu pun, tentu saja, daripada menggunakan cara pengiriman fitur lengkap, yang kemungkinan akan memakan waktu lama dan membatasi ruang lingkup __array_function__ sangat (dan pada dasarnya membuatnya tidak praktis untuk sebagian besar kasus yang lebih kompleks yang pernah saya lihat).

Tetapi jika kita ingin memanfaatkan __array_function__ secara lebih luas, apakah kita sekarang memiliki alternatif lain untuk menerapkan hal-hal seperti np.duckarray dan np.copy_like (atau apa pun yang akan kita putuskan untuk menyebutnya)?

Saya rasa Anda memang memerlukan serangkaian fitur utilitas seperti itu, dari mencakup beberapa kasus penggunaan hingga> 80% kasus penggunaan. Saya tidak berpikir ada jalan lain untuk itu. Saya hanya tidak suka mengacaukan namespace utama, jadi usulkan untuk menemukan tempat yang lebih baik untuk itu.

Saya terbuka untuk semua alternatif, tetapi saat ini saya tidak melihat satu pun, tentu saja, daripada menggunakan cara pengiriman fitur lengkap, yang kemungkinan akan memakan waktu lama dan membatasi ruang lingkup __array_function__ sangat (dan pada dasarnya membuatnya tidak praktis untuk sebagian besar kasus yang lebih kompleks yang pernah saya lihat).

Maksud saya, kami hanya memasukkan beberapa lubang yang jelas di sini kan? Kami tidak akan pernah membahas semua "kasus yang lebih kompleks". Katakanlah Anda ingin mengganti np.errstate atau np.dtype , itu tidak akan terjadi dengan pendekatan berbasis protokol.

Adapun alternatif lain, uarray belum ada dan saya belum yakin bahwa overhead akan ditekan cukup rendah untuk digunakan secara default di NumPy, tetapi semakin dekat dan kami akan mencobanya untuk membuat scipy.fft sistem backend (WIP PR: https://github.com/scipy/scipy/pull/10383). Jika itu membuktikan dirinya di sana, itu harus dianggap sebagai solusi pengiriman ganda yang lengkap. Dan sudah memiliki API numpy dengan backend Dask / Sparse / CuPy / PyTorch / XND, beberapa di antaranya cukup lengkap untuk dapat digunakan: https://github.com/Quansight-Labs/uarray/tree/master/unumpy

Pendekatan pengiriman dengan uarray tentu menarik. Meskipun saya masih khawatir tentang bagaimana kami menangani meta-array (seperti Dask, xarray, dll.). Silakan lihat komentar ini untuk detailnya. Tidak jelas ini telah ditangani (meskipun tolong perbaiki saya jika saya melewatkan sesuatu). Saya tertarik untuk bekerja dengan orang lain di SciPy untuk mencoba dan mencari tahu bagaimana kami memecahkan masalah ini.

Silakan lihat komentar ini untuk detailnya. Tidak jelas ini telah ditangani (meskipun tolong perbaiki saya jika saya melewatkan sesuatu).

Saya pikir perubahan minggu lalu menyelesaikannya, tetapi tidak yakin - mari kita tinggalkan itu untuk utas lain.

Saya tertarik untuk bekerja dengan orang lain di SciPy untuk mencoba dan mencari tahu bagaimana kami memecahkan masalah ini.

Saya akan berada di sana, akan senang bertemu langsung dengan Anda.

Mungkin np.coerce_like() atau np.cast_like() akan menjadi nama yang lebih baik daripada copy_like , jadi jelas bahwa salinan tidak selalu diperlukan. Fungsionalitas yang diinginkan memang sangat mirip dengan metode .cast() , kecuali kita ingin mengonversi tipe array serta dtypes, dan itu harus berupa fungsi daripada protokol sehingga dapat diimplementasikan dengan argumen mana pun.

Pendekatan pengiriman dengan uarray tentu menarik. Meskipun saya masih khawatir tentang bagaimana kami menangani meta-array (seperti Dask, xarray, dll.).

uarray memiliki dukungan untuk beberapa backend jadi sesuatu seperti ini akan bekerja

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

Ini dapat dilakukan dengan memanggil meta-array ua.skip_backend di dalam implementasinya, atau jika backend meta-array mengembalikan NotImplemented pada jenis mismatch.

cc: @hameerabbasi

Saya akan mengembangkan ini: Sebagai aturan umum, untuk dask.array , apapun dengan da akan ditulis tanpa sebuah skip_backend. Apa pun dengan NumPy akan membutuhkan sebuah skip_backend.

Atau untuk da Anda selalu dapat melewati pengiriman dan memanggil implementasi Anda sendiri secara langsung dan memiliki skip_backend(dask.array) mana-mana.

Adapun fungsi pengiriman yang tidak memiliki array yang terpasang, seperti ones , cast , Anda hanya perlu mengatur backend dan selesai. Sama untuk np.errstate dan np.dtype . Ada contoh yang mencakup np.ufunc dalam unumpy .

Adapun terbitan asli, uarray menyediakan __ua_convert__ Protocol, yang melakukan hal ini. Alternatifnya adalah untuk backend menimpa asarray secara langsung.

Terima kasih atas perhatiannya di uarray , @rgommers , @ peterbell10 , @hameerabbasi.

Tapi seperti yang saya lihat, Anda _harus_ menyetel backend yang benar sebelum meluncurkan komputasi, apakah itu benar? Salah satu keuntungan dari __array_function__ adalah perpustakaan dapat sepenuhnya agnostik dari perpustakaan lain, seperti Dask tidak perlu mengetahui keberadaan CuPy, misalnya.

@pentschev Ini adalah kasus hingga saat ini, ketika kami menambahkan kemampuan untuk "mendaftarkan" backend, tetapi kami merekomendasikan hanya NumPy (atau implementasi referensi) yang melakukan ini. Kemudian pengguna yang menggunakan Dask hanya membutuhkan satu set_backend.

Oke, saya kira inilah yang disebutkan @rgommers di https://github.com/numpy/numpy/issues/13831#issuecomment -507432311, menunjuk ke backend di https://github.com/Quansight-Labs/uarray / tree / master / unumpy.

Mohon maaf atas banyaknya pertanyaan, tetapi bagaimana jika beberapa aplikasi hipotetis mengandalkan berbagai backend, misalnya, baik NumPy maupun Sparse, di mana bergantung pada input pengguna, mungkin semuanya hanya NumPy, Sparse-only, atau campuran keduanya. @ peterbell10 menyebutkan bahwa beberapa backend didukung https://github.com/numpy/numpy/issues/13831#issuecomment -507458331, tetapi dapatkah pemilihan backend dibuat otomatis atau adakah kebutuhan untuk menangani ketiga case secara terpisah?

Jadi, untuk kasus ini, Anda idealnya mendaftarkan NumPy, menggunakan manajer konteks untuk Sparse, dan mengembalikan NotImplemented dari sparse bila sesuai, yang akan membuat sesuatu kembali ke NumPy.

Di SciPy @rgommers , @danielballan , dan saya sendiri membicarakan masalah ini. Kami menyimpulkan bahwa akan sangat bermanfaat untuk melanjutkan dengan menambahkan duckarray (menggunakan nama itu). Yang mengatakan, sepertinya ini akan dijadwalkan untuk 1,18. Meskipun tolong perbaiki saya jika saya salah paham. Mengingat ini, apakah tidak apa-apa untuk memulai PR?

Kami menyimpulkan bahwa akan sangat bermanfaat untuk melanjutkan dengan menambahkan duckarray (menggunakan nama itu). Yang mengatakan, sepertinya ini akan dijadwalkan untuk 1,18. Meskipun tolong perbaiki saya jika saya salah paham. Mengingat ini, apakah tidak apa-apa untuk memulai PR?

Ini semua terdengar bagus bagi saya, tetapi alangkah baiknya untuk memulai dengan NEP singkat yang menjelaskan proposal yang tepat. Lihat https://github.com/numpy/numpy/issues/13831#issuecomment -507334210

Tentu itu masuk akal. 🙂

Adapun titik penyalinan yang telah dikemukakan sebelumnya, saya ingin tahu apakah ini tidak diselesaikan melalui mekanisme yang ada. Secara khusus bagaimana dengan garis-garis ini?

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

Memang, akan menyenangkan untuk menjelaskan ini ke satu baris. Hanya ingin tahu apakah ini sudah berfungsi untuk kasus penggunaan itu atau jika kita melewatkan sesuatu.

Kami menyimpulkan bahwa akan sangat berguna untuk melanjutkan dengan menambahkan duckarray (menggunakan nama itu).

Ini semua terdengar bagus bagi saya, tetapi alangkah baiknya untuk memulai dengan NEP singkat yang menjelaskan proposal yang tepat. Lihat # 13831 (komentar)

Saya sudah mulai menulis itu, belum bisa menyelesaikannya (maaf atas perencanaan buruk saya https://github.com/numpy/numpy/issues/13831#issuecomment-507336302).

Adapun titik penyalinan yang telah dikemukakan sebelumnya, saya ingin tahu apakah ini tidak diselesaikan melalui mekanisme yang ada. Secara khusus bagaimana dengan garis-garis ini?

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

Memang, akan menyenangkan untuk menjelaskan ini ke satu baris. Hanya ingin tahu apakah ini sudah berfungsi untuk kasus penggunaan itu atau jika kita melewatkan sesuatu.

Anda dapat melakukannya, tetapi mungkin memerlukan logika penyalinan khusus (seperti di CuPy https://github.com/cupy/cupy/pull/2079).

Karena itu, fungsi salin mungkin yang terbaik, untuk menghindari kode tambahan semacam ini diperlukan.

Di sisi lain, ini akan menjadi semacam pengganti asarray . Jadi saya bertanya-tanya apakah alih-alih fungsi baru copy_like , kami malah ingin meninjau kembali gagasan yang disarankan oleh NEP-18 :

Ini membutuhkan protokol mereka sendiri:
...
array dan asarray, karena keduanya secara eksplisit dimaksudkan untuk pemaksaan ke objek numpy.ndarray yang sebenarnya.

Jika ada kesempatan kami ingin mengunjunginya lagi, mungkin akan lebih baik untuk memulai utas baru. Ada ide, saran, keberatan?

Hanya untuk memperjelas komentar saya di atas, saya sendiri tidak tahu apakah protokol baru adalah ide yang bagus (mungkin banyak detail rumit yang tidak saya duga terlibat), benar-benar hanya bertanya-tanya apakah itu ide yang harus kita kunjungi dan diskusikan kembali .

Konsensus dari pertemuan dev dan sprint di SciPy'19 adalah: mari kita keluarkan 1.17.0 dan dapatkan pengalaman dunia nyata dengannya sebelum mengambil langkah selanjutnya.

benar-benar hanya ingin tahu apakah itu ide yang harus kita bahas kembali dan diskusikan.

mungkin ya, tapi dalam beberapa bulan.

mungkin ya, tapi dalam beberapa bulan.

Oke, terima kasih atas jawabannya!

Adapun titik penyalinan yang telah dikemukakan sebelumnya, saya ingin tahu apakah ini tidak diselesaikan melalui mekanisme yang ada. Secara khusus bagaimana dengan garis-garis ini?

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

Memang, akan menyenangkan untuk menjelaskan ini ke satu baris. Hanya ingin tahu apakah ini sudah berfungsi untuk kasus penggunaan itu atau jika kita melewatkan sesuatu.

Masalah utama saya dengan ini adalah bahwa itu tidak akan berfungsi untuk susunan bebek yang tidak berubah, yang tidak terlalu jarang. Juga, untuk NumPy, biaya tambahan untuk mengalokasikan sebuah array dan kemudian mengisinya mungkin hampir nol, tapi saya tidak yakin itu benar untuk semua array duck.

Adapun titik penyalinan yang telah dikemukakan sebelumnya, saya ingin tahu apakah ini tidak diselesaikan melalui mekanisme yang ada. Secara khusus bagaimana dengan garis-garis ini?

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

Memang, akan menyenangkan untuk menjelaskan ini ke satu baris. Hanya ingin tahu apakah ini sudah berfungsi untuk kasus penggunaan itu atau jika kita melewatkan sesuatu.

Anda dapat melakukannya, tetapi mungkin memerlukan logika penyalinan khusus (seperti di CuPy cupy / cupy # 2079 ).

Karena itu, fungsi salin mungkin yang terbaik, untuk menghindari kode tambahan semacam ini diperlukan.

Di sisi lain, ini akan menjadi semacam pengganti asarray . Jadi saya bertanya-tanya apakah alih-alih fungsi baru copy_like , kami malah ingin meninjau kembali gagasan yang disarankan oleh NEP-18 :

Ini membutuhkan protokol mereka sendiri:
...
array dan asarray, karena keduanya secara eksplisit dimaksudkan untuk pemaksaan ke objek numpy.ndarray yang sebenarnya.

Jika ada kesempatan kami ingin mengunjunginya lagi, mungkin akan lebih baik untuk memulai utas baru. Ada ide, saran, keberatan?

Saya tidak berpikir itu ide yang baik untuk mengubah perilaku np.array atau np.asarray dengan protokol baru. Arti mapan mereka adalah untuk dilemparkan ke array NumPy, yang pada dasarnya mengapa kita membutuhkan np.duckarray

Karena itu, kita dapat mempertimbangkan untuk menambahkan argumen like ke duckarray . Itu akan membutuhkan perubahan protokol dari proposal yang disederhanakan di atas - mungkin menggunakan __array_function__ daripada protokol khusus seperti __duckarray__ ? Saya belum benar-benar memikirkan hal ini.

Adapun titik penyalinan yang telah dikemukakan sebelumnya, saya ingin tahu apakah ini tidak diselesaikan melalui mekanisme yang ada. Secara khusus bagaimana dengan garis-garis ini?

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

Memang, akan menyenangkan untuk menjelaskan ini ke satu baris. Hanya ingin tahu apakah ini sudah berfungsi untuk kasus penggunaan itu atau jika kita melewatkan sesuatu.

Masalah utama saya dengan ini adalah bahwa itu tidak akan berfungsi untuk susunan bebek yang tidak berubah, yang tidak terlalu jarang. Juga, untuk NumPy, biaya tambahan untuk mengalokasikan sebuah array dan kemudian mengisinya mungkin hampir nol, tapi saya tidak yakin itu benar untuk semua array duck.

Itu adil. Sebenarnya kita sudah bisa menyederhanakan banyak hal. Misalnya ini berfungsi dengan CuPy dan Sparse hari ini.

a2 = np.copy(a1)

Itu adil. Sebenarnya kita sudah bisa menyederhanakan banyak hal. Misalnya ini berfungsi dengan CuPy dan Sparse hari ini.

a2 = np.copy(a1)

Ya, tapi kami juga ingin "menyalin susunan bebek ini ke dalam jenis susunan bebek lainnya"

Menurut saya bukan ide yang baik untuk mengubah perilaku np.array atau np.asarray dengan protokol baru. Arti mapan mereka adalah untuk dilemparkan ke array NumPy, yang pada dasarnya mengapa kita membutuhkan np.duckarray

Saya juga tidak yakin tentang ini, dan saya bahkan enggan untuk mengajukan pertanyaan ini, inilah mengapa saya tidak melakukannya sampai hari ini.

Karena itu, kami dapat mempertimbangkan untuk menambahkan argumen serupa ke duckarray. Itu akan membutuhkan perubahan protokol dari proposal yang disederhanakan di atas - mungkin menggunakan __array_function__ daripada protokol khusus seperti __duckarray__? Saya belum benar-benar memikirkan hal ini.

Saya tidak tahu apakah akan ada komplikasi dengan itu, kita mungkin perlu berhati-hati, tapi saya cenderung menyukai ide ini. Itu akan tampak berlebihan di berbagai tingkatan, tetapi mungkin untuk mengikuti pola yang ada, daripada menambahkan parameter like kita dapat memiliki duckarray dan duckarray_like ?

Ya, tapi kami juga ingin "menyalin susunan bebek ini ke dalam jenis susunan bebek lainnya"

Bagaimana dengan mendasarkan ini sekitar np.copyto ?

Bagaimana dengan mendasarkan ini sekitar np.copyto ?

Jangan ragu untuk mengoreksi saya jika saya salah, tetapi saya berasumsi yang Anda maksud seperti:

np.copyto(cupy_array, numpy_array)

Itu bisa berhasil, dengan asumsi NumPy bersedia mengubah perilaku saat ini, misalnya, asarray selalu menyiratkan bahwa tujuannya adalah array NumPy, apakah copyto membuat asumsi yang sama?

np.copyto sudah mendukung pengiriman dengan __array_function__ , tetapi secara kasar setara dengan:

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

Kami ingin yang setara dengan:

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

np.copyto sudah mendukung pengiriman dengan __array_function__ , tetapi secara kasar setara dengan:

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

Kami ingin yang setara dengan:

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

Benar, inilah yang kita inginkan. copyto dikirim dan berfungsi jika sumber dan tujuan memiliki tipe yang sama, kita memerlukan sesuatu yang memungkinkan pengiriman ke pustaka array tujuan.

Ya copyto masih bisa masuk akal tergantung bagaimana kita memikirkannya. Ambil contoh kasus penggunaan berikut.

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

Ini dapat diterjemahkan menjadi sesuatu seperti mengalokasikan dan menyalin data seperti yang telah kita diskusikan. Jika kita mengirimkan sekitar dst ( cp.ndarray dalam kasus ini), maka perpustakaan dengan larik yang tidak dapat diubah dapat mengimplementasikan ini dengan cara yang sesuai juga. Ini juga menyelamatkan kita dari menambahkan API baru (yang hanya disediakan NumPy, tetapi tidak digunakan), yang tampaknya menjadi perhatian.

Hanya untuk memunculkan pemikiran lain yang muncul pada saya baru-baru ini, ada baiknya memikirkan tentang apa arti API ini di hilir antara pustaka lain (misalnya bagaimana Dask dan Xarray berinteraksi).

Apakah halaman ini membantu?
0 / 5 - 0 peringkat