multiplicação modular

Eu estava lendo a página Modular Multiplication na wikipedia ... e não conseguia entender o algoritmo para calcular $a \cdot b \pmod{m}$ .

uint64_t mul_mod(uint64_t a, uint64_t b, uint64_t m)
{
  long double x;
  uint64_t c;
  int64_t r;
  if (a >= m) a %= m;
  if (b >= m) b %= m;
  x = a;
  c = x * b / m;
  r = (int64_t)(a * b - c * m) % (int64_t)m;
  return r < 0 ? r + m : r;
}

Entendi:

a \cdot b (\mod m) \equiv ((a \mod m) \cdot (b \mod m)) \mod m

$a \cdot b \pmod{m} \equiv ((a \mod{m}) \cdot (b \mod{m})) \mod{m}$

o passo que eu não consegui é c=x*b/me depois fazer o r = (int64_t)(a * b - c * m) % (int64_t)m;que é isso?

O artigo diz:

empregando o truque que, por hardware, a multiplicação de ponto flutuante resulta nos bits mais significativos do produto mantidos, enquanto a multiplicação inteira resulta nos bits menos significativos mantidos

Não vejo como isso está relacionado !!!

algorithm-analysis modular-arithmetic

— usuário -1
fonte

Aqui está uma descrição mais compacta e matemática do que está acontecendo. Deixe e ser a entrada, já reduzido módulo , de modo que e . (Em termos de código, isso significa depois da linha.) Queremos calcular , ou seja, definindo , queremos encontrar modo que para alguns . $a$ $b$ $m$ $a < m$ $b < m$ b %= m $ab \mod m$ $x=ab$ $r_x$ $x = q_xm + r_x$ $q_x$

O caso não transbordante

No caso de não transbordar, poderíamos apenas calcular o módulo e concluir com ele. Em vez disso, o código calcula: Agora . Eu elidei uma preocupação aqui, no entanto. Pode ser que não se encaixe na mantissa da nossa variável de ponto flutuante. Enquanto se encaixar, no entanto, isso não será um problema, pois . Terminaremos com onde é algum erro de arredondamento cuja magnitude é menor que . Prosseguimos como antes:

y = ⌊ \frac{x}{m} ⌋ = ⌊ q_{x} + \frac{r_{x}}{m} ⌋ = q_{x} + ⌊ \frac{r_{x}}{m} ⌋ = q_{x}

$y = \left\lfloor\frac{x}{m}\right\rfloor = \left\lfloor q_x + \frac{r_x}{m}\right\rfloor = q_x + \left\lfloor\frac{r_x}{m}\right\rfloor = q_x$

x - y m = q_{x} m + r_{x} - q_{x} m = r_{x}

$x - ym = q_xm + r_x - q_xm = r_x$

x

$x$

m

$m$

x = a b < m^{2}

$x = ab < m^2$

