“Bazı test davalarını dene” buluşunu nasıl kandırabilirim: Doğru görünen fakat aslında yanlış olan algoritmalar

Bazı problemler için bir algoritmanın doğru olup olmadığını test etmek için, normal başlangıç ​​noktası algoritmayı bir dizi basit test durumunda elle çalıştırmayı denemek - birkaç basit "köşe durumu" da dahil olmak üzere birkaç örnek problem örneğinde deneyiniz. ". Bu harika bir buluşsal yöntemdir: Bir algoritmada birçok yanlış girişimi hızlı bir şekilde ayıklamak ve algoritmanın neden işe yaramadığını anlamak için harika bir yoldur.

Bununla birlikte, algoritmaları öğrenirken, bazı öğrenciler orada durma eğilimindedir: eğer algoritmaları denemeyi düşünebilecekleri tüm köşe vakaları da dahil olmak üzere birkaç örnek üzerinde doğru çalışıyorsa, algoritmanın doğru olması gerektiği sonucuna varırlar. Her zaman şunu soran bir öğrenci vardır: "Birkaç test vakasında deneyebilirsem neden algoritmamı doğrulamam gerekiyor?"

Öyleyse, "bir avuç test vakasını dene" buluşsalını nasıl kandırıyorsun? Bu buluşsal yöntemin yeterli olmadığını göstermek için bazı güzel örnekler arıyorum. Başka bir deyişle, yüzeysel olarak doğru gibi görünen ve algoritmanın gerçekte nerede olacağı, ancak algoritmanın gerçekte olduğu küçük girişlerin hepsine doğru cevabı veren bir algoritma örneği arıyorum. çalışmıyor Belki de algoritma tüm küçük girişlerde doğru bir şekilde çalışıyor ve sadece büyük girişler için başarısız oluyor veya sadece alışılmadık bir düzende girişler için başarısız oluyor.

Özellikle, ben arıyorum:

1. Bir algoritma. Kusur algoritmik seviyede olmalıdır. Uygulama hataları aramıyorum. (Örneğin, en azından, örnek dilin agnostik olması ve kusur, yazılım mühendisliği veya uygulama konularından ziyade algoritmik endişelerle ilgili olmalıdır.)

2. Birisinin makul bir şekilde bulabileceği bir algoritma. Sahte kod en azından makul bir şekilde doğru görünmelidir (ör. Gizlenmiş veya açıkça şüpheli olan kod iyi bir örnek değildir). Bonus, bir öğrencinin bir ev ödevi veya sınav problemini çözmeye çalışırken gerçekten ortaya çıkardığı bir algoritma ise puan.

3. Yüksek olasılıkla makul bir manuel test stratejisini geçebilecek bir algoritma. Birkaç küçük test vakasını elle deneyen birinin bu hatayı keşfetmesi mümkün olmamalıdır. Örneğin, "QuickCheck'i bir düzine küçük test durumunda el ile simüle edin", algoritmanın yanlış olduğunu ortaya koyması olası değildir.

4. Tercihen, deterministik bir algoritma. Bir çok öğrencinin “bazı test vakalarını el ile dene” nin, deterministik bir algoritmanın doğru olup olmadığını kontrol etmenin makul bir yolu olduğunu düşündüğümü gördüm, ancak çoğu öğrencinin birkaç test senaryosunu denemenin olasılıkları doğrulamak için iyi bir yol olduğunu varsaymayacağını düşünüyorum. algoritmaları. Olasılıklı algoritmalar için, herhangi bir özel çıkışın doğru olup olmadığını söylemenin bir yolu yoktur; ve çıktı dağılımı üzerinde faydalı bir istatistiksel test yapmak için yeterli örneği elle veremezsiniz. Bu yüzden, öğrenci yanılgılarının kalbine daha net bir biçimde yaklaşırken deterministik algoritmalara odaklanmayı tercih ederim.

