Julia: Keadaan produk dalam di Basis

Bisakah Anda menjelaskan sedikit lebih banyak tentang kasus penggunaan Anda dan mengapa memilikinya di Base alih-alih hanya mendefinisikannya dalam paket Anda bermanfaat? Sebuah contoh konkret akan menjadi yang terbaik. Apakah Anda mengharapkan beberapa definisi inner di seluruh paket dimuat secara bersamaan?

Saya pikir memiliki antarmuka formal untuk ruang matematika ini akan membantu pengguna mengeksploitasi sistem tipe dengan lebih baik. Misalnya, saya berharap metode pengelompokan berfungsi pada ruang metrik apa pun. Jika saya dapat menentukan tipe saya dengan produk dalam, saya akan mendapat manfaat dari Clustering.jl di luar kotak (setelah paket diperbaiki). Banyak algoritma berbasis jarak atau berbasis proyeksi lainnya juga dapat digeneralisasi.

Sebagai contoh konkret, saya menemukan batasan ini hari ini mencoba mendefinisikan geometri untuk data komposisi: https://github.com/juliohm/CoDa.jl Saya lebih suka berspesialisasi pada fungsi inner yang terkenal didefinisikan di Basis daripada mendefinisikan antarmuka saya sendiri yang tidak akan diketahui orang lain.

Mengapa tidak memperpanjang dot untuk tipe ruang Hilbert Anda? Saya cukup yakin itu dirancang dengan mempertimbangkan produk batin generik.

Konsep hasil kali titik lebih ketat daripada konsep hasil kali dalam. Sedangkan yang terakhir didefinisikan untuk ruang umum, produk titik hanya didefinisikan ketika ada gagasan tentang sistem koordinat yang ditentukan oleh basis yang terbatas. Semantik dari dot(x,y) adalah x'*y di mana x dan y merepresentasikan koordinat objek di dunia Cartesian. Buku teks matematika jarang menyebutkan istilah produk titik karena penulis biasanya tertarik untuk membahas materi dalam ruang yang lebih umum (tidak harus terbatas atau Euclidean).

Untuk membedakan lebih lanjut, dalam ruang Hilbert dengan produk dalam <x,y> (atau inner(x,y) ) objek bisa tak terbatas dan semantik x'*y tidak berlaku. Misalnya, dalam analisis data fungsional objeknya adalah fungsi f dan g dan produk dalam biasanya diperoleh dengan integrasi numerik: inner(f,g) = quadrature(f*g) . Menyebut operasi ini sebagai produk titik adalah menyesatkan.

Contoh lain seperti yang saya tunjukkan dalam paket CoDa.jl saya adalah data komposisi. Objek komposisi terletak di dunia simpleks di mana operasi x'*y tidak masuk akal. Namun, terdapat transformasi isometrik (transformasi log-rasio) yang dapat digunakan untuk memetakan komposisi ke dalam geometri lain di mana seseorang kemudian dapat menerapkan produk titik dengan koordinat. Bekerja dengan koordinat tidak diperlukan, tetapi itu adalah praktik umum di bidang ini. Hasilnya dapat ditransformasikan kembali ke ruang semula di mana benda-benda itu berada.

Saya tidak melihat manfaat dalam mempertahankan istilah dot dalam bahasa, tetapi jika seseorang meminta kompatibilitas ke belakang, generalisasi inner(x::AbstractVector, y::AbstractVector) = dot(x,y) bekerja dengan sempurna.

Bisakah Anda menguraikan keberatan atas perubahan ini?

Bisakah Anda menguraikan keberatan atas perubahan ini?

Kami umumnya membutuhkan cukup banyak pembenaran untuk menambahkan fungsi publik baru ke Base, itulah keberatannya. Ini dapat disediakan oleh paket InnerProducts . Mengapa itu perlu dibangun ke dalam bahasa itu sendiri? Ini adalah pertanyaan pertama yang @andreasnoack tanyakan di atas – jawaban yang agak kabur adalah "Saya pikir memiliki antarmuka formal untuk ruang matematika ini akan membantu pengguna mengeksploitasi sistem tipe dengan lebih baik". Tidak ada alasan bahwa antarmuka yang didefinisikan dalam sebuah paket tidak seformal yang ada di Base. Apa yang ditawarkan Base.inner yang tidak ditawarkan oleh InnerProducts.inner ? Ini adalah pertanyaan asli yang dapat memiliki jawaban yang meyakinkan, tetapi saya tidak tahu apa jawaban itu, itulah sebabnya pertanyaan itu diajukan.

Saya tidak melihat argumen yang baik untuk mendefinisikan konsep matematika dasar seperti produk dalam di tempat lain yang tidak ada di Basis. Bahasa yang audiens utamanya adalah orang-orang komputasi ilmiah akan mendapat manfaat dari terminologi yang benar. Mengapa konsep norm didefinisikan dalam Base.LinAlg dan inner , yang berada pada kohort yang sama, harus didefinisikan dalam sebuah paket? Selain ketidakkonsistenan ini, bahasanya sudah memiliki dot , yang membuat saya bertanya-tanya mengapa harus memiliki sesuatu yang begitu spesifik daripada konsep yang lebih umum?

Jadi, Anda ingin semua kemungkinan konsep matematika dalam bahasa dasar? Tidak memiliki sesuatu yang didefinisikan di Base tidak memaksa orang untuk menggunakan terminologi yang salah. Fungsi norm diekspor dari LinAlg karena didefinisikan dan digunakan dalam LinAlg . Mirip dengan dot . Apakah Anda mengusulkan bahwa dot harus diganti namanya menjadi inner ?

Jadi, Anda ingin semua kemungkinan konsep matematika dalam bahasa dasar?

Saya tidak pernah mengatakan itu.

Tidak memiliki sesuatu yang didefinisikan di Base tidak memaksa orang untuk menggunakan terminologi yang salah.

Saya yakin tidak. Mempromosikan terminologi yang salah adalah masalahnya. Orang yang berasal dari latar belakang matematika yang kurang akan mengadopsi penggunaan titik karena mereka melihatnya di Base. Penggunaan istilah "titik" produk untuk mewakili konsep produk dalam tidak benar. Ini juga berbahaya bagi komunitas matematika, yang kadang-kadang berjuang untuk memperbaiki bekas luka yang ditinggalkan oleh terminologi yang salah ini. Siswa dari generasi saya secara konsisten harus merujuk ke buku-buku lama untuk mendapatkan terminologi yang benar, ini seharusnya tidak terjadi.

Apakah Anda mengusulkan bahwa titik itu harus diganti namanya menjadi inner

Itu sudah menjadi peningkatan besar menurut saya. Lihat semua contoh yang saya berikan di atas tentang data fungsional dan komposisional. Orang-orang di komunitas ini tidak akan pernah menggunakan istilah dot dalam pekerjaan mereka. "dot" lebih seperti istilah ilmu komputer daripada yang lainnya.

Mengganti nama dot menjadi inner adalah proposal yang sangat berbeda dari menambahkan inner ke Base selain dot . Itu lebih merupakan pertanyaan "terminologi yang benar", yang harus Anda dan orang-orang linalg lainnya harus keluarkan, meskipun saya ingat kami pernah melakukan bikeshed ini dan menyimpulkan bahwa dot adalah nama yang benar untuk apa yang diimplementasikan oleh fungsi ini.

Ada sedikit diskusi tentang ini di https://github.com/JuliaLang/julia/issues/22227 dan https://github.com/JuliaLang/julia/pull/22220

Mengganti nama titik menjadi bagian dalam adalah proposal yang sangat berbeda dari menambahkan bagian dalam ke Basis selain titik.

Inilah yang saya usulkan dalam pesan pertama saya di utas ini:

Saya ingin mengusulkan penggantian nama dot menjadi inner, atau mungkin mengarahkan pengguna untuk mendefinisikan inner(x,y) sebagai produk dalam umum antara objek x dan y

Saya ulangi produk titik adalah istilah yang salah untuk operasi yang saya diskusikan di sini. Dalam, luar, produk skalar... ini adalah objek matematika. "produk titik" adalah objek komputasi: ia mendapat dua urutan angka dan melakukan x1*y1 + x2*y2 + ... xn*yn , operasi yang tidak berguna di ruang matematika lainnya.

Saya telah fokus pada opsi kedua yang Anda usulkan, yang tampaknya telah menambahkan Base.inner dengan fallback untuk memanggil Base.dot . Pilihan mana pun dimungkinkan, tetapi keduanya memerlukan beberapa pembenaran: untuk menambahkan operasi baru, seseorang memerlukan alasan mengapa itu tidak bisa hanya dalam satu paket (apa bagian awal dari diskusi ini); untuk mengganti nama, perlu diputuskan bahwa dot adalah nama yang salah dan inner adalah nama yang benar (tampaknya percakapan berubah menjadi apa).

@juliohm Mungkin perlu (kembali) menyatakan bahwa ada upaya aktif yang saat ini mencoba mengecilkan Base dan mendorong penggunaan paket. Dalam hal ini dot tampaknya benar untuk semua jenis yang berpartisipasi dalam aljabar linier yang disediakan dalam Julia standar (yaitu Number dan Array - jadi ya, ada yang pasti, diketahui , basis yang terbatas dalam semua kasus - jadi saya tidak berpikir kami telah membuat kesalahan dalam terminologi, meskipun mungkin ada pilihan yang lebih baik). Saya tidak menentang proposal ini - tetapi ingin menunjukkan ini untuk mengklarifikasi mengapa Anda mungkin mengalami penolakan "tersembunyi" terhadap perubahan.

Juga perlu diingat bahwa cukup banyak pendatang baru Julia mungkin akrab dengan produk titik tetapi bukan produk dalam (katakanlah, mereka melakukan sedikit fisika di universitas, tetapi bukan jurusan matematika) jadi ada juga beberapa alasan untuk keep dot (belum lagi kami memiliki operator infiks yang sesuai dengannya - kami hanya dapat memetakannya ke inner saya kira tapi itu sedikit kurang jelas). Kami juga tidak memiliki fungsi outer , atau berbagai kemungkinan operasi lainnya.

Jadi, ada beban untuk membuat kasus yang masuk akal tentang bagaimana memasukkan ini ke dalam Base (atau LinAlg ) benar-benar lebih baik daripada memasukkan ini ke dalam paket pengguna. Alasan utama tampaknya adalah untuk menyediakan antarmuka yang dapat dibagikan dan diperluas oleh orang lain - apakah itu ringkasan yang masuk akal? Argumen tentang membiarkan kode generik dari Clustering.jl bekerja dengan produk batin Anda tampaknya cukup menarik. Juga, dalam konteks bahwa kita tampaknya membagi LinAlg menjadi paket stdlib - saya berpikir bahwa jika saya menulis paket bernama LinearAlgebra saya mungkin akan dengan senang hati menyertakan inner berfungsi untuk diperluas orang lain.

Terima kasih @andyferris telah berbagi pemikiran Anda. Saya melihat perlawanan dengan sangat jelas, yang merupakan sesuatu yang saya tidak terlalu bersemangat. Namun demikian, saya ingin tahu tentang bagaimana proposal khusus ini mengarah pada peningkatan kode? Bagi saya, sepertinya perubahan kecil dalam kode dengan peningkatan besar dalam abstraksi. Contoh dengan Clustering.jl hanyalah salah satu dari banyak, pikirkan metode berbasis kernel apa pun yang dapat dibuat untuk bekerja dengan tipe Julia arbitrer yang gagasan tentang produk dalam ada. MultivariateStats.jl memiliki banyak dari mereka.

Mengenai komentar tentang LinAlg dipecah menjadi paket terpisah, saya setuju bahwa sepertinya tempat yang bagus untuk merangkum produk matematika. Saya berasumsi bahwa paket LinearAlgebra masa depan ini akan diimpor dalam sesi Julia secara default sehingga semua pengguna akan memiliki akses ke konsep inner , outer , dll segera.

Ya, semua pustaka standar dibuat bersama dengan citra sistem Julia dan tersedia secara default. Setidaknya untuk seri v1.x tidak ada yang perlu mengetik using LinAlg (Saya tidak berpikir itu akan diganti namanya LinearAlgbebra , btw, saya hanya membuatnya sebagai pesaing hipotetis) .

Untuk memperjelas, itu akan dimuat dengan Julia standar sehingga Anda tidak perlu menginstal apa pun, tetapi Anda masih harus menulis using LinAlg untuk mendapatkan nama yang diekspornya.

Di sinilah anehnya, kan, karena kita akan mendapatkan metode * dan seterusnya tanpa using LinAlg ? (dalam istilah lain, LinAlg adalah tipe bajak laut).

Ya, itu pada dasarnya di mana kita harus menarik garis: Basis harus mendefinisikan fungsionalitas aljabar linier sebanyak yang diperlukan untuk membuat LinAlg bukan bajak laut, jadi matmul didefinisikan di Basis karena Array dan * keduanya. Jenis matriks yang funky dan operasi non-basis tinggal di sana.

Izinkan saya memberi Anda contoh konkret dan menanyakan bagaimana Anda menyelesaikannya dengan antarmuka saat ini, mungkin ini dapat memperjelas banyak hal untuk saya.

Tujuannya adalah untuk melakukan analisis faktor dengan komposisi data. Saya memiliki tipe yang disebut Composition dan produk dalam di ruang komposisi. Saya mengumpulkan banyak sampel (mis. sampel batuan) dan memasukkan semuanya ke dalam Vector{Composition} besar (mis. komposisi = %air, %butir, %udara). Sekarang saya ingin memanggil algoritma analisis faktor yang diimplementasikan dalam paket lain (misalnya MultivariateStats.jl) pada vektor data ini. Bagaimana Anda menerapkannya secara umum tanpa produk inner diimpor secara default?

