Mengapa menambahkan probabilitas log lebih cepat daripada mengalikan probabilitas?

Untuk membingkai pertanyaan, dalam ilmu komputer sering kita ingin menghitung produk dari beberapa probabilitas:

P(A,B,C) = P(A) * P(B) * P(C)

Pendekatan paling sederhana adalah melipatgandakan angka-angka ini, dan itulah yang akan saya lakukan. Namun, bos saya mengatakan lebih baik menambahkan log probabilitas:

log(P(A,B,C)) = log(P(A)) + log(P(B)) + log(P(C))

Ini memberikan probabilitas log, tetapi kita bisa mendapatkan probabilitas setelahnya jika perlu:

P(A,B,C) = e^log(P(A,B,C))

Penambahan log dianggap lebih baik karena dua alasan:

Ini mencegah "underflow" di mana produk probabilitas sangat kecil sehingga dibulatkan menjadi nol. Ini sering bisa menjadi risiko karena probabilitas seringkali sangat kecil.
Itu lebih cepat karena banyak arsitektur komputer dapat melakukan penambahan lebih cepat daripada perkalian.

Pertanyaan saya adalah tentang poin kedua. Ini adalah bagaimana saya melihatnya dijelaskan, tetapi tidak memperhitungkan biaya tambahan untuk mendapatkan log! Kita harus membandingkan "biaya log + biaya penambahan" ke "biaya penggandaan". Apakah masih lebih kecil setelah memperhitungkannya?

Juga, halaman Wikipedia ( Kemungkinan log ) membingungkan dalam hal ini, yang menyatakan "Konversi ke formulir log mahal, tetapi hanya dilakukan sekali." Saya tidak mengerti ini, karena saya pikir Anda perlu mengambil log dari setiap istilah secara independen sebelum menambahkan. Apa yang saya lewatkan?

Akhirnya, pembenaran bahwa "komputer melakukan penambahan lebih cepat daripada multiplikasi" agak kabur. Apakah itu spesifik untuk set instruksi x86, atau itu beberapa sifat yang lebih mendasar dari arsitektur prosesor?

algorithm-analysis probability-theory

— Stephen
sumber

Manfaat pertama (menghindari underflow) seringkali jauh lebih penting daripada keuntungan kinerja, jadi bahkan jika itu tidak lebih cepat kita masih akan menggunakan probabilitas log.

— DW

Untuk memperluas apa yang dikatakan @DW, ada "trik log-sum-exp" yang serupa yang digunakan secara khusus untuk mengatasi underflow, tanpa memperhatikan kinerja apa pun. Bahkan, ini adalah pertama kalinya saya melihat seseorang menganggap mengambil logaritma sebagai teknik peningkatan kinerja!

— Mehrdad

Jawaban:

Juga, halaman Wikipedia ( https://en.wikipedia.org/wiki/Log_probability ) membingungkan dalam hal ini, menyatakan "Konversi ke bentuk log mahal, tetapi hanya dilakukan sekali." Saya tidak mengerti ini, karena saya pikir Anda perlu mengambil log dari setiap istilah secara independen sebelum menambahkan. Apa yang saya lewatkan?

Jika Anda hanya ingin menghitung satu kali, maka Anda benar. Anda harus menghitung logaritma dan penambahan , sedangkan metode naif membutuhkan perkalian . $P(A_1)\ldots P(A_n)$ $n$ $n-1$ $n-1$

Namun, sangat umum bahwa Anda ingin menjawab pertanyaan dari formulir:

Hitung untuk beberapa subset dari . $\prod_{i \in I} P(A_i)$ $I$ $\{1, \ldots n\}$

Dalam hal ini, Anda dapat memproses data Anda untuk menghitung semua hanya sekali, dan menjawab setiap permintaan dengan melakukan tambahan. $\log P(A_i)$ $|I|$

Akhirnya, pembenaran bahwa "komputer melakukan penambahan lebih cepat daripada multiplikasi" agak kabur. Apakah itu spesifik untuk set instruksi x86, atau itu beberapa sifat yang lebih mendasar dari arsitektur prosesor?

Ini pertanyaan yang lebih luas. Secara umum (mungkin?) Lebih sulit untuk menghitung perkalian daripada penambahan. Komputasi adalah linier dalam ukuran dan (menggunakan algoritma trivial), sedangkan kita saat ini tidak tahu bagaimana menghitung dengan kompleksitas waktu yang sama (periksa algoritma terbaik di sini ). $a+b$ $a$ $b$ $a\times b$

Tentu saja tidak ada jawaban pasti: misalnya jika Anda hanya berurusan dengan bilangan bulat dan Anda mengalikannya dengan angka , maka Anda harus membandingkan shift dengan operasi tambah. $2$

Namun demikian ini adalah pernyataan yang masuk akal pada semua arsitektur komputer umum: perkalian pada angka floating-point akan lebih lambat daripada penambahan.

— md5
sumber

Bukankah Anda juga perlu memperhitungkan kompleksitas waktu yang diperlukan untuk menghitung logaritma untuk semua probabilitas

P (A_{i})

$P(A_i)$

— David C

Bagaimana dengan exp akhir ()? Bukankah itu lambat?

— Mehrdad

@ DavidC: Saya tidak mencoba menghitung kompleksitas waktu keseluruhan. Saya hanya menjawab pertanyaan "apakah perkalian lebih cepat daripada penambahan". Tetapi dalam komputasi umum logaritma angka floating-point pada skala perangkat lunak dapat mengambil

mana

adalah kompleksitas dari algoritma multiplikasi. Sehingga akan memberikan

kompleksitas (di mana

Θ (M (n) \log n)

$\Theta(M(n)\log n)$

M (n)

$M(n)$

Θ (n M (n) \log n + n \sum_{q \in Q} | I_{q} |)

$\Theta(nM(n)\log n+n\sum_{q\in Q}|I_q|)$

Q

$Q$ adalah himpunan pertanyaan).

— md5

@Mehrdad: Sama sulitnya dengan menghitung logaritma. Namun saya tidak yakin Anda harus melakukan itu. Misalnya, jika Anda hanya membandingkan probabilitas, Anda lebih suka tidak menghitung

akhir . Perkalian

angka dalam

dapat dengan cepat menjadi sangat kecil, jadi untuk alasan yang sama kami mencoba menghindari underflow dengan menggunakan probabilitas log, kita harus tetap dalam bentuk logaritmik pada akhirnya (misalnya dengan menghitung

di basis

, sehingga lebih "terbaca oleh manusia").

\exp

$\exp$

n

$n$

(0, 1)

$(0,1)$

\log

$\log$

10

$10$

— md5

Apakah penambahan masih lebih cepat daripada perkalian jika Anda menggunakan IEEE float - yang tentunya Anda akan lakukan dalam kasus ini? CPU modern cukup baik dalam mengalikan angka sedangkan penambahan float memiliki beberapa langkah yang tidak dapat dieksekusi secara bersamaan - menyelaraskan mantra (bergeser ke kiri berdasarkan hasil pengurangan), kemudian menambahkannya, kemudian menormalkan (yang dapat memicu baik underflow dan meluap, yay). Dalam rangkaian itu cukup banyak mati, dalam mikrokode setiap langkah membutuhkan satu atau beberapa siklus.

— John Dvorak

$N$ $p_1,...p_N$ $p_i$

$N$

$O(n)$ $n$ $O(n^2)$

Ngomong-ngomong, ide ini mirip dengan multiplikasi modular Montgomery, di mana multiplikasi dilakukan dalam bentuk Montgomery yang jauh lebih cepat daripada multiplikasi biasa dan kemudian reduksi.

— fade2black
sumber

-1 Multiplikasi tidak membutuhkan waktu kuadrat ...

— Mehrdad

@Mehrdad, saya harap Anda belajar multiplikasi sekolah dari dua angka. Algoritme itu masih banyak digunakan pada chip komputer, silakan lihat di sini. Apa yang Anda maksud adalah algoritma level perangkat lunak yang masih lebih buruk daripada waktu linier. Apakah algoritma multiplikasi ini banyak digunakan seperti pada rangkaian multiplikasi?

— fade2black

en.wikipedia.org/wiki/Carry-save_adder#The_basic_concept

— Mehrdad

Semangat jawabannya masih benar, kan? Jika tidak ada algoritma multiplikasi yang cocok dengan waktu penambahan linier?

— Stephen

@Stephen, pada kenyataannya pertanyaannya bukan tentang apa kompleksitas yang tepat dari algoritma multiplikasi. Saya bisa memberikan informasi tambahan tentang hal ini jika komentator diperlukan. Saya pikir diskusi panjang tentang itu akan menjadi topik di sini. )))

— fade2black