Algoritmanızın doğru olduğunu kanıtlamanın önemini öğretmek istiyorum ve doğruluk kanıtlarını motive etmek için buna benzer birkaç örnek kullanmayı umuyorum. Lisans öğrencileri için nispeten basit ve erişilebilir örnekleri tercih ediyorum; ağır makine veya bir ton matematiksel / algoritmik arka plan gerektiren örnekler daha az yararlıdır. Ayrıca, "doğal olmayan" algoritmalar istemiyorum; Sezgisel kandırmak için bazı garip yapay algoritmalar oluşturmak kolay olsa da, eğer oldukça doğal görünmüyorsa veya sadece bu sezgisel kandırmak için yapılmış açık bir arka kapı varsa, muhtemelen öğrencileri ikna etmeyecektir. İyi örnekler var mı?

Bence yaygın bir hata, her zaman doğru yaklaşım olmayan açgözlü algoritmaları kullanmaktır, ancak çoğu test durumunda işe yarayabilir.

Örnek: Para mezhepler ve bir sayı , ifade toplamı olarak : s mümkün olduğunca az paralar ile. n n d $d_1,\dots,d_k$$n$$n$$d_i$

Saf bir yaklaşım ilk önce mümkün olan en büyük madeni parayı kullanmak ve iştahla böyle bir miktar üretmek.

Örneğin, , ve değerine sahip sikkeler, sayıları hariç ile arasındaki tüm sayılar için açgözlü cevaplar verecektir .5 1 1 $6$$5$$1$$1$$14$$10 = 6+1+1+1+1 = 5+5$

Hemen R. Backhouse'dan bir örnek hatırladım (bu onun kitaplarından birinde olmuş olabilir). Görünüşe göre, öğrencilerin iki dizenin eşitliğini test etmek için bir Pascal programı yazması gereken bir programlama ödevi vermişti. Bir öğrenci tarafından başlatılan programlardan biri şuydu:

issame := (string1.length = string2.length);

if issame then
  for i := 1 to string1.length do
    issame := string1.char[i] = string2.char[i];

write(issame);

Şimdi programı aşağıdaki girdilerle test edebiliriz:

"üniversite" "üniversite" Doğru; tamam$\Rightarrow$

"course" "course" Doğru; tamam$\Rightarrow$

"" "" Doğru; tamam$\Rightarrow$

"üniversite" "ders" Yanlış; tamam$\Rightarrow$

"ders", "ders" Yanlış; tamam$\Rightarrow$

"kesinlik" "kesinlik" False, OK$\Rightarrow$

Bütün bunlar çok umut verici görünüyor: belki de program gerçekten işe yarıyor. Ancak "saf" ve "gerçek" olarak yapılan daha dikkatli bir test, hatalı çıktı olduğunu ortaya çıkarır. Aslında, dizeleri aynı uzunlukta ve aynı son karaktere sahipse, program "Doğru" diyor!

Bununla birlikte, testler oldukça kapsamlıydı: farklı uzunluktaki, eşit uzunluktaki, farklı içerikteki ve hatta eşit dizgelere sahipti. Ayrıca, öğrenci her dalını bile test etmiş ve uygulamıştır. Testin burada dikkatsiz olduğunu iddia edemezsiniz - program gerçekten çok basit olduğu için, yeterince test etmek için motivasyon ve enerjiyi bulmak zor olabilir.

Başka bir sevimli örnek ikili aramadır. TAOCP'da Knuth, "ikili arama temel fikri oldukça basit olmasına rağmen, ayrıntıların şaşırtıcı derecede zor olabileceğini" söylüyor. Görünüşe göre, Java ikili arama uygulamasında bir hata on yıl boyunca farkedilmeden gitti. Bir tamsayı taşması hatasıydı ve yalnızca yeterince büyük girdiyle tezahür etti. İkili arama uygulamalarının zor detayları aynı zamanda Bentley tarafından Programming Pearls kitabında ele alınmıştır .

