곱하기 확률보다 로그 확률을 더 빠르게 추가하는 이유는 무엇입니까?

문제를 해결하기 위해 컴퓨터 과학에서 종종 여러 확률의 곱을 계산하려고합니다.

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

가장 간단한 방법은 단순히이 숫자를 곱하는 것입니다. 이것이 바로 제가하려는 것입니다. 그러나 상사는 확률의 로그를 추가하는 것이 좋습니다.

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

이것은 로그 확률을 제공하지만 필요한 경우 나중에 확률을 얻을 수 있습니다.

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

다음과 같은 두 가지 이유로 로그 추가가 더 나은 것으로 간주됩니다.

확률의 곱이 너무 작아서 0으로 반올림되는 "언더 플로우"를 방지합니다. 확률이 종종 매우 작기 때문에 이것은 종종 위험이 될 수 있습니다.
많은 컴퓨터 아키텍처가 곱셈보다 더 빠르게 덧셈을 수행 할 수 있기 때문에 더 빠릅니다.

제 질문 은 두 번째 요점입니다. 이것이 내가 설명 한 방법이지만 로그를 얻는 데 드는 추가 비용은 고려하지 않았습니다! "로그 비용 + 추가 비용"을 "곱하기 비용"과 비교해야합니다. 그것을 고려한 후에도 여전히 더 작습니까?

또한 Wikipedia 페이지 ( Log 확률 )는 "로그 형식으로 변환하는 데 비용이 많이 들지만 한 번만 발생합니다." 나는 이것을 이해하기 전에 모든 용어의 로그를 독립적으로 가져 가야한다고 생각하기 때문에 이것을 이해하지 못합니다. 내가 무엇을 놓치고 있습니까?

마지막으로, "컴퓨터가 곱셈보다 더 빠르게 덧셈을한다"는 정당성은 모호하다. 이는 x86 명령어 세트에만 해당됩니까, 아니면 프로세서 아키텍처의보다 근본적인 특성입니까?

algorithm-analysis probability-theory

— 스티븐
소스

언더 플로를 피하는 첫 번째 이점은 성능 향상보다 훨씬 중요하기 때문에 속도가 빠르지 않더라도 여전히 로그 확률을 사용합니다.

— DW

@DW가 말한 것을 확장하기 위해 성능에 관계없이 언더 플로를 처리하기 위해 특별히 사용 된 유사한 "로그-섬-익스프레스 트릭"이 있습니다. 사실, 누군가가 로그를 성능 향상 기법으로 생각하는 것을 본 것은 이번이 처음이었습니다!

— Mehrdad

답변:

또한 Wikipedia 페이지 ( https://en.wikipedia.org/wiki/Log_probability )는 이와 관련하여 "로그 형식으로 변환하는 데 많은 비용이 들지만 한 번만 발생합니다." 나는 이것을 이해하기 전에 모든 용어의 로그를 독립적으로 가져 가야한다고 생각하기 때문에 이것을 이해하지 못합니다. 내가 무엇을 놓치고 있습니까?

한 번만 계산 하려면 옳습니다. 순진한 방법에는 곱셈이 필요한 반면 로그와 덧셈 을 계산 해야합니다 . $P(A_1)\ldots P(A_n)$ $n$ $n-1$ $n-1$

그러나 다음과 같은 형식의 쿼리에 응답하는 것이 매우 일반적입니다.

계산 에 대한 약간의 부분 집합 의 . $\prod_{i \in I} P(A_i)$ $I$ $\{1, \ldots n\}$

이 경우 모든 한 번만 계산하기 위해 데이터를 사전 처리 하고 추가. $\log P(A_i)$ $|I|$

마지막으로, "컴퓨터가 곱셈보다 더 빠르게 덧셈을한다"는 정당성은 모호하다. 이는 x86 명령어 세트에만 해당됩니까, 아니면 프로세서 아키텍처의보다 근본적인 특성입니까?

이것은 더 넓은 질문입니다. 일반적으로 덧셈보다 곱셈을 계산하기가 어렵습니다. 계산 것은 와 의 크기가 선형 적이 지만 (사소한 알고리즘 사용) 현재 우리 는 동일한 시간 복잡도로 를 계산 방법을 모릅니다 ( 여기서 가장 좋은 알고리즘을 확인 하십시오 ). $a+b$ $a$ $b$ $a\times b$

물론 정답은 없습니다. 예를 들어 정수만 처리하고 거듭 제곱을 곱하면 shift와 add 연산을 비교해야합니다. $2$

그럼에도 불구하고 이것은 모든 일반적인 컴퓨터 아키텍처에서 합리적입니다. 부동 소수점 숫자의 곱셈은 덧셈보다 느립니다.

— md5
소스

모든 확률

대한 로그를 계산하는 데 필요한 시간 복잡성을 고려할 필요도 없습니다.

P (A_{i})

$P(A_i)$ 없습니까?

— David C

최종 exp ()는 어떻습니까? 그렇게 느리지 않습니까?

— Mehrdad 2016 년

@DavidC : 전반적인 시간 복잡성을 계산하지 않았습니다. 방금 "더하기보다 곱셈이 빠릅니다"라는 질문에 답했습니다. 그러나 일반적으로 소프트웨어 스케일에서 부동 소수점 숫자의 계산 로그는

취할 수 있습니다. 여기서

은 곱셈 알고리즘의 복잡성입니다. 따라서

복잡성 (여기서

Θ (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$ 쿼리 세트입니다).

— md5 2016 년

@Mehrdad : 로그를 계산하는 것만 큼 어렵습니다. 그러나 당신이 그렇게해야할지는 확실하지 않습니다. 예를 들어 확률 만 비교하면 최종

계산하지 않을 것 입니다.

의

수 의 곱셈 은 빠르게 매우 작아 질 수 있으므로 로그 확률을 사용하여 언더 플로를 피하려고하는 것과 같은 이유로 마지막에 로그 형식으로 유지해야합니다 (예 :

진법으로

계산) 보다 인간이 읽을 수 있도록).

\exp

$\exp$

n

$n$

(0, 1)

$(0,1)$

\log

$\log$

10

$10$

— md5 2016 년

IEEE float을 사용하면 곱셈보다 곱셈이 여전히 빠릅니다.이 경우에는 확실합니까? 현대 cpus는 숫자를 곱하는 데 꽤 좋은 반면 float 추가에는 동시에 실행할 수없는 몇 단계가 있습니다-가수를 정렬하고 (빼기 결과에 따라 왼쪽으로 이동) 실제로 추가 한 다음 정규화합니다 (언더 플로우와 트리거를 유발할 수 있음) 오버플로, 예). 회로에서 그것은 많은 다이입니다. 마이크로 코드에서는 각 단계마다 사이클이 필요합니다.

— 존 드보락

"한 번 발생"은 아마도 확률이 이면 있음을 의미합니다 $N$ 다음 각의 로그를 취함으로써 한 번만 공간을 로그로 전환 , (적은 시간이 소요되는)에 추가하여 로그 공간에서 확률의 곱셈을 수행 한 다음 지수를 사용하여 초기 공간으로 다시 전환 할 수 있습니다. $p_1,...p_N$ $p_i$

작업 수가 보다 약간 큰 경우 (성능 관점에서) 로그 공간으로 전환하는 의미가 없다고 생각합니다. 그러나 작업 수가 너무 많으면 로그 공간으로 전환하는 것이 좋습니다. 예를 들어, 50 개의 변수가 있고 계산에 1000 곱셈이 있다고 가정하십시오. 그런 다음 로그 공간에서 작업해야한다고 생각합니다. $N$

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

그건 그렇고,이 아이디어는 Montgomery 모듈 식 곱셈과 유사합니다. 여기서 곱셈은 Montgomery 형식으로 수행되며 일반적인 곱셈보다 축소가 훨씬 빠릅니다.

— 페이드 2 블랙
소스

-1 곱셈에 이차 시간이 걸리지 않습니다 ...

— Mehrdad

@Mehrdad, 나는 두 숫자의 학교 곱셈을 배우기를 바랍니다. 알고리즘은 여전히 컴퓨터 칩에서 널리 사용됩니다. 여기서는 선형 시간보다 여전히 나쁜 소프트웨어 레벨 알고리즘입니다. 이 곱셈 알고리즘은 곱셈 회로 에서처럼 널리 사용됩니까?

— fade2black

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

— Mehrdad 2016 년

대답의 정신은 여전히 옳습니다. 곱셈 알고리즘 중 선형 가산 시간과 일치하는 것이 없다면?

— Stephen

@Stephen, 사실 문제는 곱셈 알고리즘의 정확한 최고의 복잡성에 관한 것이 아닙니다. 의견이 필요한 경우이 주제에 대한 추가 정보를 제공 할 수 있습니다. 나는 그것에 대한 긴 토론이 여기서 논외가 될 것이라고 생각합니다. )))

— fade2black 2016 년