Apa yang saya pahami dari komentar terakhir adalah bahwa MultivariateStats.jl dan CoDa.jl harus bergantung pada LinAlg.jl. Ketergantungan pada MultivariateStats.jl hanya untuk membawa nama inner ke dalam ruang lingkup. Ketergantungan pada CoDa.jl adalah untuk mendefinisikan metode untuk inner yang dapat dipanggil oleh MultivariateStats.jl. Apakah itu yang Anda sarankan?

Tampaknya Composition{D} adalah ruang vektor berdimensi D di bawah + dan * .

Saya akan sangat tergoda untuk mendefinisikan ruang vektor ganda.

Jadi, Anda dapat mendefinisikan adjoint(::Composition) -> DualComposition dan *(::DualComposition, ::Composition) -> scalar (saat ini inner ). DualComposition tidak perlu melakukan banyak hal kecuali menyimpan Composition di dalamnya.

Kalimat pertama di https://en.wikipedia.org/wiki/Dot_product tampaknya menunjukkan bahwa dot dapat berupa operasi pada dua iterable mana pun. Kita bisa membuatnya rekursif dan mendefinisikannya untuk Number , dan mendefinisikan inner sebagai fungsi aljabar linier abstrak, yang kebetulan tumpang tindih untuk Number dan AbstractArray .

Terima kasih @andyferris , saya menghargai pemikiran Anda tentang ruang ganda. Saya lebih suka tidak bergantung pada tipe baru untuk tugas ini. Solusi akhir tidak perlu rumit.

Apa yang saya tertarik untuk memahami adalah mengapa sesuatu seperti:

inner(x,y) = sum(x.*y)
norm(x) = sqrt(inner(x,x))

export inner, norm

tidak diterima di Base? Saya berasumsi hanya ini yang diperlukan untuk mendefinisikan nama fungsi secara umum bagi pengguna bahasa untuk berspesialisasi. Ingatlah bahwa saya mengajukan pertanyaan ini dengan minat yang tulus untuk memahami sudut pandang para pengembang inti. Saya ingin mengatakan ini sebelum percakapan masuk ke arah yang salah lagi.

Dari sudut pandang seseorang yang tertarik pada matematika secara umum, rasanya tidak wajar jika konsep-konsep ini tidak diekspor secara default, dan sebaliknya mendefinisikannya di dalam LinAlg . Saya menganggap LinAlg sebagai implementasi dari konsep tingkat tinggi ini untuk tipe array. Mungkin seluruh pekerjaan saya tidak memerlukan aljabar linier pada array, tetapi saya masih dapat mengambil manfaat dari konsep produk dalam di seluruh paket (mis. MultivariateStats.jl, Clustering.jl). Juga, saya mungkin tidak ingin memiliki LinAlg sebagai ketergantungan dalam paket saya karena tidak.

Jika saya bisa menekankannya lebih jauh, ada konsep hasil kali dalam, yang tidak bergantung pada array. Konsep ini diwakili oleh pernyataan export inner di Base. Ada implementasi produk dalam untuk objek seperti array yang mewakili koordinat inner(x,y) = sum(x.*y) . Operasi ini dapat didefinisikan sebagai metode fallback di Base seperti di atas, jika perlu.

Contoh lain dari use case adalah metode Krylov. Jika Anda memiliki misalnya ruang fungsi dengan produk dalam, maka Anda dapat menggunakan metode Krylov untuk mendekati masalah linier atau masalah eigen dalam subruang berdimensi-hingga kecil dari ruang fungsi berdimensi tak hingga itu.

Saya juga memiliki objek sendiri yang membentuk ruang vektor/Hilbert tetapi bukan bagian dari <: AbstractArray . Dari analogi yang juga array dengan peringkat N>1 membentuk ruang vektor dan dapat digunakan sebagai 'vektor' dalam metode Krylov, saya mulai mengandalkan penggunaan vecdot dan vecnorm menjadi gagasan umum tentang produk dalam dan norma. Jadi saya telah mengembangkan paket dengan metode Krylov yang menggunakan fungsi sebagai operator linier dan di mana 'vektor dapat berupa jenis apa pun, asalkan objek jenis itu mendukung vecdot , vecnorm dan beberapa hal lain ( scale! , zero , ...). Tapi mungkin itu menyalahgunakan apa yang dimaksud dengan konsep-konsep ini di Base, jadi akan lebih baik untuk meluruskan antarmuka yang benar di sini.

Benar - vecdot dapat diganti namanya inner .

(Sekarang saya samar-samar bertanya-tanya apakah norm sebenarnya harus dipanggil matrixnorm untuk matriks dengan norm selalu cocok inner . Tampaknya mungkin ada dua yang berbeda hal-hal yang terjadi dengan norm yang menyebabkan beberapa kesulitan untuk menggeneralisasikannya)

Faktanya, untuk objek seperti vektor umum, juga berguna untuk menanyakan dimensi ruang vektor (misalnya untuk memverifikasi bahwa dimensi Krylov tidak boleh lebih besar dari dimensi ruang penuh dalam contoh kasus penggunaan saya). Contoh array bersarang menunjukkan bahwa length bukanlah konsep yang tepat di sini, yaitu perlu ada beberapa gagasan rekursif tentang panjang untuk kasus-kasus tersebut.

Sekarang untuk contoh penggunaan array bersarang sebagai vektor umum, vecdot dan vecnorm dalam beberapa kasus bahkan bukan gagasan yang benar tentang produk dalam dan norma, seperti yang dibahas dalam #25093, yaitu tidak secara rekursif memanggil vecdot dan vecnorm . Interpretasi saya tentang fungsi-fungsi ini sebagai produk dalam umum dan fungsi norma adalah yang memicu #25093, tetapi tampaknya ini mungkin bukan bagaimana fungsi-fungsi ini dimaksudkan (sebagai gantinya tidak yakin apa yang dimaksudkan untuk mereka lakukan).

Jadi saya setuju bahwa kita memerlukan antarmuka yang konsisten di sini untuk digunakan di seluruh paket, yang karenanya akan berada di lokasi pusat (mungkin tidak di Basis tetapi tentu saja di Perpustakaan Standar, misalnya sehingga seseorang harus melakukan using VectorSpaces ). Adapun penamaan, saya melihat dua opsi:

Opsi 1 (interpretasi saya sejauh ini):
awalan vec menunjukkan properti objek itu ketika menafsirkannya sebagai vektor generik, oleh karena itu

