Saya pikir kami akan tertarik untuk menambahkan dukungan opsional untuk tensor kompleks. Cara terbaik adalah dengan bercabang dan bekerja pada pustaka C di torch/lib . Ini harus bebas konflik dengan master, sehingga Anda dapat melakukan ini untuk waktu yang lama. Setelah Anda mendapatkan lib ke status yang dapat digunakan, Anda dapat mulai menulis binding, dan di sinilah kami dapat memberikan beberapa panduan tentang cara menghindari konflik pada saat itu.

Saya punya TH dengan kompilasi tipe kompleks. Apa yang perlu saya tambahkan untuk integrasi python?

@PhilippPelz maksud Anda seperti: https://github.com/facebook/ztorch/tree/master/lib/THZ ? atau apakah Anda membuat garpu TH Anda sendiri yang memungkinkan tipe kompleks?

@killient memiliki beberapa catatan tentang bagaimana TH terikat dengan Python, dia dapat membagikannya.

Secara umum, untuk memasukkan Tensor kompleks, saya lebih suka THZ, karena memiliki tes, dll.

Membangun backend CUDA untuk Tensor kompleks, adalah upaya yang cukup besar, kami bahkan belum memulainya.

Saya telah menulis z-cutorch ( https://github.com/PhilippPelz/z-cutorch ) beberapa waktu lalu. Ini adalah garpu off cutorch sebelum refactoring untuk CudaHalfTensor (belum memiliki perangkat keras).

Ini bagus. Saya kira Anda sudah mendorong upaya besar ke arah itu :)

@soumith saya melakukan garpu TH dengan tipe kompleks. Pada dasarnya THGenerateComplexTypes.h + menambahkan rutinitas BLAS + LAPACK sisanya hampir gratis. Tampaknya jauh lebih sedikit pekerjaan bagi saya daripada memeriksa bagian mana dari THZ yang kompatibel dan kemudian menyalin tempel.

Saya terjebak dengan kompilasi THPP sekarang, mencari tahu pesan kompiler seperti

/home/philipp/projects/pytorch/torch/lib/tmp_install/include/TH/generic/THBlas.h:6:40: error: diharapkan ',' atau '...' sebelum token '*'
TH_API void THBlas_(swap)(long n, real *, long incx, real *, long incy);

sedikit rumit.

Saya sangat menghargai bantuan tentang cara mengaktifkan integrasi python. Backend CUDA sebagian besar harus disalin dari z-cutorch.

@PhilippPelz berikut adalah beberapa catatan tentang pembungkus PyTorch TH: https://Gist.github.com/killeen/4675635b40b61a45cac2f95a285ce3c0

@killient terima kasih, terlihat sangat membantu. lib/build_all.sh sekarang sedang dikompilasi, saya pikir saya bisa melihat direktori csrc.

Ini sekarang berjalan:

impor obor sebagai ini
impor numpy sebagai np

a = np.array([1+1j,2+2j])
b = np.array([3+3j,4+4j])
ath = th.from_numpy(a)
bth = th.from_numpy(b)
ath_cuda = ath.cuda()
ath_cuda += bth.cuda()
ath = ath_cuda.cpu()
cetak(ath.numpy())

Keluar: [ 4.+4.j 6.+6.j]

bersama dengan sebagian besar fungsi matematika.
Saya akan menambahkan fungsi kenyamanan dan fft selama beberapa minggu ke depan. Saya kira perlu ada tes untuk semuanya sebelum Anda dapat menggabungkan ini. Jika Anda mengenal orang lain yang tertarik dengan tensor kompleks dan bersedia berkontribusi untuk menulis tes, itu akan luar biasa. Makalah ini muncul di benak: Deep Complex Networks , mungkin orang-orang itu tertarik.
Saya tidak akan punya waktu untuk menulis semua tes sendiri.

@PhilippPelz Terima kasih atas komentar Anda. Saya sedang memeriksa implementasi Anda. Dan pertama, saya tidak yakin tentang implementasi ger Anda. Beberapa fungsi blas yang kompleks tidak disertakan dalam THBlas.c Anda seperti Anda mendefinisikan GER sebagai zger_ dan cger_ di header generate, tetapi tidak ada fungsi blas dengan cger_ di generik/THBlas.c . Padahal, saya bisa menggunakan gemv Anda dan beberapa fungsi lainnya. Dan IMO mungkin Anda harus menambahkan .gch ke .gitignore? Sudahkah Anda mendorong semua ekstensi ke fork Anda? Saya dapat membuat beberapa permintaan tarik ke master Anda berdasarkan implementasi Anda terlebih dahulu.

Dan untuk DOT Saya kira mungkin untuk vektor kompleks, dotc rutinitas untuk titik lebih umum?

Dan ya, jika hanya menggunakan real akan lebih mudah untuk implementasi, saya hanya merasa aneh ketika real sebenarnya kompleks...

Dan untuk tes, saya tidak melihat tes sebelumnya untuk TH. Di mana saya harus menulis tes itu? atau kami hanya menulis beberapa tes python

Ya, maaf saya melihat saya mungkin tidak mendorong semua yang diperlukan. Saya akan memeriksanya lagi pada hari Senin. Beberapa deklarasi hilang, mis. zger dan cger

Untuk DOT saya menggunakan cdotc dan zdotc, sepertinya hilang, saya akan memperbarui minggu depan.

Periksa dengan pengelola pytorch penamaan apa yang mereka sukai secara nyata. Saya lebih suka versi Anda, hanya belum berusaha.

Ya, tes python untuk hal-hal matematika. Harus mudah diubah agar sebagian besar fungsi juga menyertakan pemeriksaan nomor kompleks.

Keren bahwa Anda juga melihat ke dalam ini!

Oke, saya mendorong beberapa perubahan. Rutinitas TH blas ada sekarang untuk kompleks

@PhilippPelz Saya baru saja membuat permintaan tarik ke repo Anda. Dan untuk lapisan linier kompleks dan beberapa operator lainnya. mungkin ada banyak operasi hermitian (seperti bp untuk lapisan linier kompleks). Mungkin menambahkan beberapa fungsi untuk tensor? Sudahkah Anda memeriksa bagian THNN?

Ya pertapa berguna. cuda fft berfungsi sekarang. cpu fft dapat dibungkus dari numpy. Saya belum menyentuh THNN atau THCUNN.

@PhilippPelz Saya telah menambahkan seorang pertapa sederhana di PR. Dan bisakah Anda meninjaunya. Jadi kita bisa melihat apakah perubahan itu cocok dan pindah ke langkah berikutnya. Terima kasih! PS. sepertinya Anda melewatkan beberapa tajuk, saya juga memperbaikinya dan beberapa peringatan lainnya. Untuk fungsi kompleks dengan output nyata, haruskah kita mengembalikan tensor nyata daripada tensor kompleks? Saya telah menerapkan metode penyalinan antara tipe kompleks dan nyata, jadi itu mungkin.

Saya akan rebase semua komit setelah ulasan Anda.

@PhilippPelz Hai, saya cukup bingung tentang bagian THPP yang Anda terapkan. Mengapa memiliki ketergantungan pada dorongan di Traits.hpp ?. Ini akan menyebabkan kesalahan saat kompilasi tanpa cuda. Apakah mungkin hanya menggunakan sukaataudi Traits.hpp ? Saya belum mengetahuinya. Mungkin Anda bisa menawarkan beberapa petunjuk?

@ Roger-luo Ya, saya juga mengalami beberapa masalah dengan itu di tempat lain. Tipe kompleks yang kita gunakan harus dari complex.h atau std::complex. Karena THPP adalah pembungkus C++, mungkin std::complex lebih tepat. Bisakah Anda mengubahnya?