Alt satır: İkili bir arama algoritmasının sadece test ederek doğru olduğundan emin olmak şaşırtıcı derecede zor olabilir.

Karşılaştığım en iyi örnek, ilkellik testi.

giriş: doğal sayı p, p! = 2
çıktı: pa asal mı değil mi?
algoritma: hesaplama 2 ** (p-1) mod p. Sonuç = 1 ise, p asaldır, p değildir.

Bu, çok az sayıda karşı örnek hariç her sayı için (neredeyse) çalışır ve bir gerçekte gerçekçi bir zaman diliminde bir karşı örnek bulmak için bir makineye ihtiyaç duyulur. İlk karşı örnek 341'dir ve karşı örneklerin yoğunluğu aslında yaklaşık olarak logaritmik olmasına rağmen artan p ile azalmaktadır.

Gücün temeli olarak sadece 2 kullanmak yerine, önceki üssün 1 döndüğü durumlarda baz olarak ek, artan küçük asallar kullanarak da algoritma geliştirilebilir. Yine de, bu şemaya karşı bir örnek vardır, yani Carmichael sayıları, Yine de oldukça nadir

İşte ben gittim bir kongre google reps tarafından bana atılan biri. C olarak kodlandı, ancak referans kullanan diğer dillerde çalışıyor. [Cs.se] kodunu girdiğim için üzgünüm, ancak bunu açıklayan tek kişi bu.

swap(int& X, int& Y){
    X := X ^ Y
    Y := X ^ Y
    X := X ^ Y
}

Bu algoritma, aynı değerde olsalar bile, x ve y'ye verilen değerler için çalışacaktır. Ancak, takas (x, x) olarak adlandırılırsa çalışmaz. Bu durumda, x 0 olarak sona erer. Şimdi, bu sizi tatmin etmeyebilir, çünkü bir şekilde bu işlemin matematiksel olarak doğru olduğunu ispatlayabilirsiniz, ancak yine de bu uç durumu unutabilirsiniz.

Sahte olarak test etmesi zor olan bir algoritma sınıfı var: sözde rasgele sayı üreteçleri . Tek bir çıktıyı test edemezsiniz ancak bir çok çıktı grubunu istatistiklerle araştırmanız gerekir. Neyi ve nasıl test ettiğinize bağlı olarak, rastgele olmayan özellikleri de kaçırabilirsiniz.

İşlerin feci şekilde yanlış gittiği meşhur bir vaka RANDU'dur . O sırada mevcut olan incelemeyi geçti - ki bu sonraki çıktıların tuple davranışını göz önünde bulundurmadı . Zaten üçlüler çok sayıda yapı gösteriyor:

Temel olarak, testler tüm kullanım durumlarını kapsamıyordu: RANDU'nun tek boyutlu kullanımı (muhtemelen çoğunlukla) iyi olsa da, üç boyutlu noktaları örneklemek için kullanmayı (bu şekilde) desteklemiyordu.

Doğru sözde rasgele örnekleme, zor bir iştir. Neyse ki, orada günlerde güçlü test paketleri var, örneğin, önerilen bir jeneratörde bildiğimiz tüm istatistikleri atmakta uzmanlaşmış bir kalıp kesici . Yeterli mi?

^{Adil olmak gerekirse, PRNG'ler için ne yapılabilir kanıtlar elde edebileceğinizi bilmiyorum.}

2B yerel maksimum

$n \times n$$A$

$(i,j)$$A[i,j]$

$A[i, j+1], A[i, j-1], A[i-1, j], A[i+1, j]$$A$

daha sonra her kalın hücre yerel bir maksimumdur. Boş olmayan her dizinin en az bir yerel maksimumu vardır.

$O(n^2)$

$A$$X$$X$$A$$(i, j)$$X$$(i, j)$$(i', j')$

$A \setminus X$$A$( ı ′ , j ′ ) A $X$$(i', j')$$A'$

Lemma. Çeyrek yerel maksimum .$A'$$A$

Kanıt. Hücrede başlamayı düşünün . Yerel bir maksimum değilse, daha büyük bir değere sahip bir komşuya gidin. Bu, yerel bir maksimum olan bir hücreye ulaşana kadar tekrar edilebilir. Bu son hücrenin olması gerekir , çünkü her tarafa değerleri hücrenin değerinden daha küçük olan hücreler . Bu lemmayı kanıtlar. A ′ A ′ ( i ′ , j ′ ) $(i', j')$$A'$$A'$$(i', j')$$\diamond$

Algoritma, kendisini yerel olarak bir maksimum bulmak için alt dizi da tekrarlı olarak çağırır ve daha sonra o hücreyi döndürür.$\frac{n}{2}\times\frac{n}{2}$$A'$$(i, j)$

Bir matrisi için çalışma süresi, karşılar , bu nedenle . $T(n)$$n\times n$$T(n) = T(n/2) + O(n)$$T(n) = O(n)$

Böylece, aşağıdaki teoremi ispatladık:

Teorem. Bir vardır , bir yerel-en fazla bulmak için -zaman algoritma dizi.$O(n)$$n\times n$

Yoksa biz mi?

Bunlar ilkel örneklerdir, çünkü bunlar yaygındır.

(1) SymPy'deki asallık. Sayı 1789 . Tanınmış bir web sitesine, 10 ^ 14’ten sonraya kadar başarısız olmayan yanlış bir test yapıldı. Düzeltme doğru olsa da, konuyu yeniden düşünmek yerine sadece yamaları deliyordu.

(2) Perl 6'daki primallik. Perl6, sabit tabanlı bir dizi MR testi kullanan asal bir özellik ekledi. Bilinen karşı örnekler var, ancak varsayılan test sayısı çok büyük olduğu için oldukça büyükler (temel olarak performansı düşürerek asıl sorunu gizliyorlar). Bu yakında ele alınacak.

(3) FLINT’de ilkellik. n_isprime () düzeltildiğinden beri kompozitler için true değerini döndürüyor . Temelde SymPy ile aynı konu. SPRP-2 psödoprimlerinin Feitsma / Galway veritabanını 2 ^ 64'e kullanarak şimdi bunları test edebiliriz.

(4) Perl's Math :: Primality. is_aks_prime bozuk . Bu sekans, birçok AKS uygulamasına benziyor - ya kazayla çalışan (örneğin 1. adımda kaybedilen ve her şeyi deneme bölümünde yaparak bitiren) ya da daha büyük örnekler için işe yaramayan birçok kod. Ne yazık ki AKS o kadar yavaş ki test etmek zor.

(5) Pari'nin 2.2 öncesi isprime. Matematik :: Pari bileti . MR testleri için 10 rasgele baz kullandı (GMP'nin her çağrısında sabit tohum yerine başlangıçta sabit tohum ile). Size 9 her 1M aramadan 1'i hakkında asal olduğunu söyleyecektir. Doğru sayıyı seçerseniz göreceli olarak sık sık başarısız olmasına neden olabilirsiniz, ancak sayılar daha seyrekleşir, bu yüzden pratikte pek görünmez. O zamandan beri algoritmayı ve API'yi değiştirdiler.

Bu yanlış değil ama olasılık testlerinden geçiyor: Kaç tur atıyorsunuz, mpz_probab_prime_p? 5 tur verirsek, iyi sonuç verir gibi görünüyor - sayıların bir temel 210 Fermat testini geçmesi ve ardından önceden seçilmiş 5 temel Miller-Rabin testini geçmesi gerekiyor. 3892757297131 (GMP 5.0.1 veya 6.0.0a ile) kadar bir karşı örnek bulamayacaksınız, bu yüzden bulmak için çok fazla test yapmanız gerekecek. Fakat 2 ^ 64'ün altında binlerce karşı örnek var. Yani sayıyı yükseltiyorsun. Ne kadar uzak? Bir rakip var mı? Doğru cevap ne kadar önemlidir? Rasgele tabanları sabit tabanlarla karıştırıyor musunuz? Hangi giriş boyutlarında verileceğini biliyor musunuz?

