El operador de módulo (%) da un resultado diferente para diferentes versiones de .NET en C #

Estoy encriptando la entrada del usuario para generar una cadena de contraseña. Pero una línea de código da diferentes resultados en diferentes versiones del marco. Código parcial con valor de tecla presionada por usuario:

Tecla presionada: 1. La variable asciies 49. Valor de 'e' y 'n' después de algún cálculo:

e = 103, 
n = 143,

Math.Pow(ascii, e) % n

Resultado del código anterior:

• En .NET 3.5 (C #)

  Math.Pow(ascii, e) % n

  da 9.0.

• En .NET 4 (C #)

  Math.Pow(ascii, e) % n

  da 77.0.

Math.Pow() da el resultado correcto (el mismo) en ambas versiones.

¿Cuál es la causa? ¿Existe una solución?

Math.Powtrabaja con números de coma flotante de doble precisión; por lo tanto, no debe esperar que más de los primeros 15 a 17 dígitos del resultado sean precisos:

Todos los números de punto flotante también tienen un número limitado de dígitos significativos, lo que también determina la precisión con la que un valor de punto flotante se aproxima a un número real. Un Doublevalor tiene hasta 15 dígitos decimales de precisión, aunque internamente se mantiene un máximo de 17 dígitos.

Sin embargo, la aritmética de módulo requiere que todos los dígitos sean precisos. En su caso, está calculando ⁴⁹¹⁰³ , cuyo resultado consta de 175 dígitos, lo que hace que la operación de módulo no tenga sentido en ambas respuestas.

Para calcular el valor correcto, debe usar aritmética de precisión arbitraria, como lo proporciona la BigIntegerclase (introducida en .NET 4.0).

int val = (int)(BigInteger.Pow(49, 103) % 143);   // gives 114

Editar : Como señaló Mark Peters en los comentarios a continuación, debe usar el BigInteger.ModPowmétodo, que está diseñado específicamente para este tipo de operación:

int val = (int)BigInteger.ModPow(49, 103, 143);   // gives 114

Aparte del hecho de que su función hash no es muy buena ^* , el mayor problema con su código no es que devuelve un número diferente dependiendo de la versión de .NET, sino que en ambos casos devuelve un número completamente sin sentido: la respuesta correcta al problema es

49 ¹⁰³ mod 143 = es 114. ( enlace a Wolfram Alpha )

Puede usar este código para calcular esta respuesta:

private static int PowMod(int a, int b, int mod) {
    if (b == 0) {
        return 1;
    }
    var tmp = PowMod(a, b/2, mod);
    tmp *= tmp;
    if (b%2 != 0) {
        tmp *= a;
    }
    return tmp%mod;
}

La razón por la que su cálculo produce un resultado diferente es que para producir una respuesta, usa un valor intermedio que elimina la mayoría de los dígitos significativos del número ⁴⁹¹⁰³ : ¡solo los primeros 16 de sus 175 dígitos son correctos!

1230824813134842807283798520430636310264067713738977819859474030746648511411697029659004340261471771152928833391663821316264359104254030819694748088798262075483562075061997649

Los 159 dígitos restantes están mal. Sin embargo, la operación de modificación busca un resultado que requiera que todos los dígitos sean correctos, incluidos los últimos. Por lo tanto, incluso la más mínima mejora en la precisión de Math.Poweso puede haberse implementado en .NET 4, daría como resultado una diferencia drástica de su cálculo, que esencialmente produce un resultado arbitrario.

^* Dado que esta pregunta habla de aumentar los números enteros a poderes altos en el contexto del hash de contraseñas, puede ser una muy buena idea leer este _{enlace de} respuesta antes de decidir si su enfoque actual debe cambiarse por uno potencialmente mejor.

Lo que ves es un error de redondeo al doble. Math.Powfunciona con doble y la diferencia es la siguiente:

.NET 2.0 y 3.5 => var powerResult = Math.Pow(ascii, e);devuelve:

1.2308248131348429E+174

.NET 4.0 y 4.5 => var powerResult = Math.Pow(ascii, e);devuelve:

1.2308248131348427E+174

Observe el último dígito antes Ey eso está causando la diferencia en el resultado. No es el operador de módulo (%) .

La precisión del punto flotante puede variar de una máquina a otra, e incluso en la misma máquina .

Sin embargo, .NET crea una máquina virtual para sus aplicaciones ... pero hay cambios de una versión a otra.

Por lo tanto, no debe confiar en él para producir resultados consistentes. Para el cifrado, utilice las clases que proporciona Framework en lugar de utilizar las suyas propias.

Hay muchas respuestas sobre la forma en que el código es malo. Sin embargo, en cuanto a por qué el resultado es diferente ...

Las FPU de Intel utilizan el formato de 80 bits internamente para obtener más precisión en los resultados intermedios. Entonces, si un valor está en el registro del procesador, obtiene 80 bits, pero cuando se escribe en la pila, se almacena en 64 bits. .

Espero que la versión más nueva de .NET tenga un mejor optimizador en su compilación Just in Time (JIT), por lo que mantiene un valor en un registro en lugar de escribirlo en la pila y luego leerlo de la pila.

Puede ser que el JIT ahora pueda devolver un valor en un registro en lugar de en la pila. O pase el valor a la función MOD en un registro.

Consulte también la pregunta de desbordamiento de pila ¿ Cuáles son las aplicaciones / beneficios de un tipo de datos de precisión extendida de 80 bits?

Otros procesadores, por ejemplo, el ARM, darán resultados diferentes para este código.

Tal vez sea mejor calcularlo usted mismo usando solo aritmética de números enteros. Algo como:

int n = 143;
int e = 103;
int result = 1;
int ascii = (int) 'a';

for (i = 0; i < e; ++i) 
    result = result * ascii % n;

Puede comparar el rendimiento con el rendimiento de la solución BigInteger publicada en las otras respuestas.