Toán tử modulo (%) đưa ra một kết quả khác cho các phiên bản .NET khác nhau trong C #

Tôi đang mã hóa thông tin đầu vào của người dùng để tạo một chuỗi cho mật khẩu. Nhưng một dòng mã cho các kết quả khác nhau trong các phiên bản khác nhau của khuôn khổ. Mã một phần với giá trị của phím được người dùng nhấn:

Phím được nhấn: 1. Biến asciilà 49. Giá trị của 'e' và 'n' sau một số phép tính:

e = 103, 
n = 143,

Math.Pow(ascii, e) % n

Kết quả của mã trên:

• Trong .NET 3.5 (C #)

  Math.Pow(ascii, e) % n

  cho 9.0.

• Trong .NET 4 (C #)

  Math.Pow(ascii, e) % n

  cho 77.0.

Math.Pow() cho kết quả đúng (giống nhau) trong cả hai phiên bản.

Nguyên nhân là gì, và có giải pháp không?

Math.Powhoạt động trên các số dấu phẩy động có độ chính xác kép; do đó, bạn không nên mong đợi nhiều hơn 15–17 chữ số đầu tiên của kết quả là chính xác:

Tất cả các số dấu phẩy động cũng có một số giới hạn các chữ số có nghĩa, điều này cũng xác định mức độ chính xác của giá trị dấu phẩy động xấp xỉ một số thực. Một Doublegiá trị có độ chính xác lên đến 15 chữ số thập phân, mặc dù tối đa 17 chữ số được duy trì bên trong.

Tuy nhiên, số học modulo yêu cầu tất cả các chữ số phải chính xác. Trong trường hợp của bạn, bạn đang tính 49 ¹⁰³ , có kết quả bao gồm 175 chữ số, làm cho phép toán modulo trở nên vô nghĩa trong cả hai câu trả lời của bạn.

Để tính ra giá trị chính xác, bạn nên sử dụng số học có độ chính xác tùy ý, như được cung cấp bởi BigIntegerlớp (được giới thiệu trong .NET 4.0).

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

Chỉnh sửa : Như đã chỉ ra bởi Mark Peters trong các nhận xét bên dưới, bạn nên sử dụng BigInteger.ModPowphương pháp được dành riêng cho loại hoạt động này:

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

Ngoài thực tế là hàm băm của bạn không phải là một hàm quá tốt ^* , vấn đề lớn nhất với mã của bạn không phải là nó trả về một số khác tùy thuộc vào phiên bản .NET, mà là trong cả hai trường hợp, nó trả về một số hoàn toàn vô nghĩa: câu trả lời chính xác cho vấn đề là

49 ¹⁰³ mod 143 = là 114. ( liên kết tới Wolfram Alpha )

Bạn có thể sử dụng mã này để tính toán câu trả lời này:

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;
}

Lý do tại sao phép tính của bạn tạo ra một kết quả khác là để tạo ra một câu trả lời, bạn sử dụng một giá trị trung gian làm giảm hầu hết các chữ số có nghĩa của số 49 ¹⁰³ : chỉ 16 chữ số đầu tiên trong số 175 chữ số của nó là đúng!

1230824813134842807283798520430636310264067713738977819859474030746648511411697029659004340261471771152928833391663821316264359104254030819694748088798262075483562075061997649

159 chữ số còn lại đều sai. Tuy nhiên, hoạt động mod tìm kiếm một kết quả yêu cầu mọi chữ số đều phải đúng, kể cả những chữ số cuối cùng. Do đó, ngay cả những cải tiến nhỏ nhất về độ chính xác Math.Powcó thể đã được thực hiện trong .NET 4, sẽ dẫn đến sự khác biệt lớn trong phép tính của bạn, về cơ bản tạo ra một kết quả tùy ý.

^* Vì câu hỏi này nói về việc nâng số nguyên lên lũy thừa cao trong bối cảnh băm mật khẩu, nên đọc _{liên kết} câu trả lời này trước khi quyết định xem có nên thay đổi cách tiếp cận hiện tại của bạn để có khả năng tốt hơn hay không.

Những gì bạn thấy là lỗi làm tròn thành đôi. Math.Powhoạt động với double và sự khác biệt như sau:

.NET 2.0 và 3.5 => var powerResult = Math.Pow(ascii, e);trả về:

1.2308248131348429E+174

.NET 4.0 và 4.5 => var powerResult = Math.Pow(ascii, e);trả về:

1.2308248131348427E+174

Chú ý đến chữ số cuối cùng trước đó Evà điều đó gây ra sự khác biệt trong kết quả. Nó không phải là toán tử mô-đun (%) .

Độ chính xác của dấu chấm động có thể khác nhau giữa các máy và thậm chí trên cùng một máy .

Tuy nhiên, .NET tạo một máy ảo cho các ứng dụng của bạn ... nhưng có những thay đổi giữa các phiên bản.

Vì vậy, bạn không nên dựa vào nó để tạo ra kết quả nhất quán. Để mã hóa, hãy sử dụng các lớp mà Framework cung cấp thay vì sử dụng các lớp của riêng bạn.

Có rất nhiều câu trả lời về cách code xấu. Tuy nhiên, tại sao kết quả lại khác…

FPU của Intel sử dụng định dạng 80-bit bên trong để có được độ chính xác hơn cho các kết quả trung gian. Vì vậy, nếu một giá trị nằm trong thanh ghi bộ xử lý, nó sẽ nhận được 80 bit, nhưng khi nó được ghi vào ngăn xếp, nó sẽ được lưu trữ ở 64 bit .

Tôi hy vọng rằng phiên bản mới hơn của .NET có trình tối ưu hóa tốt hơn trong quá trình biên dịch Just in Time (JIT), vì vậy nó đang giữ một giá trị trong một thanh ghi thay vì ghi nó vào ngăn xếp và sau đó đọc lại từ ngăn xếp.

Có thể JIT bây giờ có thể trả về một giá trị trong một thanh ghi thay vì trên ngăn xếp. Hoặc chuyển giá trị cho hàm MOD trong một thanh ghi.

Xem thêm Câu hỏi Tràn ngăn xếp Các ứng dụng / lợi ích của kiểu dữ liệu chính xác mở rộng 80-bit là gì?

Các bộ xử lý khác, ví dụ như ARM sẽ đưa ra các kết quả khác nhau cho mã này.

Có lẽ tốt nhất là bạn nên tự mình tính toán nó bằng cách chỉ sử dụng số học số nguyên. Cái gì đó như:

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

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

Bạn có thể so sánh hiệu suất với hiệu suất của giải pháp BigInteger được đăng trong các câu trả lời khác.