x^{'} = x + e

$x' = x + e$

e

$e$

m

$m$

y = ⌊ \frac{x^{'}}{m} ⌋ = ⌊ q_{x} + \frac{r_{x} + e}{m} ⌋ = q_{x} + ⌊ \frac{r_{x} + e}{m} ⌋

$y = \left\lfloor\frac{x'}{m}\right\rfloor = \left\lfloor q_x + \frac{r_x+e}{m}\right\rfloor = q_x + \left\lfloor\frac{r_x+e}{m}\right\rfloor$ neste caso, não podemos eliminar a porque, enquanto e , pode ser que ou , embora certamente esteja (estritamente) entre e , então é ou . Agora

⌊ \frac{r_{x} + e}{m} ⌋

$\left\lfloor\frac{r_x+e}{m}\right\rfloor$

r_{x} < m

$r_x < m$

e < m

$e < m$

r_{x} + e > m

$r_x+e > m$

r_{x} + e < 0

$r_x+e < 0$

- m

$-m$

2 m

$2m$

⌊ \frac{r_{x} + e}{m} ⌋

$\left\lfloor\frac{r_x+e}{m}\right\rfloor$

0

$0$

\pm 1

$\pm1$

x - y m = q_{x} m + r_{x} - q_{x} m - ⌊ \frac{r_{x} + e}{m} ⌋ m = r_{x} - ⌊ \frac{r_{x} + e}{m} ⌋ m

$x - ym = q_x m + r_x - q_x m - \left\lfloor\frac{r_x+e}{m}\right\rfloor m = r_x - \left\lfloor\frac{r_x+e}{m}\right\rfloor m$ A execução da operação do módulo agora se livrará desse termo extra, no entanto, devido à convenção que C escolher (-1)%m = -1,. Para obter uma convenção em que sempre retornamos um número positivo, podemos adicionar ao resultado, se negativo.

m

$m$

O caso transbordante

Vamos assumir que estamos fazendo o inteiro aritmético mod , por exemplo, , e vamos assumir que significa . Agora a multiplicação vai terminar. Escreveremos para um número inteiro . Isso significa que o cálculo dará o número . O cálculo do ponto flutuante é como antes assumindo, novamente, que se encaixa na mantissa (o que pode exigir flutuações de precisão estendidas de 80 bits para maior ). Para o módulo, defina e então $N$ $2^{64}$ $ab > N$ $m^2 > N > m$ $x = ab = z + kN$ $k < m$ a*b $z$ $m$ $m$ $z = q_z m + r_z$ $kN = q_N m + r_N$ $x = q_z m + q_N m + r_z + r_N$ . Como antes, armazenar como uma variável de ponto flutuante pode produzir algum erro de arredondamento , de novo, tenha . Se fizermos o mesmo cálculo que antes, parece: Eu tirei um coelho do chapéu aqui. Aqui, estamos adicionando o mod e o mod então . Como antes, modificamos por para obter $x$ $|e| < m$ $x' = x + e$

\begin{aligned} z - ⌊ \frac{x^{'}}{m} ⌋ m & = q_{z} m + r_{z} - q_{z} m - q_{N} m - ⌊ \frac{r_{z} + r_{N} + e}{m} ⌋ m \\ = r_{z} - q_{N} m - ⌊ \frac{r_{z} + r_{N} + e}{m} ⌋ m \\ = r_{z} + r_{N} - ⌊ \frac{r_{z} + r_{N} + e}{m} ⌋ m \end{aligned}

$\begin{align} z - \left\lfloor\frac{x'}{m}\right\rfloor m & = q_zm + r_z - q_z m - q_N m - \left\lfloor\frac{r_z+r_N+e}{m}\right\rfloor m \\ & = r_z - q_N m - \left\lfloor\frac{r_z+r_N+e}{m}\right\rfloor m \\ & = r_z + r_N - \left\lfloor\frac{r_z+r_N+e}{m}\right\rfloor m \\ \end{align}$

N

$N$

N

$N$

q_{N} m + r_{N} = k N = 0

$q_N m + r_N = kN = 0$

q_{N} m = - r_{N}

$q_N m = -r_N$

m

$m$

r_{z} + r_{N} = x \mod m

$r_z + r_N = x \mod m$ , e, como antes, a convenção C pode levar a que isso seja negativo, o que precisará ser corrigido.

Há um possível problema restante. pode ser . Isso não causa nenhum problema, a menos que , nesse caso, você obtenha a resposta errada. Para isso significa . (Além disso, se não causa nenhum problema, pois terminaremos com ). Se configurarmos o hardware de ponto flutuante para arredondar para que , esse caso não será exibido. (Embora não esqueça a minha restrição de que a mantissa pode aguentar !). $\left\lfloor\frac{r_z+r_N+e}{m}\right\rfloor$ $2$ $2m > N$ $N = 2^{64}$ $m > 2^{63}$ $2m = N$ $0$ $e \leq 0$ $m$

Conectando isso aos bits mais / menos significativos

Para abordar especificamente a parte que você citou, considere um número inteiro, , maior que 2, que consideraremos como base, como na "base ". No caso usual de , o número é representado como . Em uma representação de ponto flutuante, escreveríamos isso como . Agora, digamos que queremos multiplicar dois números (positivos) de um dígito base , o resultado exigiria no máximo dois dígitos, digamos onde (conforme exigido por uma representação [padrão] base ) e . Se estivermos restritos a apenas poder armazenar uma base, $B$ $10$ $B=10$ $21$ $21 = 2B+1$ $2.1\times B^1$ $B$ $cB+d$ $B$ $0 \leq c < B$ $0\leq d < B$ $B$ dígito do resultado, existem duas opções óbvias, ou . $c$ $d$

Escolher é equivalente a trabalhar com o mod como , é o que acontece com a aritmética inteira. (Aliás, no nível da montagem, a multiplicação inteira geralmente produz esses dois dígitos.) $d$ $B$ $cB + d = d\mod B$

A aritmética de ponto flutuante, por outro lado, corresponde efetivamente à escolha , mas compensando isso incrementando o expoente. Com efeito, representamos o resultado como mas como podemos armazenar apenas um dígito base- , isso se torna apenas . (Na prática, consideraremos números como números de vários dígitos em uma base pequena (ou seja, 2), em vez de números de 1 ou 2 dígitos em uma base grande. Isso nos permite salvar alguns dos dígitos mais altos de se eles não são necessários para armazenar , mas no pior cenário de todos está perdido. Nenhum de $c$ $c.d\times B^1$ $B$ $c\times B^1$ $d$ $c$ $d$ $c$ é perdido até começarmos a ficar sem espaço no expoente. Para o código acima, isso não é um problema.)

Desde que possa ser representado fielmente no formato de ponto flutuante, a expressão pode ser vista como uma extração desse dígito superior na base . É possível ver o código e matemática acima como a interacção entre a base- e base- representações de um número. $m$ $\left\lfloor\frac{ab}{m}\right\rfloor$ $m$ $N$ $m$

Praticidades

Com base na seção 5.2.4.2.2 deste rascunho , o padrão C11 parece exigir apenas long doubleuma mantissa de aproximadamente 33 bits de comprimento. (Em particular, parece especificar apenas o número mínimo de dígitos decimais que podem ser fielmente representados.) Na prática, a maioria dos compiladores C ao direcionar-se a CPUs de uso geral e, principalmente, à família da família x86, usará os tipos IEEE754. Nesse caso, doubleterá efetivamente uma mantissa de 53 bits. As CPUs da família x86 suportam um formato de 80 bits com uma mantissa com efetivamente 64 bits, e vários, mas nem todos os compiladores long doubleindicam isso ao direcionar o x86. O intervalo de validade do código depende desses detalhes de implementação.

— Derek Elkins deixou o SE
fonte

Excelente resposta! Um caso em que ainda estou coçando a cabeça: suponha que seja tão negativo que . Então o valor de será e, portanto, no intervalo . Suponha que esse valor seja . Em seguida, a conversão para (um tipo assinado) fará com que ela seja convertida em um número negativo. Por que o código faz a coisa certa neste caso? Em particular, torna-se após a conversão para (se fosse ) e, em seguida, a operação -e-make-positive deve produzir , em vez de

e

$e$

r_{x} + e < 0

$r_x+e < 0$ a*b - c*m

r_{x} + m

$r_x+m$

m . .2 m - 1

$m..2m-1$

\geq 2^{63}

$\ge 2^{63}$ int64_t

r_{x} + m

$r_x + m$

r_{x} + m - 2^{64}

$r_x+m - 2^{64}$ int64_t

\geq 2^{63}

$\ge 2^{63}$ %m

r_{x} - 2^{64} mod m

$r_x - 2^{64} \bmod m$

r_{x}

$r_x$ . (cont.)

— DW

Ainda não encontrei um caso de teste que desencadeie esse comportamento. Em particular, não é possível encontrar nenhum valores para a, b, monde e em que o valor do é , isto é, onde e . Esse caso pode acontecer? Se puder, por que esse código fornece o resultado certo nessa situação?

r_{x} + e < 0

$r_x+e<0$ a*b - c*m

\geq 2^{63}

$\ge 2^{63}$

r_{x} + e < 0

$r_x+e<0$

r_{x} + m \geq 2^{63}

$r_x + m \ge 2^{63}$

— DW

Depois de tentar 1 bilhão de valores aleatórios, não consigo encontrar nenhum caso de teste que satisfaça essas condições. Então, talvez este caso seja impossível? Mas por que?

— DW

Concordo que também não tenho certeza do que acontece nas extremidades. Neste caso, temos , e portanto o intervalo de é de a inclusive. Como isso não causa problemas nos casos , , . No entanto, não temos portanto, se podemos ter problemas, por exemplo, se para . Não sei se vai

0 \leq r_{z} < m

$0 \leq r_z < m$

0 \leq r_{N} < m

$0 \leq r_N < m$

| e | < m

$|e| < m$

⌊ \frac{r_{z} + r_{N} + e}{m} ⌋

$\left\lfloor\frac{r_z+r_N+e}{m}\right\rfloor$

- 1

$-1$

2

$2$

m < N

$m < N$

- 1

$-1$

0

$0$

1

$1$

2 m < N

$2m < N$

m \geq N / 2

$m \geq N/2$

m \geq 2^{63}

$m \geq 2^{63}$

N = 2^{64}

$N = 2^{64}$ tem problemas; Eu acredito que sim. Por outro lado, se o modo de arredondamento estiver definido para arredondar para baixo, teremos e acho que funciona até .

e \leq 0

$e \leq 0$

m = N - 1

$m = N-1$

— Derek Elkins saiu de SE

Obrigado pela edição e pelo comentário. No entanto, ainda não vejo como isso resolve o caso de que estou falando. O caso que me preocupa é onde é e onde (para que o elenco produza um resultado negativo número). Seu comentário diz que não há problemas no caso , mas não entendo o porquê; é exatamente nesse caso que estou preocupado. Eu considerei os modos de arredondamento, mas, pelo que sei, parece que o modo de arredondamento padrão é "arredondado para o par", não "arredondado para baixo", de modo que isso não parece resolver o problema.

⌊ \frac{r_{z} + r_{N} + e}{m} ⌋

$\lfloor {r_z+r_N+e \over m} \rfloor$

- 1

$-1$

r_{z} + r_{N} + m \geq 2^{63}

$r_z+r_N+m \ge 2^{63}$ int64_t

- 1

$-1$

— DW