İlişkili bir nokta var: Büyük sayı nedir? Öğrencilere göre pek çok kişi 10.000'in çok büyük olduğunu düşünüyor . Birçok programcı için büyük bir sayıdır. Kriptografi üzerine çalışan programcılar için bunlar küçük ve büyük, 4096 bit demek. Hesaplamalı sayı teorisi üzerinde çalışan programcılar için, hepsi küçük ve büyük 10 ila 100 bin ondalık basamak olabilir. Bazı matematikçilere göre, bu örneklerden daha küçük olanlardan daha büyük sayılar olduğundan daha büyük sayılar olduğu düşünülürse, bunların hepsi "büyük değil" olarak kabul edilebilir. Bu, birçok insanın düşünmediği bir şeydir, ancak doğruluk ve performans hakkında düşünürken fark yaratır.$10^{16}$

Bunları doğru test etmek oldukça zordur. Stratejim, açık birim testler, artı son durumlar, artı daha önce veya başka paketlerde görülen hata örneklerini, mümkün olduğunda bilinen veritabanlarını test etmeyi içerir (örneğin, eğer tek bir baz-2 MR testi yaparsanız, hesaplama açısından olanaksız olanı düşürürsünüz. yaklaşık 32 milyon sayıyı sınamak için 2 ^ 64 sayı sınama görevi) ve son olarak, standart olarak başka bir paket kullanarak çok sayıda rasgele sınama. Son nokta, oldukça basit bir girişin ve bilinen bir çıktının olduğu asallık gibi işlevler için işe yarar, ancak oldukça az sayıda görev bunun gibidir. Bunu hem kendi geliştirme kodumdaki kusurları hem de karşılaştırma paketlerindeki zaman zaman görülen sorunları bulmak için kullandım. Ancak sonsuz girdi alanına bakıldığında, her şeyi test edemiyoruz.

Doğruluk kanıtlamak gelince, burada başka bir primalite örneği. BLS75 yöntemleri ve ECPP, bir primallik sertifikası kavramına sahiptir. Temel olarak ispatlarına uygun değerleri bulmak için arama yapmaktan kaçındıktan sonra, bunları bilinen bir formatta çıkarabilirler. Kişi daha sonra bir doğrulayıcı yazabilir veya başka birinin yazmasını sağlayabilir. Bunlar oluşturma işlemine kıyasla çok hızlı çalışıyor ve şimdi (1) her iki kod parçası da yanlış (dolayısıyla doğrulayıcılar için neden diğer programcıları tercih edersiniz) ya da (2) ispat fikrinin arkasındaki matematik yanlış. # 2 her zaman mümkündür, ancak bunlar genellikle birden fazla kişi tarafından yayınlanmış ve incelenmiştir (ve bazı durumlarda kendi başınıza yürümeniz için yeterince kolaydır).

Buna karşılık, AKS, APR-CL, deneme bölümü veya deterministik Rabin testi gibi yöntemlerin tümü "asal" veya "kompozit" ten başka bir çıktı üretmiyor. İkinci durumda, doğrulayabileceğimiz bir faktör olabilir, ancak önceki durumda bu bitin dışında bir şey kalmadı. Program doğru çalıştı mı? Dunno.

Yazılımı birkaç oyuncak örneğinden daha fazlası üzerinde test etmek ve algoritmanın her aşamasında bazı örneklerden geçmek ve "bu girdiyi verdiğimde, burada olduğumda bir anlam ifade ediyor mu?" Demek önemlidir.

Fisher-Yates-Knuth karıştırma algoritması (pratik) bir örnek ve bu sitenin yazarlarından birinin yorum yaptığı bir örnek .

