Numpy: np.clip dengan input kompleks belum teruji dan memiliki perilaku aneh

Dibuat pada 23 Feb 2020  ·  8Komentar  ·  Sumber: numpy/numpy

Ini muncul di https://github.com/pytorch/pytorch/issues/33568. Ini tampak aneh:

>>> np.clip([3 + 4.j], -1, 2)                                                                                       
array([2.+0.j])
>>> np.clip([3 + 4.j], -1+1.j, 2+12.j)  # imaginary component goes up                                                                   
array([2.+12.j])
>>> np.clip([1 + 4.j], -1+1.j, 2+12.j)  # imaginary component doesn't go up                                                                             
array([1.+4.j])

Satu-satunya tes untuk input yang kompleks adalah bahwa itu tidak segfault.

Perilaku yang masuk akal dapat berupa salah satu dari:

  • Gunting bagian nyata dan imajiner secara terpisah
  • Klip nilai absolut, tidak mengubah fase
    Mungkin ada pilihan lain. Selama itu didokumentasikan, saya tidak terlalu yakin pilihan mana yang diambil.

Saya rasa ini bukan masalah yang sangat penting, tetapi alangkah baiknya jika perilaku yang diinginkan didokumentasikan di sini.

00 - Bug numpy.core

Komentar yang paling membantu

@mruberry , saya setuju, dalam hal apa pun saya bahkan tidak yakin ada yang memiliki kasus penggunaan untuk ini, yang akan sangat memotivasi saya untuk melakukan apa pun. Sebagai salah satu argumen untuk membuatnya sedikit lebih baik, jika Anda memastikan bahwa min.real <= max.real dan min.imag <= max.imag sebagai lawan hanya min <= max , maka semuanya baik-baik saja (meskipun saat ini kami tidak pastikan ini di NumPy).

Semua 8 komentar

Perilaku saat ini adalah membuat x = sorted(x) untuk x = [min, clip(arr, min, max), max] , saya kira.

Saya ragu adalah berharga untuk merusak konsistensi dengan min, max, menyortir di sini untuk pilihan perilaku yang tidak jelas. Bukan berarti kita tidak bisa melakukannya, tetapi kita mungkin juga harus membahas min / max dan perilaku penyortiran ...
Dan jika itu berarti bahwa absmin , absmax , dan abssort akan masuk akal dan pada dasarnya menggunakannya untuk pemotongan.
Saya bisa lebih mudah diyakinkan untuk hanya memberikan kesalahan untuk input non-nyata.

EDIT: Kliping berdasarkan komponen sebenarnya memungkinkan perilaku Erics, karena lebih ketat. Tapi hanya catatan, saya tidak yakin saya membelinya karena bermanfaat. Pertanyaan lainnya adalah: apakah ada usecase sebenarnya untuk ini sama sekali? Yang tidak jelas dengan kode yang berbeda?

Gunting bagian nyata dan imajiner secara terpisah

Itu akan menjadi pilihan pertamaku.

Klip nilai absolut, tidak mengubah fase

Bisa berguna tetapi lebih rumit untuk diterapkan daripada klip sederhana.

Pertanyaan lainnya adalah: apakah sebenarnya ada _usecase_ untuk ini? Yang tidak jelas dengan kode yang berbeda?

Itu pertanyaan yang bagus. Saya tidak yakin. Yang saya tahu adalah itu seharusnya tidak terlalu salah.

Saya khawatir tentang memotong bagian nyata dan imajiner secara terpisah. Jika kita memiliki larik yang diurutkan, misalnya, maka pemotongan biasanya mengubah larik menjadi tiga wilayah: [min_value, unchanged, max_value]. Jika kita memotong bagian nyata dan imajiner dari larik kompleks secara terpisah, maka kita tidak akan lagi memiliki daerah yang dapat dipisahkan ini. Sebaliknya, nilai dapat berubah meskipun tidak dibandingkan kurang dari minimal atau lebih besar dari maks!

Saya juga akan merekomendasikan untuk menonaktifkan perilaku sampai ada keyakinan tentang apa, tepatnya, memotong nomor kompleks yang harus dilakukan. Proposal saya adalah jika c <min_value itu diatur ke min_value, dan jika c> max_value disetel ke max_value.

@mruberry , saya setuju, dalam hal apa pun saya bahkan tidak yakin ada yang memiliki kasus penggunaan untuk ini, yang akan sangat memotivasi saya untuk melakukan apa pun. Sebagai salah satu argumen untuk membuatnya sedikit lebih baik, jika Anda memastikan bahwa min.real <= max.real dan min.imag <= max.imag sebagai lawan hanya min <= max , maka semuanya baik-baik saja (meskipun saat ini kami tidak pastikan ini di NumPy).

Saya juga setuju dengan Anda @seberg ;).

Saya pikir kita akan menonaktifkan input kompleks clipping (kita menyebutnya penjepitan) di PyTorch untuk saat ini. Tingkah laku kami tidak sejalan dengan NumPy.

Sekadar membaca masalah ini, saya pikir mengingat perbandingan leksikografik di numpy, perilaku ini sebenarnya masuk akal. jika kita menghentikan perbandingan leksikografik, clip, max dan min juga harus mengikuti. Saya berasumsi bahwa ini adalah konsensus yang dicapai di sini, tetapi saya tidak terlalu yakin dari komentar dan PR yang terkait.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat