Modulo operatörü (%), C # 'da farklı .NET sürümleri için farklı bir sonuç verir.

Parola dizesi oluşturmak için kullanıcının girişini şifreliyorum. Ancak bir kod satırı, çerçevenin farklı sürümlerinde farklı sonuçlar verir. Kullanıcı tarafından basılan tuş değerine sahip kısmi kod:

Tuşa basıldı: 1. Değişken ascii49'dur. Bazı hesaplamalardan sonra 'e' ve 'n' değeri:

e = 103, 
n = 143,

Math.Pow(ascii, e) % n

Yukarıdaki kodun sonucu:

• .NET 3.5'te (C #)

  Math.Pow(ascii, e) % n
  

  verir 9.0.

• .NET 4'te (C #)

  Math.Pow(ascii, e) % n
  

  verir 77.0.

Math.Pow() her iki versiyonda da doğru (aynı) sonucu verir.

Sebep nedir ve bir çözüm var mı?

Math.Powçift ​​duyarlıklı kayan nokta sayıları üzerinde çalışır; bu nedenle, sonucun ilk 15-17 hanesinden fazlasının doğru olmasını beklememelisiniz :

Tüm kayan noktalı sayıların sınırlı sayıda anlamlı basamağı da vardır, bu aynı zamanda bir kayan nokta değerinin gerçek bir sayıya ne kadar doğru yaklaştığını da belirler. Bir Doubledeğerin 15 ondalık basamağa kadar kesinlik vardır, ancak dahili olarak maksimum 17 basamak korunur.

Bununla birlikte, modulo aritmetiği tüm rakamların doğru olmasını gerektirir. Senin durumda, 49 hesaplıyoruz ¹⁰³ , sonucun, 175 haneden oluşur, hem yanıtlarınıza modülo operasyon anlamsız hale.

Doğru değeri bulmak için, BigIntegersınıf tarafından sağlanan (.NET 4.0'da sunulan) rasgele duyarlıklı aritmetik kullanmanız gerekir .

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

Düzenleme : Aşağıdaki yorumlarda Mark Peters'ın belirttiği gibi, BigInteger.ModPowözellikle bu tür operasyonlar için tasarlanan yöntemi kullanmalısınız :

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

Karma işlevinizin çok iyi bir işlev olmadığı gerçeğinin dışında ^* , kodunuzla ilgili en büyük sorun, .NET sürümüne bağlı olarak farklı bir sayı döndürmesi değil, her iki durumda da tamamen anlamsız bir sayı döndürmesidir: sorunun doğru cevabı

49 ¹⁰³ = 114 (143 mod Wolfram Alpha link )

Bu cevabı hesaplamak için bu kodu kullanabilirsiniz:

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

Hesaplamanızın farklı bir sonuç üretmesinin nedeni, bir cevap üretmek için ⁴⁹¹⁰³ sayısının önemli basamaklarının çoğunu düşüren bir ara değer kullanmanızdır : 175 basamağının yalnızca ilk 16'sı doğrudur!

1230824813134842807283798520430636310264067713738977819859474030746648511411697029659004340261471771152928833391663821316264359104254030819694748088798262075483562075061997649

Kalan 159 hanenin hepsi yanlış. Bununla birlikte mod işlemi, sonuncular da dahil olmak üzere her bir rakamın doğru olmasını gerektiren bir sonuç arar. Bu nedenle, Math.Pow.NET 4'te uygulanmış olabilecek kesinlikteki en ufak bir iyileştirme bile, hesaplamanızda esasen keyfi bir sonuç üreten büyük bir farkla sonuçlanacaktır.

^* Bu soru, parola karması bağlamında tam sayıları yüksek güçlere yükseltmekten bahsettiğinden , mevcut yaklaşımınızın potansiyel olarak daha iyi bir yaklaşım için değiştirilip değiştirilmeyeceğine karar vermeden önce bu yanıt _{bağlantısını} okumak çok iyi bir fikir olabilir .

Gördüğünüz şey ikiye yuvarlama hatasıdır. Math.Powdouble ile çalışır ve fark aşağıdaki gibidir:

.NET 2.0 ve 3.5 => şunu var powerResult = Math.Pow(ascii, e);döndürür:

1.2308248131348429E+174

.NET 4.0 ve 4.5 => şunu var powerResult = Math.Pow(ascii, e);döndürür:

1.2308248131348427E+174

Son basamağa dikkat edin ve Esonuçta farklılığa neden oluyor. Modül operatörü değil (%) .

Kayan nokta hassasiyeti makineden makineye ve hatta aynı makinede değişebilir .

Ancak .NET, uygulamalarınız için sanal bir makine oluşturur ... ancak sürümden sürüme değişiklikler vardır.

Bu nedenle, tutarlı sonuçlar üretmek için ona güvenmemelisiniz. Şifreleme için, kendi sınıfınızı döndürmek yerine Framework'ün sağladığı sınıfları kullanın.

Kodun kötü olma şekliyle ilgili pek çok yanıt var. Ancak sonucun neden farklı olduğuna gelince ...

Intel'in FPU'ları , ara sonuçlar için daha fazla kesinlik elde etmek için dahili olarak 80 bit formatı kullanır . Yani işlemci kaydında bir değer varsa 80 bit alır, ancak yığına yazıldığında 64 bitte depolanır .

NET'in daha yeni sürümünün Tam Zamanında (JIT) derlemesinde daha iyi bir iyileştirici olmasını bekliyorum, bu nedenle bir değeri yığına yazmak ve ardından yığından geri okumak yerine bir kayıt defterinde tutuyor.

JIT artık yığın yerine bir kayıtta bir değer döndürebilir. Veya değeri bir kayıt defterindeki MOD işlevine iletin.

Ayrıca bkz. Yığın Taşması sorusu 80 bitlik genişletilmiş hassas veri türünün uygulamaları / avantajları nelerdir?

Diğer işlemciler, örneğin ARM bu kod için farklı sonuçlar verecektir.

Belki de bunu yalnızca tam sayı aritmetiği kullanarak kendiniz hesaplamak en iyisidir. Gibi bir şey:

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

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

Performansı, diğer yanıtlarda yayınlanan BigInteger çözümünün performansıyla karşılaştırabilirsiniz.