Dorongan juga menyebabkan masalah untuk alasan yang sama persis ketika mencoba membangun ekstensi cffi. Saat ini saya sedang melakukan solusi, tetapi cara yang tepat adalah dengan mengubah tipe kompleks menjadi cuFloatComplex/cuDoubleComplex di THC. sehingga kompiler cffi tidak mengeluh. Saya hanya ingin melanjutkan penelitian sekarang, ini mengambil terlalu banyak waktu dari saya :( . Jika Anda punya waktu, silakan lakukan.

Juga, membangun ekstensi cffi dengan panggilan kernel khusus cukup rumit, karena kita selalu perlu membuat perpustakaan tambahan yang dikompilasi dengan nvcc, yang kemudian ditautkan ke pembungkus cffi. Kurasa tidak ada cara lain. Seseorang dapat menggunakan cffi dalam mode ABI, tetapi situs web mengatakan "Mode API malah mengkompilasi pembungkus CPython C yang secara langsung memanggil fungsi target. Ini, secara komparatif, jauh lebih cepat (dan bekerja lebih baik daripada yang bisa dilakukan libffi)."

@PhilippPelz mungkin reinterpret_cast bisa jadi solusi? Saya kira itu harus diubah menjadi cuComplex , dan gunakan reinterpret_cast di THPP. saya coba dulu...

Ya, saya kira tidak ada cara lain selain reinterpret_cast jika Anda ingin THPP membangun juga tanpa cuda diinstal.

@PhilippPelz Saya ingin membantu. Apakah ada daftar tugas di mana saja?

THNN dan THCUNN perlu diaktifkan untuk tipe kompleks. Bisakah Anda berkoordinasi dengan @roger-luo? Juga, jika kita bertujuan untuk integrasi dengan master, tes unit perlu ditulis untuk semua metode yang kompleks.

@elbamos Sebagian besar pekerjaan di THNN akan tentang menerapkan metode backpropagtion kompleks baru untuk setiap lapisan yang ada. Ada PR WIP di garpu Philipp. Saya telah mencantumkan beberapa referensi.

@apaszke @soumith @PhilippPelz Dan ada dua pertanyaan:

• adakah yang tahu mengapa ada file GenerateXXXTypes.h lain di THS ? Itu terlihat sama dengan yang ada di TH .

• Untuk apa kode berikut di byte_order.cpp ?

void THP_decodeFloatBuffer(float* dst, const uint8_t* src, THPByteOrder order, size_t len)
{
  for (size_t i = 0; i < len; i++) {
    union { uint32_t x; float f; };
    x = (order == THP_BIG_ENDIAN ? decodeUInt32BE(src) : decodeUInt32LE(src));
    dst[i] = f;
    src += sizeof(float);
  }
}

void THP_decodeDoubleBuffer(double* dst, const uint8_t* src, THPByteOrder order, size_t len)
{
  for (size_t i = 0; i < len; i++) {
    union { uint64_t x; double d; };
    x = (order == THP_BIG_ENDIAN ? decodeUInt64BE(src) : decodeUInt64LE(src));
    dst[i] = d;
    src += sizeof(double);
  }
}

Adakah saran untuk mengimplementasikan versi kompleks terkaitnya? Saya tidak yakin apakah implementasi berikut ini benar...

void THP_decodeZFloatBuffer(std::complex<float>* dst, const uint8_t* src, THPByteOrder order, size_t len)
{
  for (size_t i = 0; i < len; i++) {
    union { uint64_t x; std::complex<float> cf;};
    x = (order == THP_BIG_ENDIAN ? decodeUInt64BE(src) : decodeUInt64LE(src));
    dst[i] = cf;
    src += sizeof(std::complex<float>);
  }
}

void THP_decodeDoubleBuffer(std::complex<double>* dst, const uint8_t* src, THPByteOrder order, size_t len)
{
  for (size_t i = 0; i < len; i++) {
    union { uint128_t x; std::complex<double> df;};
    x = (order == THP_BIG_ENDIAN ? decodeUInt128BE(src) : decodeUInt128LE(src));
    dst[i] = df;
    src += sizeof(std::complex<double>);
  }
}

Sebelumnya decodeUInt128XE dinyatakan sebagai

static inline uint128_t decodeUInt128LE(const uint8_t *data) {
  return (((uint128_t)data[ 0])<<  0) | (((uint128_t)data[ 1])<<  8)|
         (((uint128_t)data[ 2])<< 16) | (((uint128_t)data[ 3])<< 24)|
         (((uint128_t)data[ 4])<< 32) | (((uint128_t)data[ 5])<< 40)|
         (((uint128_t)data[ 6])<< 48) | (((uint128_t)data[ 7])<< 56)|
         (((uint128_t)data[ 8])<< 64) | (((uint128_t)data[ 9])<< 72)|
         (((uint128_t)data[10])<< 80) | (((uint128_t)data[11])<< 88)|
         (((uint128_t)data[12])<< 96) | (((uint128_t)data[13])<<104)|
         (((uint128_t)data[14])<<112) | (((uint128_t)data[15])<<120);
}

static inline uint128_t decodeUInt128BE(const uint8_t *data) {
  return (((uint128_t)data[15])<<  0) | (((uint128_t)data[14])<<  8)|
         (((uint128_t)data[13])<< 16) | (((uint128_t)data[12])<< 24)|
         (((uint128_t)data[11])<< 32) | (((uint128_t)data[10])<< 40)|
         (((uint128_t)data[ 9])<< 48) | (((uint128_t)data[ 8])<< 56)|
         (((uint128_t)data[ 7])<< 64) | (((uint128_t)data[ 6])<< 72)|
         (((uint128_t)data[ 5])<< 80) | (((uint128_t)data[ 4])<< 88)|
         (((uint128_t)data[ 3])<< 96) | (((uint128_t)data[ 2])<<104)|
         (((uint128_t)data[ 1])<<112) | (((uint128_t)data[ 0])<<120);
}

Saat ini saya menggunakan std::complex<T> alih-alih T _Complex di THPP . Saya belum yakin ini bisa digunakan oleh Python. Atau hanya tipe c T _Complex yang dapat digunakan untuk python. Jadi di sini jenis dst adalah std::complex<T> .

Dan jika saya benar untuk implementasi ini, mungkin kita memerlukan implementasi uint128_t , seperti https://github.com/calccrypto/uint128_t ? Karena tampaknya tidak semua kompiler mendukung integer 128-bit (gcc memiliki int128_t dan uint128_t).

@PhilippPelz saya perhatikan garpu Anda tidak mengaktifkan masalah - apa status proyek Anda? saya sedikit kecewa karena tensor kompleks tidak ada dalam peta jalan untuk pytorch

@el3ment Saya telah menambahkan backend kompleks untuk CPU https://github.com/pytorch/pytorch/pull/4899 Tapi itu belum ditinjau ... Dan saya belum menerima komentar untuk PR saya, jadi saya beralih untuk menggunakan bahasa pemrograman Julia baru-baru ini...

Saya mengirim email ke @PhilippPelz terakhir kali, saya kira repo-nya masih di bawah v0.1 dan dia sibuk untuk tesis sampai September? Dan saya sedang mengerjakan backend CUDA v0.3 yang baru, tetapi saya tidak punya waktu untuk menyelesaikan semua binding ini sendirian. Fungsi peta/pengurangan berbeda dari v0.1 dengan beberapa pengoptimalan tetapi tidak dapat dengan mudah dikonversi untuk mendukung bilangan kompleks. Saya akan sangat senang jika ada yang bersedia membantu...

Saya bersedia membantu.

Pada 10 April 2018, pukul 22.52, Rogerluo [email protected] menulis:

@el3ment Saya telah menambahkan backend kompleks untuk CPU #4899

Saya mengirim email ke @PhilippPelz terakhir kali, saya kira repo-nya masih di bawah v0.1 dan dia sibuk untuk tesis sampai September? Dan saya sedang mengerjakan backend CUDA v0.3 yang baru, tetapi saya tidak punya waktu untuk menyelesaikan semua binding ini sendirian. Fungsi peta/pengurangan berbeda dari v0.1 dengan beberapa pengoptimalan tetapi tidak dapat dengan mudah dikonversi untuk mendukung bilangan kompleks. Saya akan sangat senang jika ada yang bersedia membantu...

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau matikan utasnya.

@elbamos keren, sepertinya tim pytorch lebih suka implementasi yang terpisah. Saya akan memperbarui garpu saya nanti untuk bagian lain nanti. Tapi saya benar-benar tidak punya waktu untuk ini dan saya kira kita harus mulai mengerjakannya ketika ada rencana dari tim pytorch karena ini akan menjadi ekstensi besar untuk pytorch.

Hai, kode saya ada di beberapa komit setelah v0.2

Saya telah melihat bahwa ada refactor yang cukup besar yang memindahkan semua kode tensor ke Aten. Ini berarti seseorang tidak dapat dengan mudah menggabungkan garpu saya ke versi saat ini dan mungkin ada beberapa pekerjaan lagi yang terlibat.

Saya masih menulis Ph.D., tapi saya berencana untuk menunggu 0.4 sampai penggabungan Variabel dan Tensor dirilis. Saya khawatir mungkin ada terlalu banyak refactoring yang terjadi untuk mengejarnya jika seseorang melakukannya lebih awal.

@elbamos jika Anda mau, Anda dapat mulai menambahkan barang ke garpu saya, saya akan menggabungkannya. Di tempat Anda, saya hanya akan mengimplementasikan apa yang Anda butuhkan untuk proyek apa pun yang Anda lakukan. TH(CU)NN adalah antarmuka yang cukup besar dan akan menjadi beban kerja yang sangat besar.

@el3ment Saya tidak punya waktu untuk mengerjakan masalah orang lain. Namun, saya akan menggabungkan hal-hal jika Anda perlu mengimplementasikan sesuatu yang tidak ada.

Jika Anda hanya menginginkan sesuatu yang bekerja dengan bilangan kompleks di luar kotak, saya akan sangat merekomendasikan tensorflow.

Saya juga akan membantu jika ada masalah kompilasi.

Jika saya melanjutkan dengan postdoc, saya akan mem-porting semua ini ke versi saat ini di beberapa titik. Sungguh menyedihkan bahwa facebook tidak mau mendukung hal ini. :((

@PhilippPelz Setuju, ini sangat menyedihkan dan sebenarnya tensorflow tidak mendukung semua operator dalam fisika kuantum... Saya sudah mulai menggunakan Julia dan meninggalkan python.

@Roger-luo menarik, apakah Anda menggunakan paket julia tertentu atau semua kode yang ditulis sendiri?

@PhilippPelz Saya sedang mengembangkan toolkit banyak tubuh kuantum di Julia (sejak itu PyTorch PR), itu termasuk implementasi jaringan saraf yang kompleks/nyata berdasarkan beberapa makalah sebelumnya tentang jaringan saraf kompleks, dan saya merasa sangat mudah untuk dikembangkan dengan Julia's pemrograman meta. Saat ini saya baru saja memasukkannya ke QMTK.jl , masih dalam proses dan saya belum menyelesaikan semua yang saya inginkan. PyTorch memang sangat menginspirasi saya, tetapi sangat menyesal atas dukungan yang rumit ...

Tetapi saya punya rencana untuk memisahkannya ke paket tunggal jaringan saraf di masa depan (hanya tidak ingin mempertahankan beberapa repo saat ini). Dan akan ada lebih banyak orang yang bergabung dalam pengembangan dari Institut Fisika, CAS. Saya akan menerima PR setelah versi pertama yang diberi tag (yang akan dirilis dalam beberapa minggu).

Anda bisa menontonnya jika tertarik dengan perkembangannya.

Jika tim PyTorch masih memiliki rencana untuk dukungan kompleks di masa mendatang, saya akan bersedia membantu.

Keren, aku akan mengawasinya!

Hai teman-teman, mohon maaf karena kami belum menanggapi masalah ini sejak dibuka.

Berikut adalah dua fakta:

1. Kami sangat setuju bahwa PyTorch membutuhkan dukungan yang kompleks, dan
2. Kami tidak memiliki tenaga kerja yang cukup untuk mengisi ekor panjang yang dibutuhkan oleh semua operasi kompleks. (Untuk bukti ini, lihat dukungan yang jarang, yang ada di master dan telah tertatih-tatih.)

Sejak masalah ini dibuka kembali pada tahun 2017, beberapa hal penting telah berubah yang mungkin membuat penerapan dukungan kompleks menjadi sedikit lebih sederhana. Yang pertama adalah kita sekarang memiliki ATen, library C++ yang ergonomis untuk memanipulasi tensor. Ini berarti bahwa Anda tidak perlu menyalin petak raksasa kode TH/THC dan berharap Anda mendapatkan semua penghitungan ulang manual dengan benar, Anda dapat menulis kode C++ seolah-olah itu adalah Python dan itu akan berjalan cepat. Kedua adalah bahwa kami sedang mengerjakan versi baru ATen, yang disebut C10, yang jauh lebih serius tentang memiliki backend terbuka daripada ATen (yang merupakan hal yang tertutup) yang seharusnya membuatnya lebih mudah untuk bekerja pada dukungan yang kompleks, karena itu tidak akan ' t memerlukan benar-benar forking PyTorch, hanya menambahkan direktori kode baru.

Jadi, @Roger-luo dan @PhilippPelz , kami ingin bantuan Anda membuat backend kompleks menjadi kenyataan, tetapi kami benar-benar ingin mencari cara untuk melakukannya yang membantu kami mempertahankannya secara berkelanjutan di masa depan. Beri tahu kami pendapat Anda.

@ezyang Jika Anda kekurangan tenaga, saya dapat mencoba mempertahankan bagian tensor kompleks di masa depan, saya baru saja memulai PhD saya (dan ini adalah tahun jeda saya sebenarnya), dan oleh karena itu saya tidak akan kesulitan untuk menulis tesis saya di tahun terakhir setidaknya. Tetapi saya benar-benar tidak dapat terus berkontribusi tanpa umpan balik dari tim pytorch. Saya pikir harus ada peta jalan untuk ekstensi besar ini. Dan kami dapat menambahkan dukungan kompleks dengan lancar sehingga orang-orang Anda tidak perlu meninjau PR besar dan itu akan memudahkan upaya pengembang dalam melacak cabang master.

Pertama, saya pikir masalah utama tentang dukungan kompleks adalah bagian CUDA. Sangat mudah untuk mendukung bagian CPU dengan ATen atau perpustakaan lain, saya dapat menulis ulang bagian CPU hanya dalam beberapa hari jika ada umpan balik. Ada beberapa masalah yang mungkin saya perhatikan untuk bagian CUDA, dan saya pikir ini mungkin mengarah pada dua pendekatan yang berbeda:

1. Gunakan float2 , dll. untuk mensimulasikan satu nilai kompleks seperti yang dilakukan cuComplex di bagian CUDA.
2. Gunakan FloatTensor dan DoubleTensor yang ada untuk mensimulasikan tensor kompleks di bagian C++ ATen.

Alasan untuk pendekatan kedua adalah karena dalam THC , pytorch menggunakan beberapa trik untuk mempercepat operasi peta/mengurangi dan tidak cocok untuk cuComplex secara sepele karena cuComplex sebenarnya float2 , tetapi fungsi __shfl_xxx tidak secara asli mendukung float2 . Saya tidak yakin bagaimana mensimulasikan fungsi seperti itu secara efisien untuk float2 saat ini.

Pendekatan kedua akan lebih mudah karena kita sekarang tidak perlu peduli dengan perangkat keras, dan kita dapat membuat ekstensi kompleks baru kita bekerja pada perangkat lama dengan lebih mudah. Namun, ini mungkin menyebabkan beberapa overhead karena alamat memori yang berdekatan.

Selain itu, saya menemukan bahwa untuk mengintegrasikan bilangan kompleks ke dalam ATen, kita mungkin harus menangani empat tipe berbeda yang sebenarnya sama pada perangkat keras: std::complex , thrust::complex , cuComplex , float2 yang terkadang berbahaya. (Faktanya, saya menemui masalah ini tahun lalu, dan reinterpreter_cast adalah solusinya).

Saya pribadi lebih suka menulis semuanya lebih asli.

Dan saya pikir kita mungkin memerlukan kerangka waktu atau peta jalan, dan kita dapat mengambil setiap bagian kecil dan bekerja sama sehingga saya tidak perlu melacak master sendiri yang sama sekali tidak mungkin...

ada ChangeLog ketika saya mencoba mengimplementasikan backend CPU, saya mengklasifikasikan fungsi yang perlu dimodifikasi untuk bilangan kompleks di log. Kita bisa menulis peta jalan berdasarkan log ini.

Selain itu, karena visa saya baru saja ditolak (oleh Australia), saya harus memulai tahun jeda, jika Anda membutuhkan seseorang untuk terus mengerjakan ini, saya dapat mengajukan permohonan magang.

Saya banyak berpikir tentang ini selama hari terakhir. Agak menyedihkan bahwa kami tidak dapat menggabungkan upaya Roger apa adanya, tetapi saya berpikir sendiri

"bagaimana kita bisa membangun dukungan Tensor yang kompleks, sambil menjaga biaya perawatan tetap rendah?"

Inilah yang saya susun sebagai rencana yang efektif dari tujuan di atas:

• Tensor Kompleks tidak boleh menjadi jenis Tensor baru yang mendasar, seperti Tensor sparse . Menambahkan tipe fundamental menyebabkan banyak overhead pemeliharaan dan perubahan lintas sektoral. Overhead pemeliharaan bukan tentang "siapa yang memelihara bit kompleks?", tetapi lebih dari "sekarang semua pengembang inti harus menyadari jenis kompleks ini ketika melakukan perubahan mendasar, perubahan ATen, dll."
  
  
  
  • Sebaliknya, mereka harus selalu [Bentuk Tensor x 2] atau [2 x Bentuk Tensor], yaitu Tensor harus memiliki satu dimensi tambahan dengan ukuran 2.
  
  
• Tensor Kompleks harus berupa file/folder kecil dari ~2k baris C++ sederhana yang dibangun di atas ATen Tensor API.
  
  
  
  • Misalnya, seperti yang disarankan https://github.com/pytorch/pytorch/issues/6514 , perkalian kompleks harus diterapkan sebagai torch.stack([real1 * real2 - imag1 * imag2, real1 * imag2 + imag1 * real2], dim = -1) di mana real1 = input1[:, :, :, ..., 0]
  
  
  • Ini merusak kinerja: ya, kami tidak akan mendapatkan kinerja sebanyak jika kami menyejajarkan semuanya. Namun, pertanyaannya adalah: "berapa banyak?". Saya pikir kita harus menargetkan kinerja 20% lebih rendah sebagai ganti dukungan kompleks yang sehat dan berfitur lengkap + terpelihara.
  
  
  • Fungsi kompleks yang paling sering digunakan dapat mulai mendapatkan kernel khusus, sehingga di mana kinerja mencapai lebih dari 20% pada fungsi yang sering digunakan, kami turun tangan.
  
  

Itu harus [Bentuk Tensor x 2] karena BLAS, cublas, dan MAGMA semuanya mengharapkan tipe kompleks mereka sendiri yang kompatibel dengan byte ke float2. Juga panggilan blas, cublas dan magma tidak dapat ditangani pada level python.
Saya tidak berpikir itu akan menjadi hanya 20% untuk perkalian kompleks, bukankah Anda memiliki 4 operasi penyalinan penuh di atas perhitungan untuk bagian nyata dan gambar?
Bagaimanapun, saya masih akan senang jika saya tidak harus menggabungkan perubahan dari master terus menerus.

Setuju dengan @PhilippPelz , kami mungkin kehilangan banyak kinerja karena kami akan kehilangan dukungan kompleks dari BLAS, cublas, dan MAGMA. Tapi aku tidak yakin tentang itu. Namun, untuk lebih jelasnya, Tensor kompleks adalah sesuatu yang sama sekali berbeda dari sparse tensor , sebagian besar perpustakaan seperti scipy.sparse , dan Julia's SparseArrays memperlakukan sparse array sebagai komposisi array multi-dimensi yang mendasar. Tapi tidak ada yang memperlakukan array multi-dimensi dengan tipe kompleks dengan menggabungkan dua array nyata ... (tidak ada seorang pun di sini yang saya maksud tensorflow, arrayfire, numpy dan Julia). Meskipun di MXNet, FFT dicapai dengan komposisi dua tensor nyata, mereka tidak mendukung kompleks... Tampaknya tensorflow mengimplementasikan DataType sebagai pembungkus di sekitar tipe berbeda termasuk complex64 dan complex128 lihat types.proto

Tentang kehilangan kinerja

Pertama, fungsi elemen-bijaksana (fungsi memanggil peta/mengurangi) tidak akan kehilangan kinerja yang besar (setidaknya, memori untuk operasi ini akan berdekatan). Tapi saya rasa kita harus mencoba membandingkan beberapa fungsi BLAS terlebih dahulu, untuk melihat apakah komposisi FloatTensor memiliki performa yang sama dengan Complex64Tensor pada GPU, dan seberapa besar kita akan kehilangan performa dengan a rancangan implementasi, seperti:

• gemm
• gemv

Tensor kompleks gabungan akan terlihat seperti (atau cukup gunakan shared_ptr ):

class ComplexTensor {
    FloatTensor *real;
    FloatTensor *imag;
};

Namun, seperti yang saya sebutkan di kelemahan pendekatan pertama, fungsi seperti __shfl_xxx juga terlihat seperti kendala jika kita ingin melakukan ini lebih asli.

saat ini torch.fft mengembalikan satu float tensor berbentuk [dim1, ..., dimN, 2]

@ezyang apa kerangka waktu untuk rilis C10? Kedengarannya seperti poin yang sangat masuk akal untuk mulai mendukung kompleks di cabang master.

@PhilippPelz Jelas bukan untuk 0,4. Kami targetkan secara internal Juni, semoga tidak terlalu lama menunggu.

@ezyang Anda menyebutkan Juni, apakah Anda berhasil menambahkan dukungan untuk bilangan kompleks ke PyTorch?

Saya pikir maksudnya C10, bukan dukungan yang kompleks. C10 akan membuat penambahan kompleks menjadi lebih mudah. Begitulah cara saya memahaminya.

Ya, C10 akan membuka pendaftaran jenis dan fungsi Tensor. Jadi menambahkan tipe kompleks sebagai paket terpisah akan jauh lebih mudah.

Apakah ada ETA pada bilangan kompleks? Apakah "jauh lebih mudah" berarti "mungkin akan selesai dengan cepat"?

@themightyoarfish dengan lebih mudah, maksud saya bahwa kita tidak akan diblokir pada apa yang dapat didorong ke pytorch master. Kami belum menetapkan ETA. Saya akan membahas pekerjaan itu setelah kami membuka pendaftaran ke PyTorch.

@soumith apakah Anda masih membutuhkan orang untuk mengerjakan ini (nomor kompleks)? Tim PyTorch akan mendukung bilangan kompleks? Saya dapat meluangkan waktu untuk mengerjakan ini jika Anda mau pada bulan September, karena saya akan mempertahankan QuCumber (ini akan sangat menggunakan bilangan kompleks)

@Roger-luo ya. Saya ingin menghubungi Anda setelah pendaftaran terbuka tersedia di backend PyTorch, dan kami dapat menyelesaikan detailnya.
@ezyang apakah kami akan membuka pendaftaran tipe terbuka pada bulan September?

@soumith Keren, siap melayani Anda.

Kita bisa mewujudkannya. (Kami tidak akan memiliki sistem baru "penuh", tetapi selama kami mengatur semuanya agar dapat direfaktor, kami dapat terus memindahkannya seiring perkembangan baru terjadi. Ini akan menjadi kasus uji yang baik untuk open baru pendaftaran. Saya dapat memastikan ini terjadi.)

@ezyang ada catatan sekarang? Saya bisa membacanya sebelum mengerjakannya. Tampaknya banyak hal berubah sejak terakhir kali.

@Roger-luo @PhilippPelz Saya juga ingin membantu Anda dengan penerapan tensor kompleks. Saya juga membutuhkannya untuk investigasi PhD saya..

@alexgomezalanis mungkin kita bisa memiliki saluran untuk berdiskusi di waktu luang, saya baru saja membuat panggilan saluran #complex-numbers . Tetapi saya tidak akan mulai mengerjakannya sampai September (masih perlu mengerjakan beberapa kode Julia saya ...)

BTW, sepertinya banyak berubah sejak terakhir kali. Saya akan menggunakan beberapa waktu untuk mengejar ketinggalan sebelum saya mendapatkannya.

@alexgomezalanis saya tidak bisa. anda harus bergabung dengan ruang kerja pytorch di slack terlebih dahulu. Saya tidak dapat menemukan Anda. Silakan kirim email ke alamat: [email protected] untuk mendapatkan undangan.

@Roger-luo @alexgomezalanis Senang melihat kehidupan lagi pada masalah tensor yang kompleks. Saya dapat menawarkan untuk terlibat juga, tetapi secara realistis ini tidak akan terjadi sampai akhir September / awal Oktober. Adapun beberapa komentator tentang masalah ini, dukungan tensor yang kompleks akan sangat membantu untuk proyek PhD saya.

Saya juga mencoba menyimpan penelitian saya tahun lalu … tetapi sekarang saya hanya ingin menghidupkan kembali kode lokasi 1w+ lama saya. ayo ngobrol di slack!

:) Ya, mari kita mengobrol di slack. Baru saja menemukan undangan di folder surat.

Plugin pekerjaan dalam proses (hanya untuk CPU dalam jangka pendek) ada di sini: https://github.com/Roger-luo/pytorch-complex

Tolong beri saya masalah dan PR.

Saya telah memposting catatan tentang bagaimana implementasi kompleks akan dilakukan di bagian atas masalah ini.

Saya baru-baru ini mulai menggunakan PyTorch dan saya sangat menyukainya -- ini jauh lebih baik digunakan daripada TensorFlow. Namun, dukungan tensor kompleks cukup penting untuk penelitian saya (jaringan saraf optik). Apakah ini masih aktif dikerjakan? Jika demikian, adakah yang tahu kerangka waktu (longgar) untuk dukungan tensor kompleks?

Saya akan dengan senang hati membantu mengerjakan ini di mana saya bisa, tetapi saya relatif baru di PyTorch, jadi saya belum memiliki gagasan yang bagus tentang seberapa besar upaya yang dilakukan fitur ini. Beberapa rekan lab saya juga telah menyatakan minatnya pada dukungan tensor kompleks (dalam fisika, menambahkan ini dapat membuat Torch hampir menjadi pengganti yang dipercepat GPU untuk NumPy) dan mungkin bersedia membantu juga jika itu berarti mendapatkan dukungan kompleks di tidak lama lagi.

Hai @bencbartlett

Saya masih berusaha untuk mengerjakannya secara perlahan.... tapi saya saat ini juga masih mahasiswa (dengan situasi yang cukup labil), yang artinya saya tidak bisa mengerjakan ini secara full time tetapi hanya di waktu senggang. (Saya menerapkan kode terkait penelitian saya di Julia dari tahun lalu, yang berarti hanya paket warisan kami yang membutuhkan dukungan nomor kompleks yang lebih baik dari obor.).

Jika bilangan kompleks sangat penting bagi Anda dan sangat penting untuk dimiliki, saya sarankan coba ini:

https://github.com/PIQuIL/QuCumber/blob/master/qucumber/utils/cplx.py

Ini sangat lambat... tapi setidaknya berhasil. Atau saya punya versi C dalam gaya TH lama.

Ini bukan proyek kecil yang bisa diselesaikan dalam beberapa hari. Oleh karena itu saya tidak dapat menjamin kerangka waktu tertentu untuk dukungan fungsional penuh dengan nilai kompleks pada CPU atau CUDA.

Saya akan senang membantu Anda bekerja sama dengan saya dalam hal ini. Saya akan menyarankan Anda untuk memulai dengan mencoba menyelesaikan masalah yang saya posting di repo ekstensi. Dan jangan ragu untuk bertanya kepada saya melalui slack atau email atau masalah jika Anda memiliki pertanyaan (karena belum banyak dokumen).

Sayangnya, saya belum memiliki akses ke PyTorch Slack. (Saya mengirim email dua kali untuk meminta undangan, tetapi belum mendapat balasan.) Bisakah seseorang mengundang saya? ([email protected])

@ Roger-luo Saya pasti akan memeriksa garpu Anda, tapi saya tidak bisa menjanjikan saya akan banyak membantu -- C++ saya berkarat dan seperti yang Anda tunjukkan, sulit menemukan waktu untuk mengerjakan ini sebagai murid. Utilitas QuCumber bagus, tetapi sayangnya mereka tidak akan terlalu membantu bagi saya: sampai tensor kompleks didukung GPU atau didukung oleh autograd dan torch.nn, mereka tidak menyediakan banyak utilitas di atas apa yang dapat ditawarkan NumPy.

@soumith @ezyang Akan sangat bagus untuk mendapatkan lebih banyak perhatian dari tim PyTorch! Dukungan kompleks sepertinya merupakan fitur penting yang harus dimiliki perpustakaan tensor umum, ini hampir esensial dalam fisika, dan khususnya dalam ML selama beberapa tahun terakhir, ada minat yang berkembang pesat pada model bernilai kompleks.

Pendekatan @bencbartlett QuCumber dapat digunakan pada GPU dengan AD... itu sangat lambat... Maksud saya jika Anda hanya menginginkan AD itu, Anda mungkin dapat menggunakannya.

Ya, terus terang, saya menggunakan versi https://github.com/FluxML/Flux.jl yang sedikit dimodifikasi dan beberapa paket saya sendiri di Julia untuk penelitian (saya perlu AD kompleks pada GPU dengan tensor dalam beberapa situasi juga ). Paket AD source2source Zygote.jl dapat melakukan AD pada tensor kompleks, tetapi pada tahap sangat awal yang mungkin memiliki kesalahan segmen. Ekosistemnya belum begitu stabil dibandingkan dengan obor, terkadang saya harus meretas implementasi tersebut sedikit untuk penggunaan sendiri... Tapi pada dasarnya ini berfungsi untuk apa yang saya perlukan untuk penelitian dalam fisika kuantum. Saya dapat memiliki tensor kompleks pada GPU juga.

Saya tidak berpikir dukungan nilai kompleks untuk torch.nn diperlukan, kita mungkin hanya perlu menambahkan beberapa definisi untuk autograd setelah tensor kompleks berfungsi, karena hal-hal seperti lapisan linier dapat tetap sama . Dan beberapa fungsi aktivasi mungkin tidak memiliki ekspansi standar di ruang Hilbert... (Anda dapat memeriksa posting blog kolaborator saya @GiggleLiu )

Untuk ekstensi pytorch-complex, saya tidak yakin kapan kami bisa mendapatkan dukungan penuh dengan AD di GPU... ini masih tampak cukup jauh bagi saya. Saya akan mengatakan implementasi CPU akan melalui beberapa periode yang memerlukan tambalan di pohon utama (mis. Jenis promosi, dukungan simd, dll.), Ini mungkin juga terkait dengan implementasi ATen yang akan datang di C++ dan singkirkan TH, dll., dan kemudian kita akan dapat menambahkan operator untuk tensor kompleks dengan lebih cepat.

Saya dapat melamar magang di Musim Semi (yang baru saja saya tanyakan kepada @ezyang ). Jadi saya mungkin bisa mengerjakan ini penuh waktu selama beberapa bulan sebelum saya memulai PhD saya. Ayo lihat.

Sementara itu, saya menerapkan versi saya sendiri dari perkalian kompleks. Namun, ketika saya membuat profil, ternyata banyak waktu yang dihabiskan untuk: torch._C_._cuda_isDriverSufficient

Apakah Anda tahu mengapa? Jika Anda mengetahui implementasi perkalian kompleks yang lebih baik, beri tahu saya. Entah bagaimana, versi saya (meskipun dioptimalkan untuk jumlah perkalian: 3 bukannya 4) tampaknya relatif lambat, misalnya irfft dari tensor keluar 10X lebih cepat daripada perkalian elemen-bijaksana saya. Apakah perkalian kompleks didukung pada level C++ dari PyTorch?

def complex_mul(x, y, out):
    uavc = x[..., 0] * (y[..., 0] + y[..., 1])
    out[..., 0] = uavc - (x[..., 0] + x[..., 1]) * y[..., 1]
    out[..., 1] = (x[..., 1] - x[..., 0]) * y[..., 0] + uavc

def test_complex_mul_out_tensor(self):
        N, C, H, W, I = 128, 3, 32, 32, 2
        K = 16  # number of filter banks
        repetitions = 1000
        dtype = torch.float
        if torch.cuda.is_available():
            device = torch.device("cuda")
        else:
            device = torch.device("cpu")
        x = torch.randn(N, 1, C, H, W, I, dtype=dtype, device=device)
        y = torch.randn(K, C, H, W, I, dtype=dtype, device=device)
        start_mul_time = time.time()
        out = torch.empty(N, K, C, H, W, I, dtype=dtype, device=device)
        for _ in range(repetitions):
            complex_mul(x, y, out)
        print("multiplication time: ", time.time() - start_mul_time)

Kami mencoba untuk mendukungnya dari C++. lihat postingan di atas. Jika Anda dapat mengkompilasi ekstensi, itu harus berfungsi untuk perkalian skalar setidaknya saat ini....

Implementasi Anda mirip dengan apa yang kami miliki di QuCumber. Ini mungkin memanggil lebih banyak utas GPU tambahan jika Anda tidak memanggil kernel cuda yang benar untuk nomor kompleks. Dan Anda mungkin kehilangan SIMD jika Anda tidak memiliki backend C++ sebagai dukungan di Python.

Saya sarankan Anda menjalankan nvprof untuk mendapatkan detail lebih lanjut.

@Roger-luo @apaszke @soumith Terima kasih untuk utas ini btw. Saya menerapkan tensor kompleks dasar yang diretas bersama dari subclassing torch.Tensor.

Saya memperlakukan babak pertama sebagai nyata, kedua sebagai imajiner dan menerapkan operasi aritmatika dasar saya sendiri dan beberapa lainnya yang saya perlukan untuk penelitian saya.

Saya memverifikasi terhadap Tensorflow dan numpy. Gradien dan semua operasi yang saya terapkan cocok dengan outputnya!

Itu hanya dimaksudkan sebagai peninggalan sampai PT sepenuhnya mendukung tensor kompleks.

Fitur:

1. Tes dilaksanakan.
2. Pypi didukung (yaitu: pip install)

pip install pytorch-complex-tensor

https://github.com/williamFalcon/pytorch-complex-tensor

Terima kasih @williamFalcon !

Ada yang update ini? Hanya ingin tahu apakah akan ada rencana untuk mengintegrasikan dukungan tipe kompleks ke dalam pytorch.

Hai, @whmrtm

@ezyang sedang mengerjakan https://github.com/Roger-luo/pytorch-complex/issues/4 Atau siapa pun yang tertarik dengan ini dapat membantu kami menjalankannya. Masalah ini akan menyelesaikan beberapa masalah siaran dasar (maka Anda dapat menggunakan banyak fungsi setelah yang ini diselesaikan). Silakan melakukan PR apa pun atau minta saya menambahkan Anda sebagai kolaborator.

Saya tidak akan dapat mengerjakan apa pun sampai musim panas, harus menyelesaikan rilis baru untuk paket kami sendiri.

Hai, @whmrtm

@ezyang sedang mengerjakan Roger-luo/pytorch-complex#4 Atau siapa pun yang tertarik dengan ini dapat membantu kami menjalankannya. Masalah ini akan menyelesaikan beberapa masalah siaran dasar (maka Anda dapat menggunakan banyak fungsi setelah yang ini diselesaikan). Silakan melakukan PR apa pun atau minta saya menambahkan Anda sebagai kolaborator.

Saya tidak akan dapat mengerjakan apa pun sampai musim panas, harus menyelesaikan rilis baru untuk paket kami sendiri.

Terima kasih atas pembaruannya, saya akan melihat apa yang bisa saya lakukan.

Hai @Roger-luo

Bisakah saya mengakses saluran slack yang terkait dengan topik dukungan tensor kompleks ([email protected])? Saya mengirim email untuk undangan tetapi belum ada yang terjadi. Saat ini saya mencoba untuk mencari tahu poin di mana untuk mulai berkontribusi untuk masalah ini. Saya kira https://github.com/Roger-luo/pytorch-complex/issues/4 adalah titik masuk saat ini sekarang?

@beconstant ya, itulah titik awalnya, ini seharusnya membuat beberapa fungsi siaran berfungsi, tapi saya tidak tahu mengapa itu melempar kesalahan jenis promosi pada cuda, itu bekerja pada CPU. (Meskipun kami tidak bermaksud untuk mendukung cuda sejak awal, ini akan menyebabkan kegagalan build)

Saya tidak dapat mengirimi Anda email undangan (saya tidak memiliki akses). Saya pikir Anda harus mengikuti panduan resmi pytorch untuk bergabung dengan slack. Tapi kita selalu bisa berdiskusi dalam masalah/PR.

@Roger-luo ok, mengerti :)

Beri tahu saya jika kalian membutuhkan bantuan. Saya akan mulai dengan membangun versi pytorch yang ditentukan. Adakah kemajuan pada pytorch-complex/issues/4 ?

Beri tahu saya jika kalian membutuhkan bantuan. Saya akan mulai dengan membangun versi pytorch yang ditentukan. Adakah kemajuan pada pytorch-complex/issues/4 ?

@dylanbespalko Hai, saya sangat membutuhkan pytorch diimplementasikan dalam versi bernilai Kompleks.
Terima kasih banyak atas kontribusi Anda.

Salam Hormat,
Zellar209

Hai @Zellar209 ,

Saya merasa @ezyang sedang bekerja keras pada salah satu masalah yang lebih besar ( pytorch-complex/issues/4 ). Saya memiliki sistem AMD sekarang dan sistem Nvidia dalam 3 minggu yang dapat saya gunakan untuk meningkatkan dukungan GPU.

Saya kira masalahnya hanya tentang perubahan promosi tipe asli yang merusak CUDA, selama PR itu diselesaikan setidaknya ada beberapa operator yang bekerja pada CPU, kami belum memiliki dukungan CUDA sama sekali ...

IMHO Saya pikir kita harus fokus pada CPU dan membuat semuanya berfungsi terlebih dahulu, kemudian pertimbangkan GPU nanti.

Dukungan hanya CPU baik-baik saja. Apakah masalah promosi jenis ini ( pytorch-complex/issues/4 sedang ditangani secara internal oleh fb? Bolehkah mengerjakannya secara eksternal?

Hai @dylanbespalko; Saya memang memberi tahu @ Roger-luo bahwa saya akan memeriksanya (karena saya mungkin berada di tempat terbaik untuk mencari tahu apa masalahnya), tetapi saya belum punya waktu untuk melihatnya. Jika Anda ingin mencari tahu cara memperbaiki masalah, saya akan dengan senang hati menyarankannya.

Hai @Zellar209 ,

Saya merasa @ezyang sedang bekerja keras pada salah satu masalah yang lebih besar ( pytorch-complex/issues/4 ). Saya memiliki sistem AMD sekarang dan sistem Nvidia dalam 3 minggu yang dapat saya gunakan untuk meningkatkan dukungan GPU.

Ya, saya tidak membutuhkan GPU sekarang, saya menggunakan sistem MAC. Tetapi saya memiliki beberapa kesalahan saat membangun proyek ini.

Hai @ Zellar209 , bisakah Anda memposting apa yang Anda dapatkan dalam masalah pytorch-complex? Saya pikir ada yang salah dengan Xcode baru Mac, yang membuatnya sulit untuk dibuat. Tetapi orang-orang akan membutuhkan lebih banyak pesan kesalahan untuk mencari tahu alasannya.

Saya bertanya tentang OS dan pesan kesalahan, tetapi Anda tidak menjawab ...

Hai @dylanbespalko; Saya memang memberi tahu @ Roger-luo bahwa saya akan memeriksanya (karena saya mungkin berada di tempat terbaik untuk mencari tahu apa masalahnya), tetapi saya belum punya waktu untuk melihatnya. Jika Anda ingin mencari tahu cara memperbaiki masalah, saya akan dengan senang hati menyarankannya.

Terima kasih atas balasan awal Anda.

1. Ketika saya menjalankan "python setup.py install" menggunakan gcc (default), saya mendapatkan kesalahan seperti ini:

membangun ekstensi 'torch_complex.cpp'
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/anaconda3/include -arch x86_64 -I/anaconda3/include -arch x86_64 -I/ anaconda3/lib/python3.6/site-packages/torch/include -I/anaconda3/lib/python3.6/site-packages/torch/include/torch/csrc/api/include -I/anaconda3/lib/python3. 6/site-packages/torch/include/TH -I/anaconda3/lib/python3.6/site-packages/torch/include/THC -I/anaconda3/include/python3.6m -c src/module.cpp -o build/temp.macosx-10.7-x86_64-3.6/src/module.o -g -stdlib=libc++ -std=c++11 -DTORCH_API_INCLUDE_EXTENSION_H -DTORCH_EXTENSION_NAME=cpp
gcc: kesalahan: opsi baris perintah tidak dikenal '-stdlib=libc++'

kesalahan: perintah 'gcc' gagal dengan status keluar 1

2. Saat saya menggunakan dentang untuk mengompilasinya, kesalahannya adalah:

Dalam file yang disertakan dari src/module. cpp:2 :
Dalam file yang disertakan dari src/CPUComplexType.h:60:
src/CPUComplexTypeImpl.h:102:105: peringatan: 'IntList' tidak digunakan lagi [-Wdeprecated-declarations]
Tensor & CPUComplexType::set_(Tensor & self, Sumber penyimpanan, int64_t storage_offset, ukuran IntList, langkah IntList) const {
^
/anaconda3/lib/python3.6/site-packages/torch/include/c10/util/ArrayRef.h:273:7: catatan: 'IntList' telah secara eksplisit ditandai tidak digunakan lagi di sini
menggunakan IntList C10_DEPRECATED_USING = ArrayRef;
^
Dalam file yang disertakan dari src/module. cpp:2 :
Dalam file yang disertakan dari src/CPUComplexType.h:60:
src/CPUComplexTypeImpl.h:105:76: kesalahan: tidak ada anggota bernama 'scalarTypeToDataType' di namespace 'at'
auto source_ =checked_storage(source,"source",2, DeviceType::CPU, at::scalarTypeToDataType(CPUComplexTypeInfo::scalar_type));
~~~~^
7 peringatan dan 2 kesalahan dihasilkan.

kesalahan: perintah 'dentang' gagal dengan status keluar 1

Saya tidak bisa memperbaikinya. Saya sangat berharap Anda dapat membantu saya!

Hai teman-teman,

Terima kasih atas tanggapan Anda. Saya pikir saya bisa menghabiskan seminggu untuk melihat ini. Sejauh ini saya telah mengkompilasi pytorch-complex @ Roger-luo sebagai berikut:

@Zellar209 : Saya telah melampirkan variabel lingkungan saya yang berjalan di macOS 10.13.

1. Hapus distribusi pytorch yang ada sebagai berikut
   conda uninstall pytorch
   pip uninstall obor
   pip uninstall torch # jalankan perintah ini dua kali
   python setup.py bersih
   Hapus folder obor di folder paket situs python jika ada.
   Ganti nama (atau hapus) folder sumber pytorch sebelumnya (ada yang merujuk padanya).

2. Instal revisi PyTorch 6cb593b88cb0c411690b4957850058329526d87b.

    git clone [email protected]:pytorch/pytorch.git
    git checkout 6cb593b88cb0c411690b4957850058329526d87b
    git submodule update --init —recursive
    export CMAKE_PREFIX_PATH=${CONDA_PREFIX:-"$(dirname $(which conda))/../“}
    MACOSX_DEPLOYMENT_TARGET=10.13 CC=clang CXX=clang++ python setup.py develop
    python

>>> import torch

1. Instal pytorch-kompleks

    python setup.py install
    python setup.py build
    python setup.py test
    # ERROR: test (unittest.loader._FailedTest)
    # ERROR: test_scalar_binary_op (tests.test_tensor.TestComplexTensor)

1. Buat tensor kompleks

   from torch_complex import torch
   a = torch.ones(3, dtype=torch.complex128)
   a*a  
   RuntimeError: promoteTypes with complex numbers is not handled yet; figure out what the correct rules should be

@ezyang , @Roger-luo:

Segala sesuatu untuk promosi tipe untuk operasi tensor tampaknya dilakukan di c10/core/ScalarType.h
Saya telah menemukan kesalahan AT_ERROR("promoteTypes with complex numbers is not handled yet; figure out what the correct rules should be”);
Sepertinya saya harus menambahkan entri untuk c8 dan c16 di dalam tabel ini.
Apakah ini ada hubungannya dengan 9515 ? Saya pikir ini hanya untuk memanggil fungsi numpy.
Apakah itu tempat yang baik untuk memulai?

9515 tidak berhubungan. Namun, memperbaiki jalur kode ini di ScalarType.h adalah tempat yang baik untuk memulai.

Saya memperbaiki jalur kode di ScalarType.h
BinaryOps (tambah, sub, mul, div) berfungsi, tetapi hanya jika kedua argumen adalah Tensor.
Beberapa masalah aneh lainnya, tetapi saya perlu melihatnya lagi.

@dylanbespalko Saya telah menambahkan jenis promosi di sini: https://github.com/pytorch/pytorch/pull/11641

Anda bisa menyalinnya, tetapi masalahnya adalah ini entah bagaimana merusak CUDA.

IIRC, ada bug kawat karena versi gcc. Saya punya beberapa solusi di sana.

Ah, terima kasih @Roger-luo. Saya melihat komentar #11641 . Saya akan melakukan pekerjaan yang lebih baik untuk menyalin kode besok.

Bagaimana saya tahu ketika saya telah merusak CUDA ketika saya tidak memiliki perangkat CUDA? Saya berasumsi CI akan memberi tahu saya?

Ya, selama Anda mengirimkan PR, itu akan memberi tahu Anda mana yang rusak. Dan jika semuanya berlalu begitu saja, maka kita bisa menggabungkannya dan membuat semuanya bekerja.

Oke, kalau begitu saya akan mulai mengirimkan PR agar saya tahu kapan itu terjadi.

@dylanbespalko Hai, sepertinya masih ada beberapa kesalahan di lingkungan Anda?
Jika Anda memperbaikinya, silakan bagikan dengan kami. Terima kasih banyak.

Hai teman-teman,

Saya mencoba melakukan beberapa PR setelah menyalin beberapa komit @ Roger-luo. Sayangnya, saya tidak memiliki GPU CUDA sekarang dan mesin CI dengan CUDA tidak melakukan inisialisasi. Saya tidak dapat membuat ulang kegagalan pengujian CUDA sekarang, jadi saya akan kembali ke sini dalam beberapa minggu ketika saya dapat menjalankan GPU itu secara lokal. Terlihat menjanjikan, setidaknya.

@ezyang , @Roger-luo

Saya telah melihat PR Roger #11641 :

• Itu dibangun dan berjalan di mesin CUDA 9.0 saya
• Gagal membangun mesin CI yang menjalankan CUDA 9.0

Saya juga telah melihat beberapa perkembangan PyTorch baru-baru ini:

• Presentasi dari @ezyang menjelaskan cara menulis ekstensi C++/CUDA yang dapat menentukan perangkat/tata letak/dtype khusus.
  
  
  
  • PR #21964 yang lebih baru yang "menghapus ComplexHooksInterface", tetapi mendefinisikan ekstensi C++ bilangan kompleks yang terletak di pytorch/test/cpp_extensions/complex_registration_extension.cpp
  
  

Tampak bagi saya bahwa kemampuan ekstensi "out-of-tree" baru sedang dikembangkan, yang akan memungkinkan saya untuk menyelidiki dukungan bilangan kompleks tanpa merusak pytorch lainnya. Tujuan saya adalah untuk:

1. Tentukan dukungan CPU Kompleks tanpa AVX.
2. Tentukan dukungan CUDA Kompleks menggunakan Thrust.

@ezyang
Bisakah Anda memberikan garis waktu yang diharapkan untuk ekstensi perangkat/tata letak/dtype out-of-tree yang Anda presentasikan ini? Bisakah kita mengharapkan fitur ini dalam 3 bulan ke depan?

@ezyang

Apakah Anda dapat menggabungkan dukungan bilangan kompleks pada CPU tanpa dukungan AVX/SSE? Saya berencana untuk mengirimkan yang berikut ini dalam permintaan gabungan terpisah:

• [ ] Menambahkan dukungan kompleks dari kernel CPU BinaryOp
• [ ] Menambahkan dukungan kompleks dari CPU TensorFactories
• [ ] Menambahkan dukungan kompleks untuk CPU FillKernels
• [ ] Menambahkan dukungan kompleks kernel Rentang CPU
• [ ] Menambahkan dukungan kompleks dari kernel CPU Unary
• [ ] Menambahkan dukungan kompleks CPU Bandingkan kernel
• [ ] Menambahkan dukungan kompleks dari kernel CPU TensorCompare
• [ ] Menambahkan dukungan kompleks kernel ReduceOp CPU
• [ ] Menambahkan dukungan kompleks dari kernel CPU PointwiseOps
• [ ] Menambahkan dukungan kompleks dari kernel learpOps CPU
• [ ] Menambahkan dukungan kompleks dari kernel CPU LinearAlgebraOps
• [ ] Menambahkan dukungan kompleks dari kernel CPU SpectralOps

Saya berencana untuk mengujinya di seluruh intel/arm cpus dalam beberapa hari ke depan.

@ezyang ,

Saya sedang mencari operasi seperti fft() dan var() di mana implementasi bilangan kompleks harus mengubah data tensor menjadi bentuk tensor ganda: (complex_shape, 2) . Ini tidak berfungsi dengan metode tensor yang ada:

1. 'tensor.to(torch.float64): hanya menyimpan bagian asli, dan mengembalikan tensor dengan bentuk yang sama.
2. 'tensor.view(new_shape): bentuk baru harus memiliki jumlah elemen yang sama.

Jelas saya dapat melakukan sesuatu yang tidak efisien seperti:

def to_float(tensor):
    return th.stack((tensor.real().type(th.float64), tensor.imag().type(th.float64)), -1)

def to_complex(tensor):
    tensor = tensor.type(th.complex128) 
    return tensor[..., 0] + 1j*tensor[..., 1]

Jelas itu membuat salinan, ketika yang saya butuhkan hanyalah static_cast<double> dan mengubah bentuk tensor menjadi (old_shape, 2) . Apakah Anda punya saran tentang cara melakukan ini?

Juga, Ada peretasan di numpy yang memungkinkan Anda melakukan ini:

a = np.array([1 + 1j], dtype=np.complex128)
a.dtype = np.float64  ## This works

a = torch.tensor([1 + 1j], dtype=torch.complex128)
a.dtype = torch.float64  ## This does not work

Kemampuan untuk mengatur dtype benar-benar berfungsi dalam situasi ini, namun bisa jadi tidak dapat diprediksi.

Beberapa informasi tambahan tentang menafsirkan bilangan kompleks sebagai larik bilangan real dengan panjang-2. Berikut ini berlaku di C++11.

Untuk sembarang penunjuk ke elemen larik bilangan kompleks p dan indeks larik apa pun yang valid i, reinterpret_cast(p)[2 i] adalah bagian real dari bilangan kompleks p[i], dan reinterpret_cast(p)[2 i + 1] adalah bagian imajiner dari bilangan kompleks p[i]. (Sejak C++11)

Saya pikir ini berarti adalah mungkin untuk mengubah complex_tensor menjadi real_tensor dengan bentuk (complex_shape, 2) dan kemudian melakukan operasi tanpa memanggil real() dan imag() yang mengalokasikan memori baru.

@dylanbespalko Saya takut ketika Anda bertanya tentang ini :) Jaminan std::complex berarti bahwa jika Anda memiliki penunjuk data std::complex<float>* , Anda dapat dengan aman memasukkannya ke float* (bergumam aliasing ketat) dan kemudian meneruskannya ke hal fft apa pun yang Anda gunakan. Jika Anda hanya perlu menerapkan fft/var di mana Anda dapat meneruskan perwakilan tingkat rendah ini, itu akan menjadi yang paling mudah.

Namun, jika Anda perlu benar-benar melihat kembali tensor kompleks sebagai tensor float, kami berada dalam sedikit masalah, karena tidak ada preseden untuk ini di PyTorch hari ini. Penyimpanan dtype selalu setuju dengan Tensor dtype. Jadi jika Anda membuat penyimpanan yang kompleks tidak ada cara untuk meninjaunya sebagai penyimpanan pelampung.

Satu pemikiran yang saya miliki adalah mungkin kita harus mengendurkan invarian ini. Idenya adalah:

1. Kami selalu mengalokasikan penyimpanan sebagai tipe "tidak divektorkan" yang dimaksud. Jadi untuk komplekskami mengalokasikan tensor float.
2. Tipe d tensor diperbolehkan untuk tidak setuju dengan tipe d penyimpanan, tetapi hanya sebagai varian vektor dari tipe yang mendasarinya

Saya tidak yakin berapa banyak kode yang harus kita ubah untuk membuat invarian ini terjadi.

@ezyang ,

Ya ini tidak bisa dihindari ...

Jika Anda hanya perlu menerapkan fft/var di mana Anda dapat meneruskan perwakilan tingkat rendah ini, itu akan menjadi yang paling mudah.

Ya ini mungkin dalam banyak kasus. Apakah Anda dapat memberikan cuplikan kode tentang cara menginterpretasikan data tensor sebagai std::vector?

Namun, jika Anda perlu benar-benar melihat kembali tensor kompleks sebagai tensor float,....

Saya membayangkan jarang melihat tensor menggunakan dtype lain. Saya menerapkan metode set_dtype() untuk Tensor , tetapi saya mendapatkan beberapa kesalahan. Saya juga tidak memperbarui langkah untuk mencerminkan perubahan bentuk. Saya tidak yakin mengapa pengaturan dtype berfungsi di numpy (apakah ini kebetulan?), Namun ketika Anda mengunggah data ke konverter digital-ke-analog (DAC) sering kali mengharapkan data nyata/imajiner untuk disisipkan. Mungkin itu akan memotivasi kebutuhan untuk memisahkan tensor dtype dari penyimpanan dtype seperti yang Anda sarankan.

Saya akan menghindari melakukan ini untuk saat ini. Saya yakin ada hambatan kinerja lain bagi saya.

Ya ini mungkin dalam banyak kasus. Apakah Anda dapat memberikan cuplikan kode tentang cara menginterpretasikan data tensor sebagai std::vector?

Bukan std::vector, tapi saya membayangkan sesuatu seperti ini:

Tensor complex_tensor;
assert(complex_tensor.is_contiguous());
std::complex<float>* cp = complex_tensor.data_ptr<std::complex<float>>();
float* fp = reinterpret_cast<float*>(cp);
auto num_floats = complex_tensor.numel() * 2;

Saya menerapkan metode set_dtype() untuk Tensor, tetapi saya mendapatkan beberapa kesalahan. Saya juga tidak memperbarui langkah untuk mencerminkan perubahan bentuk.

Ya, ini mungkin ide yang buruk jika Anda tidak juga memperbaiki langkahnya. Saya juga bukan penggemar tensor yang mentransmutasikan ke tipe lain; lebih baik lakukan semuanya di luar tempat :)

namun ketika Anda mengunggah data ke konverter digital-ke-analog (DAC) sering kali mengharapkan data nyata/imajiner untuk disisipkan. Mungkin itu akan memotivasi kebutuhan untuk memisahkan tensor dtype dari penyimpanan dtype seperti yang Anda sarankan.

Ya, pada akhirnya ini adalah hal yang benar untuk dilakukan, tetapi saya setuju bahwa lebih mudah untuk tidak melakukannya sekarang.

@ezyang ,

Saya mulai dipusingkan dengan dukungan CUDA nomor kompleks.

Ada dua opsi biner yang kompatibel:

1. cuComplex : Dukungan add, sub, mul, div, real, imag yang sangat mendasar.
2. thrust::complex : pengganti std::complex yang mendukung alokasi memori host dan perangkat.

Kontainer dorong::kompleks tampaknya menjadi cara yang harus dilakukan. Thrust::Complex API menyarankan bahwa kontainer thrust::complex<T> dapat dialokasikan pada memori host dan perangkat, sedangkan std::complex<T> hanya dapat dialokasikan pada memori host:

__host__ __device__     thrust::complex< T >::complex (const complex< T > &z)  //thrust container
__host__    thrust::complex< T >::complex (const std::complex< T > &z) //stl container.

1. Apakah ini menyarankan bahwa AT_DISPATCH_COMPLEX_TYPES harus menetapkan using scalar_t = thrust::complex<double> alih-alih using scalar_t = std::complex<double> ?

2. Bagaimana Pytorch secara otomatis memanggil CUDA yang setara dengan std::log untuk tipe data nyata? Bagaimana saya tahu ada CUDA yang setara dengan kernel matematika?

1. Saya pikir kesulitan dengan menggunakan thrust::complex<double> secara universal untuk CPU dan CUDA adalah bahwa kami tidak benar-benar membangun melawan dorongan jika Anda membuat CPU saja. Saya kira ada banyak pilihan; kita bisa menggulung tipe kompleks kita sendiri (mirip dengan bagaimana kita menggulung setengah tipe kita sendiri), atau Anda bisa menafsirkan ulang cara Anda menuju kemenangan, karena std::complex<> didefinisikan memiliki tata letak biner tertentu. Terserah Anda, tetapi hanya menafsirkan ulang casting antar jenis tampaknya lebih mudah untuk saat ini.
2. Kami memiliki kelebihan matematika di THCNumerics.cuh, apakah itu menjawab pertanyaan Anda?

@iotamudelta telah mengangkat masalah dengan kepatuhan C++11 di #29547

std::real hanya constexpr dari C++14

Jika saya mengerti dengan benar std::real() perlu constexpr sehingga hcc compiler dapat mengkompilasi instruksi untuk __device__ .

Solusi yang memungkinkan:

1. Temukan metode atau fungsi lain untuk mengonversi complex<double> ke double :
   
   
   
   • abs juga tidak berfungsi: templateT abs (konst kompleks& x) ;
   
   

1. Temukan cara untuk membungkus fungsi:

   • Sebagian besar panggilan ke std::real dilakukan di aten/src/ATen/native/cpu/zmath.h . Contoh: ganti inline w/ constexpr :

     inline VALUE_TYPE real_impl (SCALAR_TYPE z) ->
     constexpr VALUE_TYPE real_impl (SCALAR_TYPE z)

     inline std::complex<float> real_impl <std::complex<float>> (std::complex<float> z) -> constexpr std::complex<float> real_impl <std::complex<float>> (std::complex<float> z)

     inline std::complex<float> real_impl <std::complex<double>> (std::complex<float> z) -> constexpr std::complex<float> real_impl <std::complex<double>> (std::complex<float> z)

Ini tidak akan dikompilasi karena masih ada panggilan bersarang ke std::real() yang bukan constexpr .

3. Jika saya menggunakan std::complex::real() alih-alih std::real() ini tampaknya sesuai dengan C++11.

1. Saya pikir Anda mengatakan bahwa apa pun yang saya lakukan, kode ini adalah UB hingga C++ 14. Apakah ada cara lain untuk mengonversi std::complex<double> menjadi double yang akan memenuhi kebutuhan Anda?

@iotamudelta , @bddppq , @ezyang ,

Saya telah menambahkan dukungan untuk UnaryOps dan BinaryOps yang kompleks pada CUDA thrust::complex API, tetapi saya perlu mengajukan beberapa pertanyaan sebelum saya mengirimkannya.

Saya mendefinisikan fungsi templat yang memungkinkan Anda menggunakan tipe data dorong::kompleks saat menangani bilangan kompleks.
aten/src/ATen/native/cuda/zmath.cuh

#pragma once

#include <complex>
#include <thrust/complex.h>

namespace at { namespace native {
namespace {

template <typename TYPE>
struct ztype_cuda {
  using value_t = TYPE; // Complex template type
  using thrust_t = TYPE; // Equivalent thrust type
};

template <>
struct ztype_cuda<std::complex<float>> {
  using value_t = float;
  using thrust_t = thrust::complex<float>;
};

template <>
struct ztype_cuda<std::complex<double>> {
  using value_t = double;
  using thrust_t = thrust::complex<double>;
};

} // end namespace
}} //end at::native

Kemudian di aten/src/ATen/native/cuda/BinaryOpsKernel.cu
Mengganti:

void add_kernel_cuda(TensorIterator& iter, Scalar alpha_scalar) {
  AT_DISPATCH_ALL_TYPES_AND2(kHalf, kBool, iter.common_dtype(), "add_cuda/sub_cuda", [&]() {
    auto alpha = alpha_scalar.to<scalar_t>();
    gpu_kernel_with_scalars(iter, [alpha]GPU_LAMBDA(scalar_t a, scalar_t b) -> scalar_t {
      return a + alpha * b;
    });
  });
}

Dengan:

void add_kernel_cuda(TensorIterator& iter, Scalar alpha_scalar) {
  AT_DISPATCH_ALL_TYPES_AND_COMPLEX_AND2(kHalf, kBool, iter.dtype(), "add_cuda/sub_cuda", [&]() {
    using thrust_t = typename ztype_cuda<scalar_t>::thrust_t;
    auto alpha = thrust_t(alpha_scalar.to<scalar_t>());
    gpu_kernel_with_scalars(iter, [alpha]GPU_LAMBDA(thrust_t a, thrust_t b) -> thrust_t {
      return a + alpha * b;
    });
  });
}

pertanyaan

1. @ezyang : Untuk bilangan non-kompleks, scalar_t dan thrust_t adalah tipe yang sama. Mungkin saya bisa mengganti nama variabel thrust_t dengan sesuatu yang lebih ramah untuk nomor non-kompleks, seperti scalar_t_c ?
2. Pustaka dorong tampaknya banyak direferensikan dalam kode:
   a) @bddppq : Apakah ada alasan mengapa saya harus menggunakan cuComplex daripada thrust::complex ?
   b) @iotamudelta : hip-thrust telah dihilangkan di ROCm2.7. Haruskah saya menggunakan hip_complex sebagai gantinya?
   thrust::complex tampaknya mendukung lebih banyak fungsi daripada cuComplex .

Tolong beritahu saya bagaimana menurut anda.

@iotamudelta

Saya telah memperbarui diskusi tentang std::real(). Bisakah Anda mengonfirmasi bahwa std::complex::real() akan memperbaiki masalah.

Hai @dylanbespalko ,

Saya kira apa yang @iotamudelta keluhkan adalah cast_and_store untuk tipe kompleks tidak memiliki C10_HOST_DEVICE , ini akan menjadi UB jika jalur kode itu pernah dieksekusi pada GPU.

Saat ini, utilitas casting dinamis ini hanya digunakan di GPU TensorIterator, dan hanya digunakan ketika ada promosi jenis. Untuk alasan kompleks tidak didukung pada GPU saat ini, cast_and_store untuk tipe kompleks saat ini tidak memiliki kualifikasi C10_HOST_DEVICE dan menggunakan std::real yang benar-benar OK untuk host- hanya fungsi. Tidak ada UB di sini karena tidak digunakan dan tidak ada yang perlu dikhawatirkan.

Tetapi karena Anda ingin menambahkan dukungan kompleks ke GPU, dan kompleks didukung oleh jenis promosi seperti yang dapat kita lihat di https://github.com/pytorch/pytorch/blob/master/c10/core/ScalarType.h#L398 - L420, Anda harus sangat berhati-hati pada jalur kode ini dan ada beberapa modifikasi yang mungkin perlu Anda lakukan untuk membuatnya berfungsi:

Tentu saja, Anda perlu menambahkan C10_HOST_DEVICE seperti yang dilakukan @iotamudelta di https://github.com/pytorch/pytorch/pull/29547 , tetapi itu tidak cukup, karena hanya menambahkan C10_HOST_DEVICE tanpa perubahan lain masih UB pada C++11 seperti yang disebutkan oleh @iotamudelta , solusi yang baik mungkin seperti yang Anda sebutkan: gunakan std::complex::real() untuk mengganti std::real .

Tetapi di luar itu, jika Anda melihat file https://github.com/pytorch/pytorch/blob/master/c10/util/TypeCast.h , Anda akan melihat di dalam fetch_and_cast , ada sesuatu seperti:

#ifndef C10_HOST_DEVICE
    AT_FORALL_COMPLEX_TYPES(FETCH_AND_CAST_COMPLEX_CASE)
#endif

Jalur kode ini dinonaktifkan pada GPU. Anda harus mengaktifkannya dan membuatnya berfungsi.

Juga, saya tidak melihat konversi apa pun antara complex<float> dan complex<double> di dalam fetch_and_cast dan cast_and_store . Anda mungkin juga perlu menambahkan konversi untuk itu. Pastikan Anda menguji secara menyeluruh pada cakupan fungsi-fungsi ini dari semua tipe d.

cc: @ezyang dan @bddppq

Juga @dylanbespalko , tolong cc saya jika Anda membuat perubahan ke TypeCast.h di PR Anda.

Oke, saya punya beberapa hal kecil yang harus diperbaiki dengan torch.real() dan torch.imag() di ARM, jadi saya akan memperbaiki TypeCast.h dan beberapa lainnya saat saya melakukannya. Aku akan cc kalian di PR.

Drive by comment: @smessmer memindahkan kami ke C++14, di mana itu bukan UB. Karena ini akan segera hadir, jika UB tidak menimbulkan masalah nyata saya tidak akan terlalu khawatir.

@ezyang : Senang mengetahuinya. Sebagian besar barang pihak ketiga seperti Eigen masih menyebut std::real() dengan sangat bebas.

Untuk bilangan non-kompleks, scalar_t dan thrust_t adalah tipe yang sama. Mungkin saya bisa mengganti nama variabel thrust_t dengan sesuatu yang lebih ramah untuk angka non-kompleks, seperti scalar_t_c?

Saya tidak terlalu yakin, tetapi scalar_t_c tampaknya sedikit kurang jelas daripada thrust_t (apa maksud dari c ?) Jenis yang dimaksud di sini tampaknya cukup spesifik, jadi sepertinya lebih baik menggunakan nama yang langsung berbicara tentang niat.

Oke, saya akan tetap menggunakan thrust_t . Jika ada yang menyelam ke ztype_cuda<>() mereka harus langsung mengetahui bahwa scalar_t adalah thrust_t untuk tipe non-kompleks.

Silakan lihat https://github.com/pytorch/pytorch/pull/29612

Halo semuanya! Sepertinya kemajuan yang baik sedang dibuat untuk menambahkan dukungan kompleks ke pytorch! Terima kasih @dylanbespalko telah mengambil inisiatif dalam hal ini dan menambahkan dukungan CUDA juga! Dari tingkat tinggi, saya tertarik untuk mengetahui apa kemajuan saat ini dalam dukungan kompleks? Saya sebagian besar tertarik pada garis waktu kasar untuk memiliki dukungan CUDA untuk menambah dan mengalikan tensor kompleks (ops biner). Terima kasih!

Hai @sunilkpai ,

Saya memiliki PR terbuka yang seharusnya mendukung operasi biner dan unary di CUDA: #30295.

Satu masalah lagi adalah dengan propagasi mundur. Saya pikir turunan dari kompleks abs() didefinisikan berbeda dari bilangan real. Tidak yakin apa yang harus dilakukan tentang itu, tetapi turunan didefinisikan dalam tools/autograd/derivatives.yaml

Saya pikir untuk bilangan kompleks /dz abs(z) = z/abs(z) . Ini dapat digunakan untuk bilangan real juga, tetapi kemungkinan akan lebih lambat dari sgn(z)

@dylanbespalko Mungkin tabel 4.1, 4.2 dan 4.3 dalam Laporan saya https://arxiv.org/pdf/1701.00392.pdf dapat membantu Anda menentukan turunannya.

Untuk turunan kompleks (kalkulus wirtinger), ada dua pilihan.
Menghitung turunan wrt z atau konjugat z.
Saya pribadi lebih menyukai turunan wrt z conjugate.
Terasa lebih alami untuk operasi matriks dan pembaruan gradien tidak memerlukan konjugat.
Definisi dari mereka adalah:

• turunan wrt z untuk z = x + jy : dJ/dz = dJ/dx -j dJ/dy
• turunan wrt z.conj untuk z = x + jy : dJ/dz.conj = dJ/dx + j dJ/dy

Dari komentar Anda, asumsi saya adalah, Anda menghitung turunannya dengan z saat ini.
Dalam hal ini turunannya adalah d abs(z) / d z = z.conj / abs(z) . Ketika Anda mengambil definisi lain, Anda dapat mengikuti saran @Randl .

Beri tahu saya jika saya harus menjelaskan lebih lanjut. Saya juga memiliki beberapa implementasi numpy untuk turunan kompleks.

Satu operasi lain yang akan berguna (terutama untuk proyek-proyek di ruang fisika yang membutuhkan dukungan bilangan kompleks) adalah handler untuk operator exp() . Di tensorflow, kami memiliki tf.exp(x + iy) = tf.exp(x) * (tf.cos(y) + 1j * tf.sin(y)) . Apakah ini mudah diterapkan di pytorch juga?

@sunilkpai , @boeddeker , @Randl ,

Terima kasih atas laporan tentang turunan kompleks. Saya akan mencoba mengikuti itu dan saya akan kembali pada minggu depan. Saya pikir saya akan menambahkan beberapa tautan di sini dan menjelaskan status proyek.

Status bilangan kompleks didukung secara tidak resmi dan harus ditambahkan melalui Ekstensi PyTorch:

• pytorch-cpu-melangkah-kompleks
• pytorch-cuda-melangkah-kompleks

Setiap ekstensi berisi dua hal:

• .cpp yang berisi registrasi kernel matematika yang diperlukan.
• Folder test/ yang berisi versi skrip uji pytorch yang sangat disederhanakan.
  Lihat di skrip pengujian untuk melihat kernel mana yang didukung (dan mengapa yang lain tidak).

Mengapa saya tidak dapat mencetak tensor kompleks ke konsol?

• Objek python Tensor memiliki beberapa format cetak cantik yang memanggil beberapa fungsi yang tidak didukung.
  
  
  
  • Anda dapat memodifikasi konten tensor.py untuk mengabaikan pemformatan cetak.
  
  
  • Atau, Anda cukup mengonversi tensor Pytorch ke array Numpy lalu mencetak.
  
  

Status Proyek Saat Ini:

• Cakupan CPU cukup baik.
  
  
  
  • Kernel diimplementasikan di dalam PyTorch di bawah 'aten/src/ATen/native/cpu/ </li> <li>Complex number specific code is under 'aten/src/ATen/native/cpu/zmath.h
  
  
  • Akselerasi Intel AVX256 berada di bawah 'aten/src/ATen/cpu/vec256/`
    
    
    
    
    
    • @sunilkpai : Saya tidak tahu optimasi exp. Ini adalah folder tempat Anda menambahkannya.
    
    
    
    • Beri tahu saya jika Anda merasa nyaman melakukan perubahan.
    
    
    
  
  
• Cakupan GPU terbatas pada operasi biner dan unary:
  
  
  
  • Kernel diimplementasikan di dalam PyTorch di bawah 'aten/src/ATen/native/cuda/* </li> <li>Complex number specific code is under 'aten/src/ATen/native/cuda/zmath.cuh
  
  
  • Tipe data thrust::complex<T> digunakan dan termasuk kernel yang dioptimalkan.
  
  

Perkembangan zaman:

• Menunggu kernel TH berbasis C untuk porting ke folder C++ ATen.
  
  
  
  • Fungsi rand() diperlukan untuk mem-port kasus uji ke pengujian internal pytorch.
  
  
  • Beberapa operasi pengindeksan saat ini tidak porting.
  
  
  • Saat ini ada 168/1300 kernel matematika (turun dari 230 di bulan Oktober) yang perlu di-porting dari TH ke ATen.
  
  
• Saya akan mencoba menambahkan dukungan bilangan kompleks saat kernel ini tersedia di ATen.

--

FYI. Mengenai turunan kompleks, kami memiliki diskusi panjang di Julia dan implementasinya sekarang di ChainRules (lihat juga: http://www.juliadiff.org/ChainRules.jl/dev/api.html#ChainRulesCore.Wirtinger ) dan Zygote sekarang . Umumnya, orang hanya membutuhkan
\partial L/\partial adjoint(z) sebagai gradien (menurut definisi itu adalah arah penurunan tercepat), tetapi turunannya berbeda sebagai \partial L/\partial z , antarmuka tambahan harus ditambahkan, jika kita menginginkan dukungan penuh untuk bilangan kompleks AD . Untuk aturan terperinci, Anda dapat memeriksa apa yang diterapkan di ChainRules atau Zygote/lib (karena hanya ada aturan umum, tidak ada aturan terpisah untuk bilangan kompleks untuk sebagian besar operator, pass mundur untuk hal-hal seperti matmul ditulis dalam definisi umum misalnya adjoint(A) * B )

Mengapa saya tidak dapat mencetak tensor kompleks ke konsol?
Objek python Tensor memiliki beberapa format cetak cantik yang memanggil beberapa fungsi yang tidak didukung.
Anda dapat memodifikasi konten tensor.py untuk mengabaikan pemformatan cetak.
Atau, Anda cukup mengonversi tensor Pytorch ke array Numpy lalu mencetak.

Saya pikir saya memperbaiki setidaknya sebagian dari pencetakan di https://github.com/Roger-luo/pytorch-complex untuk debugging dll. Di tempat pertama, tidak yakin apakah ini akan membantu karena master telah banyak berubah di masa lalu tahun. Anda dapat mengambilnya jika itu membantu, saya tidak akan mengerjakan ini lagi.

@dylanbespalko Saya relatif tidak berpengalaman dengan internal pytorch, meskipun saya sudah mulai belajar! Saya dapat mencoba perubahan ini, meskipun berdasarkan apa yang saya lihat di aten/src/ATen/cpu/vec256/* , saya tidak yakin apakah itu perlu mengingat bahwa perilaku default std::exp(std::complex) persis seperti yang saya sebutkan dalam komentar saya sebelumnya: lihat catatan https://en.cppreference.com/w/cpp/numeric/complex/exp . Saya juga tidak yakin bagaimana ini diterjemahkan ke dalam implementasi ops ini di CUDA (yang saat ini tampaknya terbatas pada real, imag, conj, dan angle?).

@sunilkpai ,

Saya telah menambahkan dukungan AVX untuk exp() menggunakan persamaan yang disediakan.

Saya juga memperhatikan beberapa hal yang rusak karena beberapa perubahan terbaru di PyTorch. Saya telah memperbaikinya di #30871.

@dylanbespalko

Apakah ada timeline untuk porting dari TH ke ATen?
Apakah ada cara saya dapat berkontribusi, mengingat fakta bahwa saya tidak berpengalaman dengan cara kerja pytorch?

Saya menemukan formula untuk backpropagation dari svd kompleks di arxiv dan dapat mengimplementasikannya, jika Anda tunjukkan di mana

Terima kasih atas pekerjaan Anda!

@Jakob-Unfried

https://github.com/pytorch/pytorch/wiki/TH-to-ATen-porting-guide

Kernel TH diimplementasikan dalam C dan ada sedikit minat untuk menambahkan dukungan kompleks di sana karena semua masalah penghitungan referensi yang melekat. Anda dapat melacak kemajuan di aten/src/ATen/native/native_functions.yaml di mana setiap kernel terdaftar:

Cari legacy::cpu::_th dan bagi angka itu dengan 3 untuk jumlah kernel TH lama.
Cari legacy::cpu::_thnn dan bagi angka itu dengan 3 untuk jumlah kernel jaringan saraf TH lama.

Setiap kernel biasanya terdaftar dengan 3 cara berbeda:
1. Kernel Reguler y = tambah(a, b)
2. Kernel Di Tempat a = add_(a, b)
3. Output Kernel add_out(a, b, out=y)
Implementasi sebenarnya selalu di Kernel Keluaran dan 2 lainnya memanggil fungsi itu.

Kernel nn cenderung lebih mudah di-porting karena memiliki lebih sedikit kernel dependen. Oleh karena itu, Jika Anda dapat mem-port kernel dalam urutan terbalik dari cara implementasinya, maka Anda akan melakukan lebih sedikit pekerjaan secara keseluruhan.

Memeriksa masalah pelacakan porting https://github.com/pytorch/pytorch/issues/24507 , juga cc @VitalyFedyunin

Berikut adalah pembaruan status pada dukungan nomor kompleks seperti yang diminta di #32437. Saya kembali mengerjakan dukungan terkait CPU hari ini.

Dukungan Autograd

• Saya tidak punya banyak waktu untuk ini.
• angle() , real() , imag() , conj() semuanya diimplementasikan.
• abs() akan membutuhkan implementasi terpisah untuk bilangan kompleks. (lihat catatan dari @boeddeker dan @Randl di atas)

Dukungan perangkat keras

Dukungan bilangan kompleks saat ini diimplementasikan out-of-tree. Inilah artinya:

Kode Dalam Pohon

• Operasi matematika sebenarnya diimplementasikan di dalam pohon (di dalam kode sumber PyTorch).
• Tak satu pun dari tes Pytorch dalam pohon memvalidasi dukungan bilangan kompleks (sehingga segala sesuatunya cenderung rusak).
• PyTorch sedang bermigrasi dari TH ke ATen (#24507).
  - Kernel matematika yang diimplementasikan di TH tidak mendukung bilangan kompleks.
  - Hanya kernel yang diimplementasikan di ATen yang dapat mendukung bilangan kompleks.
• Anda perlu menginstal Ekstensi PyTorch untuk mengaktifkan tipe dtype.

Kode Di Luar Pohon

• Beberapa Ekstensi PyTorch diimplementasikan dan dapat dengan mudah diinternalisasi di masa mendatang:
• Setiap ekstensi memiliki empat file penting:
  
  
  
  • setup.py: buat dan instal ekstensi pytorch.
  
  
  • [CPU/CUDA/FPGA]ComplexType.cpp: Pendaftaran kernel matematika mirip dengan CPUType.cpp atau CUDAType.cpp
  
  
  • test/test_torch.py: Kasus uji yang sangat jelek yang menunjukkan kernel mana yang berfungsi, dibatasi oleh dukungan ATen.
  
  
  • test/test_autograd.py: Menguji fungsionalitas autograd.
  
  

Ekstensi PyTorch Di Luar Pohon

1. cpu_strided_complex
   - [x] CopyKernel
   - [ ] TensorFactories (th_random, th_uniform, th_normal)
   - [x] Pabrik Rentang
   - [x] BinaryOpKernals
   - [x] UnaryOpKernels
   - [x] BandingkanOpKernels
   - [x] PowKernels
   - [x] ReduceOpKernels (th_min, th_max, beberapa norma tidak menghitung konjugat kompleks)
   - [ ] IndexOpKernels (th_masked_select_bool, th_set, th_gather, th_cat)
   - [x] PointwiseOps
   - [x] Operasi Lerp
   - [ ] BlasOps (th_mv, th_mm, th_fmod, th_eig)
   - [ ] LinpackOps (menggunakan Blas)
   - [ ] SpectralOps (didukung, tetapi perlu bekerja)
   
   
   
   1. cuda_strided_complex
      
      
      
      
      
      • [x] CopyKernel
      
      
      
      • [ ] TensorFactories (lihat masalah cpu)
      
      
      
      • [x] BinaryOpKernals
      
      
      
      • [x] UnaryOpKernels (Lakukan: menambah sudut, nyata, gambar, konj)
      
      
      
      • [ ] BandingkanOpKernels (Todo)
      
      
      
      • [ ] ReduceOpKernels (Pesan kesalahan terkait WARP_SIZE)
      
      
      
      • GPU menjadi sulit di luar perhitungan poin-bijaksana, namun fungsi tambahan dapat didukung
      
      
      
   
   
2. vitis_strided_complex
   
   
   
   • Xilinx Vitis adalah platform sintesis Tingkat Tinggi FPGA yang mendukung server dan perangkat yang disematkan.
   
   
   • Dirilis pada Oktober 2019 (kemungkinan dukungan terbatas untuk perangkat).
   
   
   • Menggabungkan SDaccel (server) dengan VIvado HLS (tertanam).
   
   
   • [ ] BinaryOpKernals (Akhir Jan)
   
   
   • [ ] UnaryOpKernels (Akhir Jan)
   
   
   • [ ] ReduceOpKernels (Akhir Februari).
   
   
   • FPGA baru-baru ini menambahkan dukungan objek vektor yang serupa dengan kelas template Vec256 PyTorch
   
   
   • Vec256 adalah bagaimana dukungan kompleks ditambahkan ke CPU dan sepertinya cara yang lebih alami untuk mengimplementasikan ruang tensor $C$ atau $R^N$
   
   

Pembaruan lebih lanjut untuk masalah ini: https://github.com/pytorch/pytorch/issues/33152

Ini mungkin atau mungkin tidak pantas mendapatkan masalah terpisah, tetapi saya akan menghargai melihat dan berpikir itu praktis lebih penting saat ini untuk memiliki sesuatu dalam dokumentasi yang menjelaskan 'bagaimana pytorch bekerja dengan bilangan kompleks sekarang'. alias dapat melakukan penjumlahan, perkalian, semacam norma, tidak dapat memiliki bobot kompleks, dll. Semuanya dapat diringkas oleh beberapa baris dokumentasi yang menjelaskan apa yang dimaksud dengan perilaku tingkat tinggi saat ini.

Ini mungkin atau mungkin tidak pantas mendapatkan masalah terpisah, tetapi saya akan menghargai melihat dan berpikir itu praktis lebih penting saat ini untuk memiliki sesuatu dalam dokumentasi yang menjelaskan 'bagaimana pytorch bekerja dengan bilangan kompleks sekarang'. alias dapat melakukan penjumlahan, perkalian, semacam norma, tidak dapat memiliki bobot kompleks, dll. Semuanya dapat diringkas oleh beberapa baris dokumentasi yang menjelaskan apa yang dimaksud dengan perilaku tingkat tinggi saat ini.

Hai @redwrasse terima kasih atas umpan baliknya! saat ini kami memiliki catatan untuk bilangan kompleks yang berbicara tentang beberapa dasar obor dan fungsi kompleks yang didukung untuk tensor kompleks pada master
(sebagian besar termasuk dalam rilis 1.6) https://pytorch.org/docs/master/complex_numbers.html?highlight=complex. Bisakah Anda membagikan fungsi apa lagi yang Anda minati? senang berbicara lebih banyak tentang dukungan kami saat ini dan apa rencana untuk rilis mendatang.

Ini mungkin atau mungkin tidak pantas mendapatkan masalah terpisah, tetapi saya akan menghargai melihat dan berpikir itu praktis lebih penting saat ini untuk memiliki sesuatu dalam dokumentasi yang menjelaskan 'bagaimana pytorch bekerja dengan bilangan kompleks sekarang'. alias dapat melakukan penjumlahan, perkalian, semacam norma, tidak dapat memiliki bobot kompleks, dll. Semuanya dapat diringkas oleh beberapa baris dokumentasi yang menjelaskan apa yang dimaksud dengan perilaku tingkat tinggi saat ini.

Hai @redwrasse terima kasih atas umpan baliknya! saat ini kami memiliki catatan untuk bilangan kompleks yang berbicara tentang beberapa dasar obor dan fungsi kompleks yang didukung untuk tensor kompleks pada master
(sebagian besar termasuk dalam rilis 1.6) https://pytorch.org/docs/master/complex_numbers.html?highlight=complex. Bisakah Anda membagikan fungsi apa lagi yang Anda minati? senang berbicara lebih banyak tentang dukungan kami saat ini dan apa rencana untuk rilis mendatang.

Terima kasih @anjali411 , senang melihat dokumentasi ini, saya tidak mengetahuinya sebelumnya. Saya pikir apa yang dibutuhkan adalah di depan dan di tengah beberapa baris 'keadaan dukungan saat ini untuk jaringan saraf kompleks', tetapi biarkan saya melewatinya ...

Orang yang tertarik dengan autograd kompleks, Anda mungkin tertarik dengan https://github.com/pytorch/pytorch/issues/41857 yang menyentuh konvensi apa yang akan diikuti PyTorch (JAX atau TF).