Algoritma, verilen bir dizinin rastgele permütasyonunu şu şekilde üretir:

 // To shuffle an array a of n elements (indices 0..n-1):
  for i from n − 1 downto 1 do
       j ← random integer with 0 ≤ j ≤ i
       exchange a[j] and a[i]

$i$$j$$0 \le j \le i$

Bir "naif" algoritma olabilir:

 // To shuffle an array a of n elements (indices 0..n-1):
  for i from n − 1 downto 1 do
       j ← random integer with 0 ≤ j ≤ n-1
       exchange a[j] and a[i]

Döngüde değiştirilecek eleman mevcut tüm elemanlardan seçilir. Ancak bu , permütasyonların taraflı örneklemesini üretir (bazıları aşırı temsil edilir vb.).

Aslında, basit bir (veya saf) sayım analizi kullanarak, balıkçı yates-knuff shuffling ile bir kişi ortaya çıkabilir .

$n$$n! = n \times n-1 \times n-2 ..$$n$$n-1$

Karıştırma algoritmasının doğru olup olmadığını ( önyargılı ya da değil ) doğrulamanın ana problemi , istatistiklerden dolayı çok sayıda numunenin gerekli olmasıdır. Yukarıda bağladığım kodlama makalesi tam olarak bunu (ve gerçek testlerle) açıklar.

En iyi örnek (okudum: en çok yaralandığım şey) şimdiye kadar gördüğüm kadarıyla collatz varsayımı ile ilgili. Problemlerden birinin iki sayı için aynı sayıya ulaşması için gereken minimum adım sayısını bulmak olduğu bir programlama yarışmasında (hatta birincilik için 500 dolarlık bir ödülle) bulundum. Tabii ki çözüm, her ikisi de daha önce görülen bir şeye erişene kadar sırayla adım atmak. Bize bir dizi numara verildi (sanırım 1 ile 1000000 arasındaydı) ve collatz sıfatının 2 ^ 64'e kadar doğrulandığını söyledi, böylece verilen tüm numaraların sonunda 1'de birleşeceğini söyledi. 32-bit kullandım. Bununla birlikte adımlarını yapmak için tamsayılar. Anlaşılan, 1 - 1000000 arasında (170 bin bir şey) belirsiz bir sayının olduğu ve 32-bit bir tamsayı'nın zaman içinde taşmasına neden olacağı ortaya çıkmıştır. Aslında, bu sayılar oldukça nadir görülür 2 ^ 31 Taşma olmamasını "sağlamak" için sistemimizi 1000000'den büyük BÜYÜK rakamlar için test ettik. Taşma nedeniyle test etmediğimiz çok daha küçük bir sayı ortaya çıkıyor. Çünkü "uzun" yerine "int" kullandım, 500 dolarlık bir ödül yerine sadece 300 dolarlık bir ödül aldım.

Sırt Çantası 0/1 sorun hemen hemen tüm öğrencilerin açgözlü bir algoritma ile çözülebilir olduğunu düşünüyorum biridir. Bu, daha önce bir açgözlü algoritmanın çalıştığı Sırt Çantası'nın problem versiyonu olarak bazı açgözlü çözümler gösterirseniz daha sık olur .

Bu problemler için, sınıfta , herhangi bir şüpheyi ortadan kaldırmak ve açgözlü sorun versiyonuna ilişkin Knapsack 0/1 ( dinamik programlama ) için kanıt göstermeliyim . Aslında, iki kanıt da önemsiz değildir ve öğrenciler muhtemelen onları çok yararlı bulmaktadır. Ayrıca, CLRS 3ed , Bölüm 16, Sayfa 425-427'de bununla ilgili bir yorum var .

Sorun: Bir mağazayı soyan hırsız ve sırt çantasına azami W ağırlığı taşıyabilir. Orada n öğeler var ve bu madde wi ağırlığında ve vi dolar değerinde. Hırsız hangi eşyaları almalı? kazancını arttırmak için ?