• vecdot dan vecnorm untuk array bersarang diperbaiki (PR #25093)
• definisi veclength baru ditambahkan

Opsi 2 (mungkin lebih baik): gunakan nama yang lebih benar secara matematis

• inner
• dimension
• Tapi apa yang harus dilakukan dengan norm ?

Dan akhirnya, ping saja ke @stevenngj karena dia pasti akan mendapat beberapa komentar yang berguna; saya minta maaf jika ini tidak nyaman.

Nama adalah bagian yang paling tidak menarik dari semua ini. Saya tidak memiliki masalah dengan menggunakan fungsi dot untuk merujuk ke produk dalam umum untuk ruang Hilbert sewenang-wenang. Tidak hanya tidak ada arti lain yang masuk akal untuk misalnya "perkalian titik dari dua fungsi", itu cukup umum untuk melihat "perkalian titik dari fungsi" dalam penggunaan informal, terutama dalam pengaturan pedagogis di mana seseorang mencoba untuk menekankan analogi vektor dimensi hingga spasi.

@juliohm , inner(x,y) = sum(x.*y) bahkan bukan produk dalam secara umum, jadi ini akan menjadi fallback yang sangat buruk untuk dimasukkan ke basis.

Tapi dot sudah tidak menghitung produk dalam yang benar (sebenarnya gagal) untuk berbagai objek di Base yang berperilaku sebagai vektor, misalnya array dengan peringkat N>1 atau array bersarang (vektor bersarang menjadi satu-satunya kasus di mana ia bekerja dengan benar). Selanjutnya, nama generik norm menjadi ambigu untuk matriks, karena saya setuju dengan pilihan saat ini untuk mengembalikan norma induksi, tetapi kadang-kadang "norma vektor" (norma Frobenius) juga diperlukan.

Oleh karena itu, proposal saya yang paling tidak berdampak adalah melepaskan semantik vecnorm(x) = norm(vec(x)) dan lebih menginterpretasikan vecnorm(x) sebagai "untuk x menjadi objek dari beberapa tipe generik yang berperilaku sebagai ruang vektor, hitung norma vektor yang sesuai dari x " (dan serupa dengan vecdot ). Meskipun ini adalah pergeseran interpretasi (dan karenanya dokumentasi), implementasi/tindakan aktual untuk objek di Base tidak akan jauh berbeda (PR #25093) dan akan menghasilkan hasil yang sama untuk sebagian besar kasus (peringkat array N skalar atau vektor). Sebuah fungsi veclength(x) yang mengembalikan dimensi ruang vektor yang sesuai dari x akan melengkapi antarmuka.

Paket khusus kemudian harus belajar mengimplementasikan fungsi-fungsi ini ketika mereka mendefinisikan tipe baru yang berperilaku sebagai vektor.

cukup umum untuk melihat "perkalian titik dari fungsi" dalam penggunaan informal, terutama dalam pengaturan pedagogis di mana seseorang mencoba untuk menekankan analogi dengan ruang vektor berdimensi-hingga

Tolong jangan katakan nama itu tidak penting, karena memang begitu. Saya akan ulangi untuk ke-n kalinya: produk dalam dan produk titik bukanlah hal yang sama. Materi serius apa pun yang mengekspos karya dengan ruang abstrak Hilbert tidak akan pernah menggunakan "titik". Jika Anda lebih suka mempercayai Wikipedia daripada kata-kata saya, berikut adalah definisi yang disalin dan ditempel:

Produk dalam

Dalam aljabar linier, ruang hasil kali dalam adalah ruang vektor dengan struktur tambahan yang disebut hasil kali dalam. Struktur tambahan ini menghubungkan setiap pasangan vektor dalam ruang dengan besaran skalar yang dikenal sebagai hasilkali dalam dari vektor-vektor tersebut.

Produk titik

Dalam matematika, produk titik atau produk skalar adalah operasi aljabar yang mengambil dua urutan angka yang sama panjang (biasanya vektor koordinat) dan menghasilkan satu angka.

Penolakan untuk meningkatkan terminologi dan konsistensi matematis dalam bahasa ini menurunkan motivasi. Tidak peduli berapa banyak fakta yang saya sajikan kepada Anda, tidak peduli berapa banyak contoh dan kasus penggunaan, tidak ada argumen tandingan selain "Saya baik-baik saja dengan titik".

@juliohm , terminologi adalah masalah konvensi, bukan kebenaran. Saya setuju bahwa dalam penggunaan formal untuk ruang Hilbert, terutama yang berdimensi tak terbatas, istilah "produk dalam" digunakan cukup banyak secara eksklusif. Tapi, seperti yang saya katakan, jika Anda google "fungsi produk titik" Anda akan menemukan banyak penggunaan informal dari terminologi itu juga. Jika Anda mengatakan "ambil produk titik dari dua elemen ruang Hilbert ini", setiap matematikawan akan tahu bahwa Anda mengacu pada produk dalam, bahkan untuk ruang dimensi tak terbatas, jadi tidak ada bahaya kebingungan yang nyata, karena tidak ada yang lain generalisasi standar dari istilah "produk titik". Itu sebabnya saya tidak menemukan perdebatan ejaan "titik" vs. "batin" sebagai isu sentral.

Penting untuk memutuskan semantik yang diinginkan di sini, dan kumpulan fungsi yang harus diimplementasikan oleh tipe jika mereka mendefinisikan ruang Hilbert atau ruang Banach baru. Saat ini, jika Anda ingin mendefinisikan tipe yang mewakili ruang Hilbert baru, Anda harus mendefinisikan dot dan norm (karena saat ini kami tidak memiliki fallback untuk yang terakhir), dan saya kira adjoint jika Anda ingin pemetaan ke objek ruang ganda.

Seperti yang dikatakan @Jutho , ini semua diperumit oleh kasus array-of-arrays, karena ada beberapa kemungkinan yang mungkin diinginkan seseorang di sana. Karena tidak ada nama standar untuk semua semantik yang mungkin, sulit untuk menemukan nama/semantik yang akan memuaskan semua orang. Lihat #25093 untuk diskusi tentang semantik vecdot . Saya sendiri tidak punya jawaban yang bagus di sini.

Beberapa kemungkinan di sini

1. Jumlah x[i]' * y[i] . Saat ini, ini adalah dot(x,y) . Bukan produk dalam untuk vektor matriks (di mana ia memberikan matriks), dan saat ini tidak didefinisikan semua untuk array multidimensi.
2. Jumlah dot(x[i], y[i]) , termasuk untuk array multidimensi, dan conj(x)*y untuk Number . Saat ini, ini adalah vecdot(x,y) .
3. Beberapa fungsi, misalnya inner(x,y) didefinisikan untuk selalu menjadi produk dalam yang sebenarnya, dan untuk array membuatnya menjumlahkan inner(x[i],y[i]) — pada dasarnya "vecdot rekursif" yang diinginkan @Jutho . Tetapi kemudian, untuk matriks A , hasil kali dalam ini tidak konsisten dengan norma induksi norm(A) yang merupakan definisi norm kita saat ini. Untuk memperbaikinya, kita harus mengubah norm(A) untuk matriks menjadi default ke norma Frobenius, yang berpotensi menjadi perubahan besar yang melanggar.

Sebuah pertanyaan (sebagian dibahas di #25093) adalah apakah kita memerlukan ketiganya di Pangkalan, atau apakah kita bisa lolos dengan dua (dan dua yang mana, dan kita menyebutnya apa). Usulan @Jutho , seperti yang saya pahami, pada dasarnya adalah untuk menghilangkan opsi 2 di Base dan kemudian menggunakan vecdot dan vecnorm untuk opsi 3. Kemudian kami memiliki produk dalam yang sebenarnya, tetapi terminologi agak unik untuk Julia, dan agak aneh untuk misalnya ruang Hilbert berdimensi tak terbatas. Itu tidak akan menjadi akhir dunia, tentu saja.

Kemungkinan lain (agak terlepas dari apa yang kita lakukan dengan vecdot ) adalah (kembali) meminta dot menjadi produk dalam yang sebenarnya. yaitu menghilangkan perilaku 1, dan membuat dot(x::AbstractVector, y::AbstractVector) sama dengan sum dot(x[i],y[i]) . Tetap tidak mendefinisikannya untuk array multidimensi (agar tetap konsisten dengan norm ).

Kecenderungan pribadi saya saat ini adalah untuk mendefinisikan dot menjadi produk dalam yang sebenarnya (yang harus konsisten dengan norm ), mengubahnya menjadi jumlah dot(x[i],y[i]) untuk vektor (yaitu mengubah kasus vektor-matriks), dan terus tidak mendefinisikannya untuk array multidimensi. Kemudian tentukan vecdot untuk memanggil vecdot secara rekursif seperti yang disarankan @Jutho , dengan fallback vecdot(x,y) = dot(x,y) . Terakhir, katakan bahwa tipe "Hilbert-space" baru harus mendefinisikan dot dan norm . Ini sepertinya perubahan yang paling tidak mengganggu, paling bisa dipahami bagi saya.

(Falback norm(x) = sqrt(real(dot(x,x))) juga dimungkinkan, meskipun agak berbahaya karena rentan terhadap fake overflow. Perhatikan bahwa kita tidak dapat menggunakan sqrt(dot(x,x)) sebagai fallback karena alasan teknis: kita ingin Real hasil, bukan Complex hasil.)

Terima kasih @stevenngj atas reaksi informatif ini. Hanya satu komentar kecil:

dengan mundur vecdot(x,y) = dot(x,y) . Terakhir, katakan bahwa tipe "Hilbert-space" baru harus mendefinisikan dot dan norm .

Ada dua masalah dengan itu. vecdot(x,y) = dot(x,y) fallback tidak dapat ada, karena vecdot sudah menerima argumen Any untuk menangani iterator umum. Masalah kedua adalah, jika dot dan norm diekspos menjadi produk dalam yang sebenarnya dan norma yang harus didefinisikan oleh setiap vektor seperti tipe pengguna, maka bahkan ketika menulis paket dengan misalnya metode Krylov yang harus bekerja dengan tipe seperti vektor yang sepenuhnya generik, itu masih tidak akan berfungsi untuk kasus di mana pengguna ingin menggunakan array bersarang atau multidimensi sebagai objek seperti vektor. Oleh karena itu, saya berpendapat bahwa vecdot dan vecnorm adalah produk dalam umum dan norma objek seperti vektor. Ini juga cocok dengan fakta bahwa untuk matriks, kebanyakan orang memang mengharapkan norm menjadi norma matriks/operator yang diinduksi.

Adapun kasus penggunaan aktual (untuk menunjukkan bahwa ini bukan kasus luar biasa). Matriks stokastik memiliki nilai eigen (Perron-Frobenius) terbesar yang vektor eigennya mewakili distribusi probabilitas titik tetap. Dalam generalisasi kuantumnya, distribusi probabilitas digeneralisasikan ke matriks definit positif (matriks kepadatan) dan matriks tersebut adalah titik tetap (vektor eigen yang sesuai dengan nilai eigen terbesar) dari peta yang sepenuhnya positif, yaitu peta rho -> sum(A[i] rho A[i]^\dagger for i = 1:N) dimana rho adalah matriks kepadatan dan A[i] adalah matriks untuk setiap i (dikenal sebagai operator Kraus yang mewakili peta yang benar-benar positif). Untuk dimensi matriks besar, metode Arnoldi sangat cocok untuk menemukan matriks kerapatan titik tetap.

Kecenderungan pribadi saya saat ini adalah mendefinisikan titik sebagai hasil kali dalam yang sebenarnya (yang harus konsisten dengan norma), mengubahnya menjadi jumlah titik(x[i],y[i]) untuk vektor. Terakhir, katakan bahwa tipe "Hilbert-space" baru harus mendefinisikan titik dan norma.

Itu sudah merupakan peningkatan besar. Mendokumentasikan dot untuk memiliki inner semantik di Base setidaknya akan memungkinkan pengguna untuk menentukan ruang mereka sendiri tanpa mengimpor perpustakaan yang tidak perlu. Saya tidak senang dengan penamaannya, tetapi setidaknya fungsionalitasnya akan tersedia bagi mereka yang membutuhkannya.

Ya, saya pikir akan menyenangkan untuk memiliki antarmuka yang terdokumentasi untuk diimplementasikan untuk tipe "Hilbert-space".

Tentu saja, memikirkan antarmuka umum untuk ruang vektor ini, jika menyertakan norm seperti yang disarankan di atas maka itu harus menjadi norma Frobenius untuk matriks (dan digeneralisasikan untuk array berdimensi lebih tinggi, karena semua array adalah elemen vektor ruang angkasa). Dalam hal ini kita memerlukan fungsi "norma operator" terpisah untuk matriks ( matnorm atau opnorm atau sesuatu, atau argumen kata kunci pada norm ...).

@andyferris , harap perhatikan komentar terakhir saya. norm dan dot tidak dapat menjadi antarmuka ruang umum Hilbert, karena mereka bahkan tidak bekerja pada objek seperti vektor di Julia seperti array dimensi lebih tinggi dan array bersarang. Oleh karena itu vecdot dan vecnorm adalah kandidat yang 'lebih baik' (dalam arti paling tidak melanggar) untuk ini.

Menghidupkan kembali topik ini, yang saya anggap cukup relevan dengan jenis matematika yang saya harapkan akan saya lakukan dengan bahasa dalam waktu dekat. Apakah ada konsensus tentang apa yang akan dilakukan untuk meningkatkan keumuman dan semantik produk dalam?

Berikut adalah bagian dari ontologi matematika pribadi saya tentang produk.
Jika itu bisa membantu untuk memoles ingatan/membawa konsensus

• produk titik ; sinonim : produk skalar
• produk dalam
• lintas produk
• produk tensor ; sinonim : produk luar
• produk irisan ; sinonim : produk eksterior
• produk cangkir
• produk rangkap tiga

Bonus: tidak ada referensi wikipedia

Pada titik ini, proposal @Jutho di #25093 tampaknya merupakan perubahan yang paling tidak mengganggu, meskipun terminologi vec* agak aneh bagi saya dalam konteks ini.

Saya setuju bahwa istilah vec* aneh. Itulah mengapa mengganti nama fungsi menjadi nama standar akan bermanfaat bagi semua pengguna.

Saya juga setuju bahwa istilah vec* aneh.

Saya setuju, sebagai alternatif dari vecdot kita dapat memperkenalkan metode baru inner , tetapi saya tidak tahu nama yang bagus untuk "mengganti" vecnorm . Sebenarnya, saya tidak menemukan vecnorm seburuk itu, norma vektor adalah istilah yang mapan dan eksplisit untuk operasi yang kita inginkan.

Masalah dasar di sini adalah dengan matriks dan array multidimensi, yang biasanya norm(A) tidak sesuai dengan produk dalam, serta dengan array array seperti yang dibahas di atas. Beberapa disambiguasi (misalnya vec* atau fro* ) diperlukan dalam kasus ini untuk menunjukkan produk dalam mana yang dimaksudkan.

Anda dapat memiliki fungsi inner yang defaultnya adalah vecdot , tetapi agak konyol memiliki dua nama untuk fungsi yang sama, dan masih ada masalah tentang apa yang harus disebut norma.

Saya juga menemukan nama vecdot aneh, pada kenyataannya, saya bahkan tidak tahu itu ada dan telah membuat fungsi saya sendiri untuk itu... disebut inner .

Pemahaman saya adalah bahwa kita dapat menghentikan vecdot yang aneh demi inner , dan memberikannya semantik produk dalam bagi pengguna untuk mengimplementasikan ruang mereka sendiri.

Mengenai norm , yang saya tidak tahu. Saya membuka edisi ini untuk membahas produk-produk dalaman, mungkin masalah lain akan sesuai untuk membahas keadaan norma di Base.

Saya kira kita dapat memiliki inner(x,y) dan innernorm(x) = sqrt(inner(x,x)) (dengan kasing khusus yang dioptimalkan untuk menghindari luapan) alih-alih vecdot dan vecnorm . innernorm sedikit tidak biasa tetapi konteksnya cukup jelas.

Acungan jempol untuk perubahan ini. Nama inner dan innernorm jelas dan konsisten dengan konsep. Saya berharap mereka bisa mencapai Julia v1.0.

inner dan innernorm tampaknya OK bagi saya.

Saya masih akan mengatakan bahwa, menurut pendapat saya, fungsi norm kami tidak terlalu cocok dengan fungsi generik Julia dan sistem pengiriman dan apa yang saya sebut "antarmuka yang jelas" di mana pengiriman tidak boleh dilakukan pilihan semantik, hanya pilihan implementasi. Saya pribadi lebih suka kita bisa mengatakan " norm mengembalikan norma elemen ruang vektor", di mana matriks dan operator linier masih merupakan elemen ruang vektor (Anda dapat menambahkannya dan mengalikannya dengan skalar) . Kita juga dapat memiliki misalnya " opnorm mengembalikan norma operator dari operator linier" (atau matnorm atau apa pun).

Saat ini kita memiliki " norm mengembalikan norma dari elemen ruang vektor, kecuali elemen tersebut juga merupakan operator linier, dalam hal ini kita akan memberikan norma operator sebagai gantinya". Saya pribadi merasa bahwa pengiriman seharusnya tidak mengejutkan.

Yaitu saya lebih suka satu fungsi yang selalu melakukan norma vektor dan fungsi lain yang selalu melakukan norma operator, dan tidak ada fungsi yang mencoba melakukan keduanya.

Lebih suka lagi @andyferris :+1: Norma khusus yang bukan norma yang diinduksi oleh produk dalam di ruang dapat memiliki nama yang lebih spesifik. Nama norm akan berarti persis norm(x) = sqrt(inner(x,x)) , dan dapat didefinisikan ulang sesuai kebutuhan untuk tipe pengguna.

Saya pribadi lebih suka kita bisa mengatakan " norm mengembalikan norma dari elemen ruang vektor"

Fungsi norm saat ini memenuhi definisi tersebut. Untuk matriks, ia menghitung norma (operator) yang diinduksi, yang merupakan norma yang benar-benar valid untuk ruang vektor . (Ruang vektor tidak harus memiliki produk dalam atau norma sama sekali.)

Anda mungkin agak bingung tentang definisi "norma" jika Anda berpikir bahwa norma operator bukan "norma ruang vektor".

Ini juga merupakan perbedaan yang berguna antara norm dan innernorm . Jika Anda mendefinisikan norm , saya akan mengatakan bahwa itu hanya menyiratkan bahwa Anda memiliki ruang Banach (atau setidaknya ruang vektor bernorma). Jika Anda mendefinisikan innernorm , itu menyiratkan bahwa Anda memiliki ruang Hilbert (atau setidaknya ruang hasil kali dalam) dan norma ini konsisten dengan inner .

Misalnya, integrasi numerik adaptif (ala quadgk) adalah sesuatu yang hanya membutuhkan ruang vektor bernorma, bukan ruang hasil kali dalam.

Tentu, maaf, saya mungkin agak terlalu tidak tepat dengan bahasa saya. Jelas ada banyak norma yang valid untuk ruang vektor, termasuk berbagai norma operator.

Saya kira apa yang saya maksud adalah bahwa mungkin saya lebih suka pilihan norma mana yang lebih eksplisit daripada implisit? Dan jika Anda menggunakan fungsi yang sama (tanpa misalnya argumen kata kunci tambahan), Anda mendapatkan norma "sama", dalam hal ini Euclidean tampaknya merupakan pilihan yang dapat dipertahankan untuk AbstractArray .

Ini juga merupakan perbedaan yang berguna antara norm dan innernorm . Jika Anda mendefinisikan norma, saya akan mengatakan bahwa itu hanya menyiratkan bahwa Anda memiliki ruang Banach (atau setidaknya ruang vektor bernorma). Jika Anda mendefinisikan innernorm , itu menyiratkan bahwa Anda memiliki ruang Hilbert (atau setidaknya ruang produk dalam) dan norma ini konsisten dengan inner .

Ini tampaknya masuk akal, tetapi saya masih bertanya-tanya mengapa jika suatu objek memiliki innernorm itu akan membutuhkan norm yang berbeda ? Sebagai alternatif, saya akan mengusulkan bahwa antarmuka untuk ruang Banach membutuhkan norm sementara antarmuka untuk ruang produk dalam akan menyediakan norm dan inner . Fungsi-fungsi ini kemudian dapat digunakan dalam kode generik yang mengharapkan objek Banach atau ruang produk dalam sebagaimana mestinya (EDIT: dengan pemikiran bahwa kode yang berfungsi di ruang Banach secara otomatis juga akan bekerja pada ruang produk dalam).

Saya pikir Anda mengusulkan bahwa norm(x) selalu mengacu pada semacam norma Euclidean berdasarkan elemen (yaitu norma Frobenius untuk matriks), yaitu pada dasarnya apa vecnorm sekarang modulo kasus rekursif. Dalam hal ini kita mungkin juga mendefinisikan ulang dot(x,y) menjadi produk dalam yang sesuai ( inner bekerja juga, tetapi dot memiliki keuntungan dari varian infix x ⋅ y ).

Saya baik-baik saja dengan ini pada prinsipnya, tetapi ini akan menjadi perubahan besar dan mungkin akan sedikit terlambat sebelum 0,7 untuk memasukkannya…

Apakah L2 standar yang baik dalam dimensi tinggi juga?
Artikel ini berbicara tentang jarak, tetapi mungkin juga menyangkut norma
https://stats.stackexchange.com/questions/99171/why-is-euclidean-distance-not-a-good-metric-in-high-dimensions

Dalam hal ini kita mungkin juga mendefinisikan ulang titik(x,y) menjadi hasilkali dalam yang sesuai (kerja dalam juga, tetapi titik memiliki keuntungan dari varian infiks x y)

Bisakah kita menyingkirkan dot seluruhnya? Notasi infiks harus tidak terkait dengan keberadaan fungsi yang disebut dot . Cukup tentukan infix dengan metode inner untuk array Julia. Apakah itu mungkin?

Itulah yang sebenarnya, produk titik: notasi yang sesuai x y untuk produk dalam antara vektor x dan y dalam R^n dengan geometri Euclidean.

@stevengj Saya pikir itu ringkasan yang bagus, ya.

@ o314 Apakah L2 default yang bagus dalam dimensi tinggi? Mungkin tidak, tetapi saya akan sangat membencinya jika misalnya norma yang dipilih oleh norm(v::AbstractVector) bergantung pada length(v) :) Saya juga tidak suka menebak-nebak apakah matriks saya atau array berdimensi lebih tinggi adalah "terlalu besar untuk L2" - Saya menyarankan bahwa mungkin ini harus secara eksplisit ditandai oleh pengguna?

@juliohm Itu pasti mungkin, meskipun seperti yang disebutkan, ini melanggar perubahan yang kami sarankan. (Sekali lagi, modulo apa yang harus dilakukan dalam kasus rekursif dan diskusi sebelumnya tentang kemungkinan perbedaan antara inner dan dot ).

@stevenngj , interpretasi saya tentang apa yang disiratkan oleh @andyferris adalah, karena pengetikan bebek, sulit untuk memutuskan apakah pengguna ingin menafsirkan objek sebagai vektor (dan menggunakan vektor yang sesuai p -norm) atau sebagai operator (dan hitung p -norma yang diinduksi). Jadi saya pikir tidak ada pilihan selain menentukan secara eksplisit perilaku apa yang diinginkan. Pendekatan saat ini agak aneh dalam arti bahwa norm mencoba menebak secara implisit apakah akan memilih norma vektor atau norma terinduksi berdasarkan input, dan vecnorm adalah cara untuk secara eksplisit menentukan yang Anda inginkan norma vektor (yang juga mengapa saya tidak menemukan vecnorm nama yang buruk). Perubahan yang lebih radikal adalah membuat norm selalu default ke norma vektor, dan menentukan secara eksplisit kapan Anda menginginkan norma yang diinduksi, menggunakan argumen (kata kunci) atau fungsi yang berbeda sama sekali.

Di sisi lain, saya juga tidak keberatan dengan nama innernorm , yang secara eksplisit menyatakan bahwa ini adalah norma berbasis produk dalam (yaitu selalu p=2 dalam kasus Euclidean). Saya merasa sulit untuk menilai apakah objek kustom (vec)norm harus mendukung argumen opsional p sebagai bagian dari antarmuka, karena dalam beberapa kasus penggunaan saya, hanya p=2 yang mudah untuk menghitung.

Itulah yang sebenarnya, produk titik: notasi yang sesuai x y untuk produk dalam antara vektor x dan y dalam R^n dengan geometri Euclidean.

Saya setuju dengan ini, dalam arti bahwa saya tidak ingat pernah melihat notasi x ⋅ y dalam konteks ruang vektor umum (misalnya kompleks). Saya pikir hanya notasi matematika (x,y) atau notasi Dirac < x | y > yang digunakan dalam kasus seperti itu. Dalam elektromagnetisme seseorang sering menggunakan E ⋅ B untuk vektor dalam ruang Euclidean 3-dimensi, dan bahkan jika seseorang menggunakan notasi kompleks (yaitu fasor) ini tidak menyiratkan konjugasi kompleks. Jika diperlukan, konjugasi kompleks dilambangkan secara eksplisit dalam kasus tersebut. Jadi saya tidak keberatan jika dot hanya menjadi sum(x_i * y_i) tanpa kompleks atau konjugasi Hermitian, dan inner menjadi produk dalam yang benar untuk ruang hasil kali dalam umum. Sayangnya, ini mungkin tidak dapat dilakukan dalam satu siklus rilis.

Apakah L2 default yang baik dalam dimensi tinggi? Mungkin tidak, tapi saya akan sangat membencinya jika misalnya norma yang dipilih oleh norma(v::AbstractVector) bergantung pada panjang(v) :) Saya juga tidak suka menebak-nebak apakah matriks saya atau array dimensi lebih tinggi adalah "terlalu besar untuk L2" - Saya menyarankan bahwa mungkin ini harus secara eksplisit ditandai oleh pengguna?

Saya bekerja di dunia BIM di mana kami menangani 2d dan 3d, tetapi juga 4d, 5d, 6d mungkin 7d. Kami tidak pernah melangkah lebih jauh. Pada titik mana pun kita tahu di dimensi mana kita bekerja, dan algo mana yang terlibat. Itu sudah cukup.

Saya tidak bisa mengungkapkan pov orang yang bekerja di ML, pencarian informasi dll. Ada, mungkin norminf lebih baik. Yang penting dalam pov saya adalah menebak dan stabilitas. Saya tidak akan terkejut sama sekali jika orang-orang di ML membutuhkan default yang berbeda untuk barang-barang mereka. Jika tidak ada kebingungan. Misalnya. diputuskan secara eksplisit dan statis pada waktu kompilasi. Bahkan mewah jika tetap stabil dan konsisten selama aplikasi algos.

Terinspirasi dari array:similar Tidak sepenuhnya diimplementasikan dan diuji.

norm2 = x -> x |> inner |> sqrt
norminf = ...
NMAX = 10
for N in 1:NMAX
    <strong i="13">@eval</strong> begin norm(a::Array{T,N}) where {T} = norm2 end
end
norm(a::Array{T,n}) where {T} = norminf

Bisakah kita menghilangkan titik sepenuhnya? Notasi infiks seharusnya tidak berhubungan dengan keberadaan fungsi yang disebut titik. Cukup tentukan infiks dengan metode dalam untuk array Julia. Apakah itu mungkin?

norm(x::AbstractVector, p::Real=2) = vecnorm(x, p) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L498
vecdot(x::Number, y::Number) = conj(x) * y # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L657
dot(x::Number, y::Number) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L659
function dot(x::AbstractVector, y::AbstractVector) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L677

# Call optimized BLAS methods for vectors of numbers
dot(x::AbstractVector{<:Number}, y::AbstractVector{<:Number}) = vecdot(x, y) # https://github.com/JuliaLang/julia/blob/master/stdlib/LinearAlgebra/src/generic.jl#L698

Dot / vecdot menyiratkan untuk menggunakan konjugasi dan memutuskan kapan harus pergi ke BLAS. ini harus ditangani di suatu tempat. Tetapi ini harus dapat dikelola dalam satu namespace.

Apakah L2 default yang baik dalam dimensi tinggi? Mungkin tidak

L2 juga merupakan norma yang paling umum untuk ruang dimensi tak hingga (misalnya fungsi). Saya pikir ini adalah standar yang masuk akal untuk diharapkan untuk ruang vektor apa pun.

Jelas Anda ingin memiliki norma lain yang tersedia juga. Jika kita mendefinisikan ulang norm(x) menjadi elemen L2 sedapat mungkin, maka norm(x, p) akan menjadi elemen Lₚ, dan kita memerlukan beberapa fungsi lain (misalnya opnorm ) untuk induksi/ yang sesuai norma operator.

Saya setuju dengan ini, dalam arti bahwa saya tidak ingat pernah melihat notasi x ⋅ y dalam konteks ruang vektor umum (misalnya kompleks).

Saya memberikan beberapa kutipan di utas lain, IIRC (misalnya BLAS menggunakan dot untuk produk titik kompleks, dan Anda dapat menemukan sumber pedagogis bahkan menggunakan istilah untuk produk dalam fungsi). Istilah "produk dalam" biasanya memperkenalkan "generalisasi produk titik". Saya tidak berpikir siapa pun akan terlalu terkejut dengan notasi dot untuk produk dalam Euclidean, dan lebih mudah untuk memiliki operator infiks.

Kita dapat mempertahankan dot apa adanya dan memperkenalkan inner , tentu saja, tetapi saya pikir itu akan menciptakan dikotomi yang membingungkan — dalam kasus yang paling umum, fungsinya akan setara, tetapi dalam kasus yang aneh (misalnya array matriks) mereka akan berbeda.

Tetapi sekali lagi, mungkin akan sedikit terlambat untuk melanggar perubahan, jadi kita mungkin harus menggunakan innernorm dan inner . Bagaimanapun, seseorang perlu membuat PR ASAP.

Jika ukuran konsensus yang wajar terbentuk, saya mungkin dapat mencurahkan sebagian bandwidth untuk mengeksplorasi implementasi pada skala waktu yang relevan (pendek), termasuk perubahan yang berpotensi melanggar. Saya menghargai dorongan untuk mengklarifikasi semantik operasi ini dan memberi mereka nama eksplisit. Terbaik!

Saya melihat dua opsi utama:

• Tidak melanggar, menambahkan fitur: inner(x,y) dan innernorm(x) . Mengganti vecdot dan vecnorm , dan rekursif untuk array array.

• Breaking: ubah norm(x,p=2) menjadi selalu elemen dan rekursif, ganti vecnorm , dan perkenalkan fungsi baru opnorm untuk operator/norma yang diinduksi. Jadikan dot(x,y) produk titik elemen yang sesuai, menggantikan vecdot . (Alternatif: ganti nama menjadi inner , tetapi menyenangkan memiliki operator infix, dan memiliki keduanya dot dan inner .)

Jika saya mendesain sesuatu dari awal, saya lebih suka 2, tetapi mungkin terlalu mengganggu untuk secara diam-diam mengubah arti norm .

Salah satu opsi perantara adalah mendefinisikan inner dan innernorm (menghentikan vecdot dan vecnorm ), dan menghentikan norm(matrix) menjadi opnorm . Kemudian, di 1.0, perkenalkan kembali norm(matrix) = innernorm(matrix) . Dengan begitu, orang pada akhirnya dapat menggunakan inner dan norm , dan kita meninggalkan dot sebagai binatang aneh saat ini untuk vectors-of-arrays (bertepatan dengan inner untuk vektor angka).

Satu keanehan tentang innernorm adalah Anda menginginkan cara untuk menentukan norma "elementwise" L1 atau Linf, tetapi tidak satu pun dari ini yang sesuai dengan produk dalam sehingga innernorm(x,p) sedikit keliru.

Saya suka opsi perantara Anda.

Seperti yang dinyatakan di atas, saya suka nama innernorm(x) karena itu menyiratkan p=2 dan tidak boleh ada argumen kedua. Saya memiliki objek yang hanya saya ketahui cara menghitung norma hasil kali dalam. Tetapi dengan (vec)norm saat ini, tidak jelas bagi saya apakah argumen p adalah bagian dari antarmuka Base yang diasumsikan, jadi saya tidak tahu apakah akan menghilangkan argumen kedua, atau mendukung itu tetapi kemudian periksa secara eksplisit untuk p != 2 dan menghasilkan kesalahan.

Tapi saya melihat masalah dengan tidak memiliki cara yang tidak digunakan untuk melakukan vecnorm(matrix, p!=2) selama tahap peralihan proposal Anda.

Saya juga menyukai opsi perantara - kami pasti ingin melalui siklus penghentian yang tepat untuk norma daripada membuat perubahan langsung. (Sebagai pengguna, perubahan yang melanggar membuat saya takut, tetapi saya melihat perbaikan penghentian dalam kode saya untuk v1.0 seperti investasi dalam kode yang bersih dan jelas untuk masa depan).

Apakah kita benar-benar membutuhkan innernorm atau bisakah kita menggunakan vecnorm untuk saat ini (dan tidak menggunakan vecnorm untuk norm nanti)?

Saya sebenarnya tidak melihat potensi keributan hanya dengan mengganti dot dengan inner ... Saya juga berpikir cukup jelas bahwa produk dalam dimaksudkan untuk menjadi generalisasi dari produk titik.

Perubahan dapat diimplementasikan dalam dua PR terpisah:

1. Ganti dot dengan inner dan berikan arti umum. Secara opsional, buat notasi infix \cdot menunjuk ke bagian dalam antara array Julia.
2. Lebih banyak diskusi dan siklus penghentian seputar varian norma dan terminologi.

Pemahaman saya adalah bahwa PR 1 dapat digabungkan sebelum Julia v1.0. Hal ini tidak melanggar.

Mengganti dot dengan inner masih akan melanggar karena dot saat ini bukan produk dalam yang sebenarnya untuk array dari array — jadi Anda akan mengubah artinya, bukan hanya mengganti nama. Saya ingin mengubah artinya menjadi produk dalam yang sebenarnya, tetapi jika Anda mengubah artinya (mendefinisikannya sebagai produk dalam yang sebenarnya) saya tidak melihat masalah untuk melanjutkan mengejanya sebagai dot .

Jadi, kita bisa melakukan hal berikut di 0.7:

1. Menghentikan norm(matrix) menjadi opnorm(matrix) dan norm(vector of vectors) menjadi vecnorm .
2. Menghentikan dot([vector of arrays], [vector of arrays]) untuk panggilan ke sum .
3. Katakan bahwa vecdot(x,y) dan vecnorm(x, p=2) adalah produk/norma dalam Euclidean (untuk p=2 ), dan buat mereka rekursif (yang sedikit melanggar, tetapi dalam praktiknya mungkin bukan masalah besar) .

Kemudian, dalam 1.0:

1. Menghentikan vecnorm menjadi norm dan vecdot menjadi dot . (Tidak yakin apakah ini diizinkan oleh aturan rilis 1.0, @StefanKarpinski?)

(Perhatikan bahwa fungsi numpy.inner , luar biasa, tidak selalu merupakan produk dalam. Tapi terminologi NumPy pada inner dan dot telah aneh untuk sementara waktu.)

Alasan saya lebih suka melanjutkan mengejanya sebagai dot :

• Itu bagus untuk memiliki ejaan infiks.
• Untuk non-matematika yang beroperasi pada ruang vektor berdimensi hingga biasa, dot adalah nama yang lebih familiar untuk produk dalam Euclidean. (Para matematikawan akan dengan mudah menyesuaikan diri untuk menggunakan nama dot untuk fungsi hasilkali-dalam pada ruang Hilbert arbitrer—"perkalian titik" tidak memiliki arti lain yang mungkin untuk ruang seperti itu.)
• Memiliki inner dan dot akan membingungkan, karena keduanya akan bertepatan dalam beberapa kasus tetapi mungkin tidak pada kasus lain (jika kita mempertahankan arti dot saat ini).
• Di luar aljabar linier, inner memiliki banyak arti potensial lain dalam ilmu komputer, dan karenanya agak mengganggu untuk mengekspor nama ini dari Base.

Bisakah Anda menguraikan penentangan Anda terhadap nama batin? Saya masih tidak mengerti
itu sebabnya Anda lebih suka menentang terminologi yang tampaknya semua orang di utas ini
menyetujui?

Pada Selasa, 15 Mei 2018, 05:13 Steven G. Johnson [email protected]
menulis:

(Perhatikan bahwa numpy.inner
https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.inner.html
fungsi, luar biasa, tidak selalu merupakan produk dalam.)

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/JuliaLang/julia/issues/25565#issuecomment-389144575 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ADMLbdcpeWo7M4prYz76NoqUPIkfVPP3ks5tysZlgaJpZM4ReGXu
.

Tidak ada alasan yang menarik bagi saya:

>

• Sangat menyenangkan memiliki varian infix.

Ya, dan notasi infiks tetap ada terlepas dari rename menjadi
batin seperti yang dijelaskan di atas.

>

• Untuk non-matematikawan yang beroperasi pada dimensi hingga biasa
  ruang vektor, titik adalah nama yang lebih akrab untuk bagian dalam Euclidean
  produk. (Matematikawan akan dengan mudah menyesuaikan diri dengan menggunakan nama titik untuk
  fungsi hasilkali-dalam pada ruang Hilbert arbitrer—"perkalian titik" tidak memiliki
  kemungkinan arti lain untuk ruang tersebut.)

Argumen ini tidak baik: mari kita ajari orang biasa yang salah
terminologi karena mereka malas dan tidak dapat mempelajari kata baru yang sesuai,
dan memaksa matematikawan untuk menggunakan terminologi yang salah yang bertentangan dengan keinginan mereka.

>

• Memiliki bagian dalam dan titik akan membingungkan, karena mereka akan
  bertepatan dalam beberapa kasus tetapi mungkin tidak yang lain (jika kita mempertahankan titik saat ini
  berarti).

Kami tidak membutuhkan keduanya, singkirkan nama yang kurang umum, yang kami setujui adalah
titik pada titik ini.

>

• Di luar aljabar linier, bagian dalam memiliki banyak potensi lainnya
  makna dalam ilmu komputer, dan karenanya agak mengganggu untuk
  ekspor nama ini dari Base.

Di luar aljabar linier saya dapat menemukan banyak kegunaan titik. Terlebih lagi untuk
notasi titik infiks berarti hal yang sama sekali berbeda.

>

Saya memposting ulang posting terakhir @juliohm dengan format tetap.

Tidak ada alasan yang menarik bagi saya:

Sangat menyenangkan memiliki varian infix.

Ya, dan notasi infiks masih bisa ada terlepas dari rename menjadi inner seperti yang dijelaskan di atas.

Untuk non-matematikawan yang beroperasi pada ruang vektor berdimensi hingga biasa, titik adalah nama yang lebih dikenal untuk produk dalam Euclidean. (Para matematikawan akan dengan mudah menyesuaikan diri untuk menggunakan nama titik untuk fungsi hasilkali-dalam pada ruang Hilbert yang berubah-ubah—"produk titik" tidak memiliki arti lain yang mungkin untuk ruang seperti itu.)

Argumen ini tidak baik: mari kita ajari orang awam istilah yang salah karena mereka malas dan tidak bisa mempelajari kata baru yang sesuai, dan memaksa matematikawan untuk menggunakan istilah yang salah di luar kehendak mereka.

Memiliki bagian dalam dan titik akan membingungkan, karena mereka akan bertepatan dalam beberapa kasus tetapi mungkin tidak dalam kasus lain (jika kita mempertahankan makna titik saat ini).

Kami tidak membutuhkan keduanya, singkirkan nama yang kurang umum, yang kami setujui adalah titik pada saat ini.

Di luar aljabar linier, inner memiliki banyak arti potensial lain dalam ilmu komputer, dan karenanya agak mengganggu untuk mengekspor nama ini dari Basis.

Di luar aljabar linier saya dapat menemukan banyak kegunaan titik. Terlebih lagi untuk notasi titik infiks yang berarti hal yang sama sekali berbeda.

Ya, dan notasi infiks masih bisa ada terlepas dari rename menjadi inner seperti yang dijelaskan di atas.

Anda tentu dapat mendefinisikan const ⋅ = inner , tetapi terminologi Anda tidak konsisten. Saya pikir Anda tidak suka menggunakan "produk titik" sebagai produk dalam umum?

memaksa matematikawan untuk menggunakan terminologi yang salah bertentangan dengan keinginan mereka

Matematikawan tahu bahwa terminologi tidak benar atau salah, itu hanya konvensional atau tidak konvensional (dan mungkin konsisten atau tidak konsisten). (Dan kebanyakan orang tidak masuk ke matematika karena mereka memiliki hasrat untuk ejaan preskriptif.) Dalam pengalaman saya, jika Anda memberi tahu ahli matematika bahwa dalam mekanika kuantum, sebuah vektor disebut "keadaan", adjointnya disebut "belati", dan vektor ganda disebut "bra", mereka sama sekali tidak peduli. Demikian pula, saya tidak berpikir ahli matematika berpengalaman akan berkedip lebih dari sekali jika Anda memberi tahu mereka bahwa di Julia produk dalam dieja dot(x,y) atau x ⋅ y , terutama karena istilahnya sudah dipahami sinonim dalam banyak konteks. (Saya ragu Anda akan menemukan ahli matematika yang tidak langsung tahu bahwa Anda mengacu pada produk dalam jika Anda mengatakan "ambil produk titik dari dua fungsi dalam ruang fungsi ini".)

Di sisi lain, untuk orang-orang yang bukan ahli matematika terlatih dan belum pernah terpapar ke ruang produk dalam yang abstrak (yaitu sebagian besar pengguna), pengalaman saya adalah bahwa istilah asing lebih merupakan hambatan. "Bagaimana cara mengambil produk titik dari dua vektor di Julia?" akan menjadi FAQ.

Sebenarnya tidak ada kesulitan matematika di sini yang harus dipecahkan selain memilih semantik. Pertanyaan ejaan adalah murni salah satu kenyamanan dan penggunaan.

Di luar aljabar linier saya dapat menemukan banyak kegunaan titik. Terlebih lagi untuk notasi titik infiks yang berarti hal yang sama sekali berbeda.

Kecuali bahwa Julia dan banyak bahasa pemrograman lainnya telah memiliki dot selama bertahun-tahun dan itu tidak menjadi masalah. inner akan menjadi kerusakan baru.

Pada akhirnya, ejaan fungsi ini (atau lainnya) adalah masalah kecil dibandingkan dengan semantik dan jalur penghentian, tapi saya pikir tips keseimbangan mendukung dot .

Anda tentu dapat mendefinisikan const = inner, tetapi terminologi Anda tidak konsisten. Saya pikir Anda tidak suka menggunakan "produk titik" sebagai produk dalam umum?

Saya pikir Anda masih tidak mengerti. Tidak ada inkonsistensi dalam menyebut titik sebagai produk dalam. Ini adalah produk batin, yang sangat spesifik dan tidak berguna bagi banyak dari kita. Tidak lebih dari sum(x.*y) .

Jika istilah dot berakhir di Julia memiliki semantik inner , ini akan menjadi bencana sejarah yang saya jamin kepada Anda banyak yang akan merasa kesal. Saya dapat meramalkan profesor di ruang kelas menjelaskan hal-hal seperti: "Anda tahu, kita sekarang akan mendefinisikan produk dalam untuk ruang kita, tetapi di Julia seseorang (@stevenngj) memutuskan untuk menyebutnya titik."

Saya akan memastikan saya akan screenshot utas ini untuk referensi di masa mendatang jika itu akhirnya terjadi.

Anda adalah satu-satunya @stevenngj yang bersikeras pada terminologi dot , tidak ada orang lain yang menentangnya. Alangkah baiknya jika Anda dapat mempertimbangkan kembali fakta ini sebelum mengambil keputusan.

Ini adalah produk batin, yang sangat spesifik dan tidak berguna bagi banyak dari kita. Tidak lebih dari jumlah(x.*y).

Jika Anda berpikir "produk titik" hanya dapat merujuk ke produk dalam Euclidean di , maka Anda tidak boleh mendefinisikan const ⋅ = inner , Anda harus mendefinisikan hanya ⋅(x::AbstractVector{<:Real}, y::AbstractVector{<:Real}) = inner(x,y) .

Anda tidak dapat memiliki keduanya: inner dapat menggunakan ⋅ sebagai sinonim infiks (dalam hal ini operator infiks keduanya "salah" dalam bahasa Anda dan penamaannya tidak konsisten) atau itu tidak memiliki sinonim infiks (kecuali dalam satu kasus khusus).

Saya dapat meramalkan profesor di ruang kelas menjelaskan hal-hal seperti: "Anda tahu, kita sekarang akan mendefinisikan produk dalam untuk ruang kita, tetapi di Julia seseorang (@stevenngj) memutuskan untuk menyebutnya titik."

Ha ha, saya bersedia menerima panas dari profesor imajiner yang marah ini. Serius, Anda perlu melihat-lihat lebih jauh jika Anda berpikir istilah "perkalian titik" hanya pernah digunakan di , atau matematikawan marah jika istilah itu digunakan di ruang Hilbert lainnya.

ini akan menjadi bencana sejarah

Dengan serius?

Diskusi ini tampaknya terkikis melampaui apa yang mungkin dianggap sebagai lingkungan yang ramah, beradab, dan konstruktif . Pendapat dan latar belakang berbeda, tapi tolong jangan membuat serangan pribadi atau menyalahkan siapa pun dan menganggap semua pihak berdebat dengan itikad baik.

Saya dapat meramalkan profesor di ruang kelas menjelaskan hal-hal seperti: "Anda tahu, kita sekarang akan mendefinisikan produk dalam untuk ruang kita, tetapi di Julia seseorang (@stevenngj) memutuskan untuk menyebutnya titik."

Mungkin juga bermanfaat di sini untuk dicatat bahwa Steven _adalah_ seorang profesor. :mengedip:

Saya juga ragu untuk menghapus dot demi inner . Istilah dot cukup banyak digunakan, dan tidak memiliki fungsi di Julia, ketika dalam Python dan MATLAB akan mengejutkan. Namun, saya juga menyukai istilah inner , karena lebih sesuai untuk ruang vektor non-ℝⁿ, dan terutama matriks.

Kebetulan, ketika saya menguji metode apa yang dilakukan di Julia, saya perhatikan bahwa dot hanya berfungsi pada vektor/matriks nyata. Apakah itu disengaja?

Memiliki bagian dalam dan titik akan membingungkan, karena mereka akan bertepatan dalam beberapa kasus tetapi mungkin tidak dalam kasus lain (jika kita mempertahankan makna titik saat ini).

@stevenngj Apakah benar-benar konyol untuk mengganti vecdot dengan inner , dan juga menyimpan dot ? Saat ini, masalah persis yang Anda gambarkan sudah ada, hanya dengan vecdot alih-alih inner .

Oke... di tunggu, apa saran livenya? Apakah mereka untuk:

• Rangkul dot sebagai produk dalam umum untuk jenis yang lebih luas. Ini sudah rekursif dengan benar pada vektor-vektor, tetapi kami akan membuatnya bekerja pada matriks, dll ( @jebej Saya tidak merasa memiliki dot dan inner berguna, dan sebagai Steven mengatakan, kami paling tidak menggunakan bahasa sehari-hari dot untuk mengartikan produk dalam cukup sering, dan ini tidak salah - itu hanya terminologi).
• Pertimbangkan untuk membuat norm sedikit lebih konsisten dengan dot di atas dan di semua AbstractArray , akhirnya memperkenalkan misalnya opnorm untuk norma operator (pada AbstractMatrix ) dan memiliki (dalam notasi baru ke lama) norm(matrix) == vecnorm(matrix) setelah penghentian yang sesuai. Pada titik ini mungkin kita tidak membutuhkan vecdot dan vecnorm lagi?

Apakah itu benar? Saya pikir ini setidaknya akan membawa kita ke cerita aljabar linier yang relatif konsisten dengan antarmuka "bersih", di mana kode generik dapat menggunakan dot dan norm sebagai pasangan yang andal untuk bekerja dengan ruang produk dalam independen dari jenis.

@andyferris , ya, saya pikir jika kita membuat perubahan ini maka kita hanya perlu dot dan norm (yang sekarang merupakan operasi Euclidean rekursif pada array atau array-of-array dari dimensi apa pun, meskipun untuk norm kita juga mendefinisikan norm(x,p) menjadi p-norm) dan opnorm , dan tidak lagi memiliki vecdot atau vecnorm .

Perhatikan bahwa perubahan ke dot adalah perubahan yang melanggar karena dot saat ini bukan hasil kali dalam yang sebenarnya untuk vektor matriks (#22392), sesuatu yang telah lama diperdebatkan di #22220 ( di mana menghilangkan vecdot tidak dianggap IIRC). Namun, itu diperkenalkan di 0,7, sehingga tidak merusak kode rilis yang sebenarnya. Faktanya, dot dalam 0,6 sudah merupakan produk titik Euclidean pada array dimensi arbitrer, agak secara tidak sengaja (#22374). Perubahan yang disarankan di sini akan memulihkan dan memperluas perilaku 0.6 itu dan mengubah norm agar konsisten dengannya.

Satu pertanyaan adalah apakah norm(x,p) akan memanggil norm(x[i]) atau norm(x[i],p) secara rekursif. Keduanya berpotensi menjadi perilaku yang berguna. Saya condong ke yang pertama karena lebih umum — x[i] mungkin merupakan ruang vektor bernorma arbitrer yang hanya mendefinisikan norm tetapi bukan p-norma. Memanggil norm secara rekursif juga dilakukan oleh vecnorm sekarang, jadi ini konsisten dengan penghentian vecnorm ke norm .

@jebej , dot pada master dan 0.6 bekerja untuk saya pada array yang kompleks: dot([3im],[4im]) dengan benar mengembalikan 12+0im , misalnya.

Poin bagus lainnya tentang mengubah norm(matrix) menjadi norma Frobenius adalah jauh lebih murah. Adalah umum untuk hanya menggunakan norm(A-B) untuk mengetahui seberapa besar perbedaan antara dua matriks, tetapi tidak terlalu peduli dengan pilihan norma tertentu, tetapi banyak pengguna tidak akan menyadari bahwa default saat ini norm(matrix) mengharuskan kita untuk menghitung SVD.

Luar biasa melihat konsensus terbentuk di sekitar beberapa poin utama! :) (Kecuali seseorang mengalahkan saya untuk itu (silakan lakukan jika Anda memiliki bandwidth!) atau tag alfa telah mencapai sebelumnya, saya akan mencoba menerapkan poin konsensus saat ini setelah pengiriman #26997.) Terbaik!

Tautan lain untuk referensi di masa mendatang: https://math.stackexchange.com/a/476742

Untuk mengilustrasikan nama buruk yang diadopsi di sini secara sadar , dan keputusan buruk yang dipaksakan oleh satu pikiran. Hasil kali titik dan dalam memiliki sifat matematika yang berbeda. Anda memaksa seluruh komunitas menentang apa yang terkenal dalam literatur matematika.

Dan untuk pembaca masa depan, apa yang seharusnya dilakukan jika kita memiliki keputusan bersama:

# make dot what it is, a NOTATION
⋅(x::AbstractVector, y::AbstractVector) = sum(x[i]*y[i] for i in indices(x))

# replace the name dot by the more general inner
inner(x, y) = # anything

Saya kira kita hanya akan menjadi orang pertama di alam semesta yang menggunakan istilah " produk titik" untuk produk dalam pada apa pun selain . Untung saya bisa memaksakan kehendak saya di utas ini (terutama dengan memeras pengembang lain) untuk memaksa inovasi ini ke dunia! Produk titik tidak lagi akan diturunkan menjadi "notasi" belaka: sebaliknya, itu akan menjadi simbol yang berarti produk dalam (seperti yang harus diketahui semua orang, memberi makna pada simbol adalah kebalikan dari "notasi").

Pengambilan keputusan yang sangat baik :clap: itu pasti konsensus. Baca komentar di atas, dan Anda akan melihat bagaimana semua orang setuju. :+1:

Atau mungkin saya harus mengutip beberapa komentar sehingga sangat jelas bagaimana konsensus itu:

>

Benar - vecdot bisa diganti namanya menjadi inner

oleh @andyferris

Opsi 2 (mungkin lebih baik): gunakan nama yang lebih benar secara matematis

batin
dimensi
Tapi apa yang harus dilakukan dengan norma?

oleh @Jutho

Saya setuju, sebagai alternatif dari vecdot, kami dapat memperkenalkan metode baru dalam

oleh @Jutho

Saya juga menemukan nama vecdot aneh, pada kenyataannya, saya bahkan tidak tahu itu ada dan telah membuat fungsi saya sendiri untuk itu ... disebut inner.

oleh @jebej

Dan masih banyak lagi...

Orang dapat berdebat dengan keras satu sama lain, dan mengangkat banyak poin ketidaksepakatan, tetapi tetap mencapai konsensus (walaupun tidak selalu bulat) dengan dibujuk dan dengan menyeimbangkan pro/kontra. (Saya setuju bahwa ada pro dan kontra dari setiap opsi di sini.) Maaf bahwa hasil yang tampaknya (sementara!) menjadi gel di sini bukanlah hasil yang Anda inginkan, tetapi saya tidak yakin bagaimana menurut Anda Saya "memaksakan" keinginan saya.

(Tentu saja tidak ada keputusan akhir yang dibuat — bahkan belum ada PR, apalagi yang digabung.)

Saya hanya berharap kita bisa membuat keputusan yang didasarkan pada audiens bahasa. Jika seseorang memilih Julia sebagai alat, saya yakin orang tersebut setidaknya pernah mendengar istilah produk inner . Ini adalah konsep yang cukup populer dan jauh dari eksotik. Hal-hal eksotis termasuk "homologi persisten", "teori kuantum", ini kurang tersebar luas, dan saya akan menentang memasukkan jenis terminologi ini.

Lagi pula saya hanya ingin memiliki bahasa yang merupakan bahasa terbaik untuk komputasi ilmiah, matematika, dll.

@juliohm , semua argumen didasarkan pada kebutuhan audiens yang kami pikir, dan kami semua berusaha membuat bahasa Julia sebaik mungkin. Orang yang berakal bisa sampai pada kesimpulan yang berbeda tentang terminologi, karena matematika tidak menentukan ejaan.

Pertama, seperti yang disebutkan di atas, saya pasti bisa setuju dengan proposal @stevenngj saat ini dan tetap berpegang pada dot sebagai nama umum untuk produk dalam. Juga, saya tidak suka cara diskusi ini berjalan dan tentu saja ingin dikutip dengan benar. @juliohm , kutipan kedua yang Anda atributkan kepada saya bukan milik saya.

Karena itu, saya ingin menyebutkan hal-hal berikut sebagai bahan pemikiran dalam pertimbangan pro dan kontra. Berikut ini sebagian besar kontra, tetapi saya setuju dengan pro yang disebutkan oleh @stevenngj. Mungkin ada kasus penggunaan terpisah untuk memiliki dot hanya berarti sum(x[i]*y[i] for i ...) . Dalam kasus di mana notasi titik infiks paling banyak digunakan dalam matematika, ini memang biasanya artinya. Sebagai produk dalam, notasi titik infiks biasanya (walaupun tentu saja tidak eksklusif) dicadangkan untuk ruang vektor nyata. Kasus penggunaan lainnya termasuk mengaktifkan hal-hal seperti σ ⋅ n dengan σ vektor matriks Pauli dan n vektor skalar. Ini adalah salah satu motivasi di balik cara dot saat ini diterapkan, seperti yang ditunjukkan kepada saya di beberapa utas lainnya. Fakta bahwa BLAS memutuskan untuk hanya menggunakan dot untuk vektor nyata dan membuat perbedaan antara dotu dan dotc untuk vektor kompleks adalah masalah lain yang perlu dipertimbangkan. Orang dengan latar belakang BLAS mungkin bingung apakah, karena memiliki vektor kompleks, mereka ingin menghitung dot(conj(u),v) atau dot(u,v) ketika mereka menginginkan hasil kali dalam yang sebenarnya (yaitu dotc ). Selanjutnya, mereka mungkin mencari cara untuk melakukan dotu tanpa terlebih dahulu membuat salinan konjugasi dari vektor yang ada.

@Jutho kutipan itu milik Anda, komentar lengkap Anda disalin di bawah ini:

Saya setuju, sebagai alternatif untuk vecdot, kami dapat memperkenalkan metode baru di dalam, tetapi saya tidak tahu nama yang bagus untuk "menggantikan" vecnorm. Bahkan, saya tidak menemukan vecnorm yang buruk, norma vektor adalah istilah mapan dan eksplisit untuk operasi yang kita inginkan.

Bagaimanapun, kutipan itu dimaksudkan untuk menunjukkan apa keinginan banyak orang di sini (setidaknya sebagai pemikiran alami pertama) ketika kita memikirkan hal ini. Jika Anda mengubah keinginan Anda dari waktu ke waktu, itu adalah cerita lain. Saya sendiri tidak akan pernah mengeluarkan istilah "titik" dari kepala saya selama pemodelan apa pun dengan ruang Hilbert. Rasanya tidak wajar dan tidak sesuai dengan apa yang saya pelajari.

@Jutho : Selanjutnya, mereka mungkin mencari cara untuk melakukan dotu tanpa terlebih dahulu membuat salinan konjugasi dari vektor yang ada.

Kemungkinan mengekspor fungsi dotu telah muncul dari waktu ke waktu (lihat misalnya #8300). Saya setuju bahwa ini terkadang merupakan fungsi yang berguna: "produk dalam" Euclidean yang tidak terkonjugasi (tidak benar-benar produk dalam lagi) yang merupakan bentuk bilinear simetris (bukan sesquilinear) dotu(x,y) == dotu(y,x) (tidak terkonjugasi) bahkan untuk ruang vektor kompleks . Tetapi kegunaan dari operasi itu tidak terbatas pada — misalnya, produk semacam ini sering muncul dalam ruang vektor (fungsi) dimensi tak hingga untuk persamaan Maxwell sebagai konsekuensi dari timbal balik (pada dasarnya: operator Maxwell dalam bahan lossy tipikal adalah analog dengan "matriks simetris kompleks" — simetris di bawah "hasil kali dalam" tak terkonjugasi. Jadi, jika kita mendefinisikan dot(x,y) sebagai produk dalam Euclidean umum (dengan argumen pertama terkonjugasi), akan sangat wajar untuk mendefinisikan fungsi dotu(x,y) untuk produk Euclidean tak terkonjugasi pada ruang vektor apa pun di mana itu masuk akal. Namun, saya tidak melihat kemungkinan fungsi dotu sebagai argumen terhadap dot . Dalam sebagian besar kasus, ketika Anda bekerja dengan ruang vektor kompleks Anda menginginkan produk terkonjugasi, jadi ini adalah perilaku default yang tepat.

Tetapi saya setuju bahwa satu kemungkinan adalah mendefinisikan dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) , yang saat ini didefinisikan di master (bukan 0.6), dan mendefinisikan inner(x,y) sebagai produk titik yang sebenarnya. Ini memiliki keuntungan menyediakan kedua fungsi, yang keduanya mungkin berguna dalam kasus tertentu. Namun, kami kemudian memiliki dua fungsi yang hampir selalu bertepatan kecuali untuk array matriks, dan saya menduga akan sedikit membingungkan untuk memutuskan kapan harus menggunakan satu atau yang lain. Banyak orang akan menulis dot ketika mereka bermaksud inner , dan itu akan bekerja dengan baik untuk mereka dalam banyak kasus, tetapi kemudian kode mereka akan melakukan sesuatu yang tidak terduga jika dilewatkan array matriks. Kecurigaan saya adalah bahwa dalam 99% kasus orang menginginkan produk dalam yang sebenarnya, dan versi "jumlah produk" dapat diserahkan ke paket, jika memang diperlukan sama sekali (bukan hanya menelepon sum ).

@juliohm , saya salah membaca posting Anda karena saya pikir nama-nama di atas (bukan di bawah) masing-masing kutipan, maka saya pikir Anda menghubungkan kutipan @jebej dengan saya. Saya minta maaf untuk itu.

@stevenngj , saya tentu saja tidak berpikir untuk memiliki dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) sebagai default yang masuk akal. Dalam kasus seperti σ ⋅ n , konjugasi kompleks/hermitian dari argumen pertama atau kedua tidak diperlukan. Jadi apa yang saya katakan adalah bahwa, dalam banyak (tetapi memang tidak semua) kasus di mana notasi titik infiks digunakan dalam rumus ilmiah, artinya bertepatan dengan dotu , yaitu sum(x[i]*y[i] for i = 1:length(x)) tanpa konjugasi, baik sebagai produk dalam pada ruang vektor nyata atau sebagai konstruksi yang lebih umum.

Jadi jika saya membuat proposal alternatif (meskipun saya tidak selalu menganjurkannya), adalah memiliki dua fungsi:

• dot(x,y) = sum(x[i]*y[i] for i...) , yang masih merupakan produk dalam yang benar untuk vektor nyata (yang kemungkinan merupakan kasus penggunaan orang-orang yang kurang atau tidak terbiasa dengan istilah produk dalam) tetapi juga memungkinkan konstruksi yang lebih umum seperti σ ⋅ n , dan dengan demikian merupakan fungsi yang sesuai dengan notasi infiks

• inner(x,y) menjadi produk dalam yang selalu valid, dengan konjugasi dan rekursi, yang akan digunakan oleh orang-orang dalam konteks teknis yang lebih umum.

Saya tidak membela ini sebagai pilihan yang baik untuk diadopsi dalam Bahasa Julia, tetapi saya pikir ini adalah bagaimana ini digunakan di banyak literatur. Ketika titik infiks digunakan, itu baik sebagai produk dalam dalam konteks vektor nyata, atau dalam beberapa konstruksi yang lebih umum di mana itu hanya berarti kontraksi. Ketika produk dalam umum pada ruang vektor arbitrer dimaksudkan, sebagian besar literatur ilmiah (tetapi Anda tentu telah menunjukkan contoh penghitung) beralih ke <u,v> atau <u|v> (di mana pada notasi pertama masih ada diskusi yang dari dua argumen terkonjugasi).

Saya bisa hidup dengan proposal ini, tetapi saya juga bisa hidup dengan hanya memiliki dot sebagai produk dalam umum. Pada akhirnya, ini adalah masalah memiliki dokumentasi yang baik, dan saya juga tidak percaya bahwa ada orang yang akan tersandung pada pilihan "desain" ini.

@Jutho , saya setuju bahwa tidak jarang mendefinisikan dot hanya berarti kontraksi. Tentu saja, orang dapat menemukan contoh dua arah. Misalnya, dalam bahasa pemrograman dan pustaka populer:

• Tidak terkonjugasi: Numpy dot (dan, anehnya, inner ), Mathematica's Dot , Maxima . , BLAS dotu

• Terkonjugasi: Matlab's dot , Fortran's DOT_PRODUCT , Maple's DotProduct , Petsc's VecDot , Numpy vdot , BLAS dotc (perhatikan bahwa kurangnya kelebihan beban di Fortran 77 membuat tidak mungkin untuk memanggil ini dot bahkan jika mereka mau), titik Eigen

Di satu sisi, produk dalam terkonjugasi biasanya diperkenalkan di buku teks sebagai perpanjangan "alami" dari gagasan "produk titik" ke vektor kompleks — versi tak terkonjugasi dalam beberapa hal merupakan ekstensi "tidak wajar", karena biasanya tidak apa maumu. (Pertimbangkan fakta bahwa, dari bahasa yang menyediakan fungsi dot terkonjugasi di pustaka standar mereka — Matlab, Fortran, Julia, Maple — hanya Maple yang menyediakan varian tak terkonjugasi, mengisyaratkan kurangnya permintaan.) Pada sisi lain, fungsi dotu tak terkonjugasi nyaman (sebagai suplemen) dalam kasus khusus tertentu (beberapa di antaranya saya sebutkan di atas).

Jika kita memiliki dot dan inner , saya menduga bahwa banyak orang akhirnya akan menggunakan dot secara tidak sengaja ketika mereka benar-benar menginginkan inner agar kode mereka menjadi umum. (Saya berani bertaruh bahwa inner Numpy tidak terkonjugasi karena kecelakaan seperti itu - mereka menerapkannya dengan array nyata dalam pikiran, dan tidak memikirkan kasus kompleks sampai terlambat untuk berubah sehingga mereka menambahkan canggung bernama vdot .) Sedangkan jika kita memiliki dot dan (mungkin) dotu , akan lebih jelas bahwa dot adalah pilihan default dan dotu adalah varian kasus khusus.

(Saya setuju bahwa ⟨u,v⟩ , ⟨u|v⟩ , atau (u,v) adalah notasi yang lebih umum untuk produk dalam pada ruang Hilbert arbitrer—mereka adalah yang biasanya saya gunakan sendiri—tetapi notasi tersebut adalah nonstarter untuk Julia. Ada beberapa diskusi tentang penguraian tanda kurung Unicode sebagai panggilan fungsi/makro, misalnya #8934 dan #8892, tetapi tidak pernah ke mana-mana dan ini sepertinya tidak akan segera berubah.)

Saya sepenuhnya setuju dengan penilaian Anda @stevenngj .

Gerakan mengungkap kekerasan seksual demi menghapuskannya.

Saya menduga sudah waktunya bagi salah satu dari kita untuk bermain dengan salah satu implementasi dalam PR dan melihat bagaimana hasilnya.

@Jutho Saya selalu melihat produk titik dengan matriks Pauli sebagai singkatan untuk kontraksi pada tensor orde tinggi... salah satu ruang vektor adalah nyata, 3D.

Saya setuju bahwa u,v⟩, u|v⟩, atau (u,v) adalah notasi yang lebih umum untuk hasilkali dalam pada ruang Hilbert yang arbitrer—mereka adalah yang biasanya saya gunakan sendiri—tetapi notasi tersebut bukan starter untuk Julia.

Sebenarnya mungkin untuk membuat ⟨u,v⟩ berfungsi.

@StefanKarpinski : Sebenarnya mungkin untuk membuat u,v⟩ berfungsi.

Tentu saja, dan mendukung notasi yang tepat ini disarankan di #8934, tetapi tidak pernah ke mana-mana. (Perhatikan juga bahwa kurung sudut memiliki kegunaan umum lainnya, misalnya u⟩ sering menunjukkan rata-rata dari beberapa jenis.) Ini tidak putus-putus dan masih dapat ditambahkan di beberapa titik, tetapi tampaknya tidak masuk akal untuk diharapkan dalam waktu dekat. ketentuan. Ini juga cukup lambat untuk mengetik \langle<tab> x, y \rangle<tab> , jadi sangat tidak nyaman dari sudut pandang pemrograman untuk operasi dasar.

dan kita tidak dapat membebani <> untuk itu, bukan?

Tidak

Saya tidak bisa mengatakan bahwa saya telah membaca setiap komentar di utas yang sangat besar ini, tetapi saya hanya ingin menyoroti beberapa poin, beberapa di antaranya telah dibuat sebelumnya:

• Membedakan antara titik dan bagian dalam tampaknya terlalu bertele-tele. Memang di telinga saya sepertinya tidak masuk akal karena dalam bahasa Prancis hanya ada satu istilah - "produk skalar" - dan sulit untuk membedakan antara hal-hal yang bagi saya memiliki nama yang sama ;-)
• Ketika Anda berasal dari numpy dan bekerja dengan array yang kompleks, memiliki dot yang terkonjugasi secara default adalah hal terbaik yang pernah ada. Tidak ada titik keputusan di sini, saya hanya ingin mengatakan betapa senangnya saya karena saya tidak lagi harus melakukan conj(dot()) ini!
• Memiliki dua fungsi yang memiliki perilaku yang sama dalam banyak kasus tetapi terkadang berbeda adalah desain yang buruk, dan telah dan akan menyebabkan kebingungan, dengan kode yang seharusnya memanggil yang satu sebenarnya memanggil yang lain, hanya karena pengguna tidak tahu lebih baik. Ini sangat mengganggu dengan norm : jika Anda mengkodekan algoritma pengoptimalan dan ingin berhenti kapan pun norm(delta x) < eps , Anda akan menulis norm . Tapi kemudian Anda ingin mengoptimalkan wrt gambar atau sesuatu, Anda menjalankan kode Anda, dan tiba-tiba diluncurkan ke SVD unkillable (karena BLAS) dari array besar. Ini bukan akademis, ini telah menyebabkan masalah di Optim.jl, dan tentu saja di paket lain juga. Tidak ada yang akan tahu bahwa vecnorm ada kecuali mereka memiliki alasan khusus untuk mencarinya.
• Berdasarkan poin sebelumnya, solusi apa pun yang menggabungkan dot dan vecdot , dan norm dan vecnorm adalah baik, bahkan jika itu menghilangkan sedikit fleksibilitas dalam kasus array-of-array. Untuk norma, saya akan sering menambahkannya ketika bekerja dengan hal-hal di mana ada beberapa norma yang ditentukan (misalnya matriks), yang diinginkan pengguna adalah memanggil norm untuk mendapatkan norma, tanpa terlalu peduli yang mana. Norma yang diinduksi paling sering bersifat teoritis daripada kepentingan praktis karena ketangguhan komputasinya. Mereka juga khusus untuk interpretasi array 2D sebagai operator daripada array 2D sebagai penyimpanan (gambar adalah array 2D, tetapi itu bukan operator dalam arti yang berguna). Ada baiknya memiliki kemungkinan untuk menghitungnya, tetapi mereka tidak layak menjadi default norm . Default yang masuk akal, sederhana, dan terdokumentasi dengan baik yang memiliki alternatif yang dapat ditemukan lebih baik daripada upaya kepandaian (jika pengguna ingin melakukan hal yang cerdas, biarkan mereka melakukannya secara eksplisit).

Oleh karena itu, +1 pada @stevenngj 's

ya, saya pikir jika kita membuat perubahan ini maka kita hanya perlu titik dan norma (yang sekarang merupakan operasi Euclidean rekursif pada array atau array-array dari dimensi apa pun, meskipun untuk norma kita juga mendefinisikan norma(x,p) menjadi p-norm) dan opnorm, dan tidak lagi memiliki vecdot atau vecnorm.

Alternatif yang lebih "julian" untuk norm/opnorm mungkin memiliki tipe Operator, yang dapat membungkus array 2D, di mana norm melakukan opnorm. Ini dapat dilakukan pada tingkat paket (beberapa di antaranya sudah ada)

Saya lebih suka mengetik opnorm(matrix) daripada norm(Operator(matrix)) …

Saya akan berpadu dari galeri kacang di sini dan mengatakan bahwa saya suka ke mana arahnya— vecnorm dan vecdot selalu mengganggu saya. Perlu secara eksplisit meminta norma operator—yang selalu tampak cukup khusus bagi saya—tampak jauh lebih waras daripada harus meminta norma yang jauh lebih cepat dan lebih mudah untuk dihitung (misalnya norma Frobenius). Menulis opnorm tampak seperti antarmuka yang bagus untuk menanyakan norma operator yang relatif khusus.

Saya juga merasa bahwa perbedaan tipis antara dot dan inner kemungkinan akan menyebabkan kebingungan dan penyalahgunaan yang merajalela. Mengajarkan pengguna tentang fungsi mana yang _seharusnya digunakan ketika kedua fungsi melakukan apa yang mereka inginkan dan salah satunya lebih mudah cenderung tidak berjalan dengan baik. Kesan saya adalah relatif jarang dalam kode generik bahwa sum(x*y for (x,y) in zip(u,v)) sebenarnya yang Anda inginkan ketika produk dalam yang sebenarnya ⟨u,v⟩ benar-benar ada. Ketika itu benar-benar yang diinginkan, cukup mudah, jelas dan efisien (karena Julia adalah apa adanya) untuk hanya menulis sesuatu seperti itu untuk menghitungnya.

Apakah akan memanggil fungsi u⋅v dot atau inner tampaknya merupakan bagian yang paling tidak penting dari semua ini. Saya cukup yakin bahwa tidak ada pilihan yang akan dipandang kembali oleh sejarawan sebagai bencana—walaupun gagasan bahwa sejarawan akan peduli sama sekali tentu saja menyanjung. Di satu sisi, jika kita setuju untuk mempertahankan arti "perkalian dalam yang sebenarnya" dari u⋅v maka ya, inner adalah istilah matematika yang lebih tepat. Di sisi lain, ketika ada sintaks dengan nama fungsi yang sesuai, itu cenderung tidak membingungkan pengguna ketika namanya cocok dengan sintaks. Karena sintaks di sini menggunakan titik, aturan praktis itu mendukung ejaan operasi ini sebagai dot . Mungkin ini kasus yang masuk akal untuk mendefinisikan const dot = inner dan mengekspor keduanya? Kemudian orang dapat menggunakan atau memperluas nama mana pun yang mereka sukai karena keduanya sama. Jika seseorang ingin menggunakan salah satu nama untuk hal lain, mereka dapat melakukannya, dan nama lainnya akan tetap tersedia dengan arti defaultnya. Tentu saja itu akan membuat tiga nama yang diekspor untuk fungsi yang sama— dot , inner dan ⋅ —yang tampaknya agak berlebihan.

Apakah ini opsi untuk menghapus simbol ⋅ atau menggantinya dengan <u,v> ?

Komentar:

• Itu membuat niat menjadi jelas. Bandingkan dua contoh ini:

<u,v> * M * x

vs.

u ⋅ v * M * x

• Sintaks <u,v> menyiratkan asosiasi: pertama kita beroperasi pada u dan v dan kemudian ekspresi selanjutnya mengikuti.

• Jika seorang pengguna berusaha untuk mengetik <u,v> , sangat kecil kemungkinannya bahwa dia hanya memikirkan sum(x[i]*y[i]) . Simbol ⋅ mudah dilewati dengan mata, dan memiliki banyak konotasi lainnya. Khususnya, dalam aljabar linier, untuk ruang vektor V di atas bidang F, produk skalar α ∈ F dengan vektor v ∈ V dilambangkan α ⋅ v dalam berbagai buku teks.

• Menghapus atau mengganti ⋅ juga akan menghilangkan masalah beberapa nama yang diekspor. Seseorang hanya perlu mengekspor inner dan <,> untuk produk dalam umum, dengan implementasi default untuk array yang cocok dengan semantik penjumlahan yang dapat diulang.

• Jika seseorang perlu mendefinisikan produk skalar-demi-vektor seperti yang dijelaskan di atas untuk ruang vektor V di atas bidang F, ia akan dapat mendefinisikan notasi ⋅ untuk itu. Ruang vektor kemudian akan sepenuhnya didefinisikan dengan sintaks pendek yang bagus, dan dapat diperluas ke ruang Hilbert dengan mendefinisikan lebih lanjut <u,v> .

Kami pasti tidak dapat menggunakan sintaks <u,v> ; sintaks yang bisa kita gunakan adalah ⟨u,v⟩ —perhatikan tanda kurung Unicode, tidak kurang dari dan lebih besar dari tanda, < dan > . Kami juga memiliki u'v sebagai sintaks untuk sesuatu yang merupakan produk titik atau produk dalam? (Saya tidak yakin yang mana...)

Ya, maaf, versi unicode-nya. Akan sangat jelas untuk dibaca. Itu juga akan menyelesaikan masalah ini dengan banyak nama, dan ⋅ gratis untuk tujuan lain.

Saya rasa kita tidak ingin menggunakan ⋅ untuk tujuan lain—sepertinya ini akan membingungkan.

Bayangkan saja betapa indahnya bisa menulis kode yang terlihat seperti:

⟨α ⋅ u, v⟩ + ⟨β ⋅ w, z⟩

untuk vektor abstrak (atau tipe) u,v,w,z ∈ V dan skalar α, β ∈ F .

u'v adalah produk dalam (dan produk titik, jika Anda mengikuti konvensi terkonjugasi) hanya untuk array 1d, bukan untuk misalnya matriks. (Ini adalah alasan lain mengapa tidak ada gunanya membatasi titik infiks ke array 1d, karena kita sudah memiliki notasi singkat untuk kasus itu.)

Stefan, "istilah matematika yang benar" adalah kesalahan kategori — kebenaran matematika bukanlah konsep yang berlaku untuk terminologi/notasi. (Ganti "konvensional" untuk "benar." Tapi kemudian kekhawatiran menjadi kurang mendesak,)

Lebih banyak kasus penggunaan: https://stackoverflow.com/questions/50408177/julia-calculate-an-inner-product-using-boolean-algebra

Dan turunan formal produk dalam boolean menggunakan notasi ⟨,⟩ : https://arxiv.org/abs/0902.1290

EDIT: tautan tetap ke kertas

Apa pendapat Anda tentang proposal sintaks kurung sudut? Apakah itu akan menyelesaikan masalah yang diangkat di sini?

Jadi apa sebenarnya proposal Anda? Apakah kira-kira begini:

1. Menghentikan dot menjadi inner
2. Menghentikan u⋅v menjadi ⟨u,v⟩

Jadi tidak akan ada fungsi dot dan tidak ada operator ⋅ ?

Akankah perubahan itu menjadi sesuatu yang masuk akal?

Maaf atas keterlambatan membalas, saya sedang menghadiri konferensi dengan akses internet terbatas.

Dan hanya untuk kejelasan dan kelengkapan, apa kontraproposal di sini? Tidak melakukan apapun?

Untuk memperjelas proposal lebih jauh, ada perubahan semantik yang terlibat: produk dalam yang digeneralisasi.

Perhatian: kami sekarang telah memperdebatkan hal ini ke titik di mana ada risiko nyata bahwa itu tidak akan berhasil menjadi 0,7-alfa. Itu tidak berarti itu tidak dapat diubah setelah alpha, tetapi akan ada lebih banyak keengganan untuk mengubah hal-hal setelah itu.

Ya, saya berharap saya memiliki keterampilan untuk mengajukan PR sejak lama. Itu di luar kemampuan saya untuk mewujudkannya, meskipun menurut saya itu adalah fitur yang sangat penting.

Bahkan mengabaikan pertanyaan sintaks operator, masih ada beberapa kompleksitas dengan bayangan nama dan penghentian multi-tahap untuk setiap rangkaian konsep semantik ( dot saat ini dan vecdot dan norm saat ini dan vecnorm ).

Untuk sisi dot sepertinya seluruh ruang opsi (sekali lagi diskon operator) adalah:

I. Pecahkan dot diam-diam pada vektor larik dengan mengubah perilaku di 0,7 ke produk dalam tanpa peringatan standar (walaupun Anda dapat memperingatkan bahwa perilaku sedang diubah). Menghentikan vecdot menjadi dot di 0,7 juga.
II. Di 0,7, hentikan vecdot pada semua input ke inner .
AKU AKU AKU. Dalam 0,7, hentikan dot pada vektor array ke definisinya, dan dot pada input lain dan vecdot pada semua input ke inner .
IV. Di 0.7, hentikan dot dan vecdot pada vektor array baik ke fungsi yang tidak diekspor atau ke definisinya, dan vecdot pada semua input lain ke dot . Di 1.0, tambahkan dot pada vektor array dengan semantik produk dalam.

Untuk sisi norma ada beberapa konsensus seputar satu jalur (dalam 0,7, hentikan norm pada matriks menjadi opnorm dan mungkin tidak digunakan lagi vecnorm ke innernorm ; dalam 1.0 , tambahkan norm pada matriks dengan semantik vecnorm saat ini), tetapi itu juga menghasilkan nama tambahan di 1.0 (baik vecnorm atau innernorm ); sekali lagi cara untuk menghindarinya adalah dengan tidak menggunakan vecnorm dalam 0,7 ke definisinya atau ke fungsi yang tidak diekspor seperti Base.vecnorm daripada ke nama yang diekspor.

...Menurut saya. Semoga saya tidak membuat hal-hal lebih lembek daripada yang sudah ada.

Adakah yang bisa akrab dengan basis kode mengirimkan PR untuk perubahan?

Bisakah kita memisahkan hal-hal norma yang tampaknya disetujui semua orang dan menyelesaikannya setidaknya? Bit dot versus inner sedikit lebih kontroversial, tetapi jangan biarkan hal itu menghalangi bagian yang tidak.

@StefanKarpinski , perhatikan bahwa mereka agak digabungkan: untuk tipe di mana Anda memiliki produk titik (dalam) dan norma, keduanya harus konsisten.

Oke, saya tidak terlalu peduli ke arah mana ini berjalan. Siapa pun yang melakukan pekerjaan harus memutuskan.

Saya memiliki PR ( #25093 ) untuk membuat vecdot berperilaku sebagai produk dalam yang sebenarnya (dan vecnorm sebagai norma yang sesuai), dengan membuatnya rekursif. Ini mungkin berguna sebagai titik awal tentang bagaimana masa depan dot dan norm akan terlihat. Sayangnya, kurangnya keterampilan git saya membuat saya mengacaukan PR itu jadi saya menutupnya, berencana untuk kembali ke sana setelah sintaks iterasi baru selesai.

Namun, baru saja menjadi ayah untuk kedua kalinya beberapa hari yang lalu berarti saat ini tidak ada slot "waktu luang" di kalender saya.

baru saja menjadi ayah untuk kedua kalinya beberapa hari yang lalu

Selamat Yuto! 🎉.

Ya, selamat!

Sepertinya mungkin ada beberapa konsensus yang terbentuk seputar gagasan memiliki dot dan inner , di mana:

1. inner adalah produk dalam rekursif sejati
2. dot = dot(x,y) = sum(x[i]'*y[i] for i = 1:length(x)) terkonjugasi atau tidak, dan karena itu akan tumpang tindih dengan dot untuk Vector{<:Number} atau Vector{<:Real}

Tentang:

Banyak orang akan menulis titik ketika mereka bermaksud dalam, dan itu akan berfungsi dengan baik untuk mereka dalam banyak kasus, tetapi kemudian kode mereka akan melakukan sesuatu yang tidak terduga jika dilewatkan dalam array matriks.

Saya tidak percaya itu akan menjadi masalah. Karena ini adalah operasi yang tidak biasa, saya berharap orang-orang setidaknya mencobanya untuk melihat apa yang dilakukannya dan/atau melihat dokumentasinya.

Saya pikir hal di atas akan menjadi perubahan besar, dan tidak terlalu mengganggu karena semantik dot tidak berubah dalam banyak kasus.

Sepertinya mungkin ada beberapa konsensus yang terbentuk seputar gagasan memiliki dot dan inner

Sebaliknya, diskusi dari https://github.com/JuliaLang/julia/issues/25565#issuecomment -390069503 tentang tampaknya lebih menyukai memiliki satu atau yang lain tetapi tidak keduanya, seperti yang dijelaskan di https://github. com/JuliaLang/julia/issues/25565#issuecomment -390388230 dan didukung dengan baik dengan reaksi.

Mungkin inner (dan juga dot ) harus menjadi produk dalam/titik/skalar rekursif dan perilaku lama dapat diimplementasikan dalam fungsi seperti dotc(x,y) = sum(x[i]' * y[i] for i in eachindex(x)) dan dotu(x,y) = sum(transpose(x[i]) * y[i] for i in eachindex(x)) ? Nama dotu dan dotc akan cocok dengan nama BLAS yang sesuai.

(Saya setuju bahwa u,v⟩, u|v⟩, atau (u,v) adalah notasi yang lebih umum untuk hasilkali dalam pada ruang Hilbert yang arbitrer—inilah yang biasanya saya gunakan sendiri—tetapi notasi tersebut bukan starter untuk Julia Ada beberapa diskusi tentang penguraian tanda kurung Unicode sebagai panggilan fungsi/makro, misalnya #8934 dan #8892, tetapi tidak pernah berhasil dan tampaknya tidak akan segera berubah.)

@stevenngj , ketika Anda menambahkan paragraf ini ke komentar sebelumnya sendiri, maksud Anda sintaks ⟨u,v⟩ sulit diterapkan dalam bahasa?

Adakah kemungkinan fitur ini akan masuk ke Julia v1.0? Saya memiliki begitu banyak ide dan paket yang bergantung pada gagasan produk dalam umum. Tolong beri tahu saya jika saya harus menurunkan harapan saya. Maaf untuk selalu diingatkan.

Apakah Anda tidak melihat #27401?

Terima kasih @jebej dan terima kasih @ranocha sudah memimpin :heart:

ketika Anda menambahkan sendiri paragraf ini ke komentar sebelumnya, maksud Anda sintaks u,v⟩ sulit diterapkan dalam bahasa tersebut?

Secara teknis tidak sulit untuk ditambahkan ke parser, tetapi terbukti sulit untuk mencapai konsensus tentang bagaimana (dan apakah) merepresentasikan tanda kurung khusus dalam bahasa tersebut. Lihat diskusi di #8934, yang tidak ke mana-mana 4 tahun yang lalu dan belum dihidupkan kembali sejak itu. (Tambahkan fakta bahwa di bidang yang berbeda orang menggunakan tanda kurung yang sama untuk banyak hal yang berbeda, misalnya u⟩ digunakan untuk rata-rata ansambel dalam fisika statistik.) Masalah lain, yang diangkat di #8892, adalah kesamaan visual dari banyak Unicode yang berbeda. kurung.

Terima kasih @stevenngj , saya menghargai klarifikasinya. Saya sudah sangat senang bahwa kita akan memiliki produk dalaman umum yang distandarisasi di seluruh paket. :100: Mungkin notasi braket sudut bisa bersinar di siklus rilis lain di masa mendatang. Tidak terlalu penting, tetapi cukup nyaman untuk dapat menulis kode yang secara harfiah seperti matematika dalam publikasi kami.

Jika ⟨args...⟩ adalah sintaks yang valid untuk memanggil operator anglebrackets atau sesuatu (sebutan apa fungsi yang dipanggil sintaks ini sebenarnya agak rumit karena kita tidak memiliki preseden), maka orang bisa memilih makna apa pun yang mereka inginkan untuk sintaks.

@StefanKarpinski , argumen di #8934 adalah bahwa itu harus makro. Saya tidak berpikir kita pernah mencapai konsensus.

(Jika kita memutuskan di Basis bahwa anglebrackets(a,b) berarti inner(a,b) , itu akan membuat orang enggan "memilih dalam arti apa pun yang mereka inginkan" karena keputusan sudah dibuat.
Ini bukan pilihan yang buruk, tentu saja, tetapi mungkin tidak perlu untuk memberikan arti ini di Base selama mereka diuraikan.)

Saya tidak ingat detail dari diskusi itu tetapi membuat makro sepertinya jelas merupakan ide yang buruk bagi saya.

Dengan #27401 saya pikir kita dapat menganggap produk dalam telah dianggap serius.

Secara tradisional, masalah ditutup hanya ketika PR yang relevan digabungkan...

Tentu, kita bisa membiarkannya terbuka, kurasa. Hanya ingin melepaskannya dari label triase.

Haruskah ini ditutup karena #27401 digabungkan sekarang?