Sırt çantası 0/1 sorun : Kurulum aynı, ancak eşyalar daha küçük parçalara bölünmeyebilir , bu nedenle hırsız bir öğeyi almaya veya bırakmaya karar verebilir (ikili seçim), ancak öğenin bir kısmını almayabilir .

Ve öğrencilerden açgözlü versiyon problemiyle aynı fikri takip eden bazı fikirler veya algoritmalar alabilirsiniz.

• Torbanın toplam kapasitesini alın ve mümkün olan en değerli nesneyi koyun ve daha fazla nesne koyana kadar bu yöntemi yineleyin, çünkü torba dolu veya torbanın içine koymak için eşit ağırlıkta daha az nesne bulunmaz.
• Başka bir yanlış yol düşünmek: hafif eşyaları koymak ve bunları en düşük fiyata en düşük seviyeye çıkarmak.
• ...

Sizin için yararlı mı Aslında, jeton sorununun bir sırt çantası problemi versiyonu olduğunu biliyoruz . Ancak, sırt çantası ormanlarının problemlerinde daha fazla örnek var, örneğin, Knapsack 2D hakkında ne düşünüyorsunuz (bu, mobilya yapmak için odun kesmek istediğinizde gerçekten faydalıdır , şehrimde yerel olarak gördüm), bunun çok yaygın olduğunu düşünüyorum. açgözlü burada da çalışır, ama değil.

Yaygın bir hata, karıştırma algoritmalarını yanlış uygulamaktır. Wikipedia'daki tartışmaya bakın .

$n!$$n^n$$(n-1)^n$

Standart kütüphaneye istatistik işlevleri getiren Pythons PEP450 ilgi çekici olabilir. Yazar Steven D'Aprano, standart python kütüphanesindeki varyansı hesaplayan bir işleve sahip olmanın gerekçesinin bir parçası olarak şöyle yazar:

def variance(data):
        # Use the Computational Formula for Variance.
        n = len(data)
        ss = sum(x**2 for x in data) - (sum(data)**2)/n
        return ss/(n-1)

Yukarıdakilerin günlük testlerde doğru olduğu görülüyor:

>>> data = [1, 2, 4, 5, 8]
>>> variance(data)
  7.5

Ancak her veri noktasına bir sabit eklemek, varyansı değiştirmemelidir:

>>> data = [x+1e12 for x in data]
>>> variance(data)
  0.0

Ve varyans hiçbir zaman negatif olmamalıdır :

>>> variance(data*100)
  -1239429440.1282566

Mesele sayısal ve konuyla ilgili hassasiyetin kaybolması ile ilgili. Maksimum hassasiyet istiyorsanız, işlemlerinizi belirli bir şekilde sipariş etmeniz gerekir. Naif bir uygulama yanlış sonuçlara yol açar, çünkü hassasiyet çok büyüktür. Bu, üniversitedeki sayısal dersimin ilgili olduğu konulardan biriydi.

Bu muhtemelen peşinde olduğunuz şey olmasa da, bazı küçük vakaları başka bir düşünce yapmadan anlamak ve test etmek kesinlikle yanlış bir algoritmaya yol açacaktır.

$n$$n^2+n+41$$0<d$$d\text{ divides } n^2+n+41$$d < n^2+n+41$

Önerilen çözüm :

int f(int n) {
   return 1;
}

$n= 0, 1, 2, \dotsc, 39$$n=40$

Bu, "bazı küçük vakaları deneyin ve sonuçtan bir algoritma çıkarsın" yaklaşımı, (a) 'nın uygulanmasının hızlı olduğu bir algoritma ile baskının ortaya çıkacağı programlama yarışmalarında sık sık (burada olduğu kadar olmasa da) çoğalır. ) hızlı bir çalışma süresine sahip.