Algoritmaların asimptotik karmaşıklığının, algoritma tasarlama pratiğiyle ilişkisinin açıklanması


40

Algoritmalar ve karmaşıklıkta algoritmaların asimptotik karmaşıklığına odaklanıyoruz, yani bir algoritmanın girdi boyutu olarak kullandığı kaynakların miktarı sonsuzluğa gidiyor.

Uygulamada, ihtiyaç duyulan şey, sınırlı sayıda (muhtemelen çok büyük) örneklerde hızlı çalışacak bir algoritmadır.

İlgilendiğimiz sınırlı sayıda örnek üzerinde pratikte iyi çalışan bir algoritmanın iyi bir asimptotik karmaşıklığa sahip olması gerekmez (sınırlı sayıda örnek üzerinde iyi performans, asimptotik karmaşıklıkla ilgili hiçbir şey ifade etmez). Benzer şekilde, iyi asimptotik karmaşıklığa sahip bir algoritma, ilgilendiğimiz sınırlı sayıda örnek üzerinde pratikte işe yaramayabilir (örneğin büyük sabitler nedeniyle).

Neden asimptotik karmaşıklık kullanıyoruz? Bu asimptotik analiz, uygulamada algoritmaların tasarımı ile nasıl ilişkilidir?


Başka bir ilgili soru şudur: Neden sürekli faktörleri görmezden geliyoruz ?
Raphael

Yanıtlar:


24

İlginç olan soru şudur: alternatif nedir? Bildiğim diğer tek yöntem test etme / kıyaslama. Algoritmaları programladık, sonlu giriş kümesini çalıştırmalarına izin verin (temsili bir örnek) ve sonuçları karşılaştırın. Bununla ilgili birkaç sorun var.

  • Sonuçlar makineler açısından genel değildir. Kriterinizi başka bir bilgisayarda çalıştırın; kesin, niceliksel ve hatta belki niteliksel olarak farklı sonuçlar elde edersiniz.
  • Sonuçlar programlama dilleri açısından genel değildir. Farklı diller çok farklı sonuçlara neden olabilir.
  • Sonuçlar uygulama detayları açısından genel değildir. Gerçekten de algoritmaları değil programları karşılaştırırsınız ; uygulamadaki küçük değişiklikler performansta büyük farklılıklara neden olabilir.
  • En kötü durum nadir ise, rastgele bir girdi örneği kötü bir örnek içermeyebilir. Ortalama vaka performansı ile ilgileniyorsanız, bu adil olabilir, ancak bazı ortamlar en kötü durum garantilerini gerektirir.
  • Uygulamada, girdi kümeleri değişiyor. Genellikle, girişler zamanla daha büyük olur. Kriterinizi altı ayda bir tekrarlamıyorsanız (evet, bazı veriler hızlı büyüyor), sonuçlarınız yakında işe yaramaz.

Bununla birlikte, analizdeki her türlü etki ve sabiti gözardı etmek tipiktir, ancak (uygulamaya göre) tembel olarak adlandırılabilir. Algoritmik fikirleri , verilen (hatta sözde kod) bir uygulamanın performansını belirlemekten daha fazla karşılaştırmaya yarar . Topluma bunun kaba olduğu ve daha yakından bakılması gerektiği iyi bilinmektedir; örneğin, Quicksort (çok) küçük girişler için Yerleştirme sıralamasından daha az verimlidir. Adil olmak gerekirse, daha kesin analizler genellikle zor ².

Bir başka, biçimsel, soyut bakış açısına ilişkin bir posteriori gerekçesi, bu düzeyde, işlerin genellikle daha net olduğu yönündedir. Böylece, onlarca yıl süren teorik çalışma, pratikte kullanılan bir dizi algoritmik fikir ve veri yapısını ortaya koydu. Teorik olarak en uygun algoritma, pratikte kullanmak istediğiniz her zaman değildir - başka hususlar da vardır; Fibonacci yığınları olduğunu düşünüyorum - ve bu etiket bile benzersiz olmayabilir. Aritmetik ifadeleri optimize etmekle ilgilenen tipik bir programcının bu seviyede yeni bir fikir üretmesi zordur (bunun gerçekleşmeyeceğini söylememek); Yine de, bu optimizasyonları asimile edilmiş fikir üzerinde yapabilir (ve yapmalı).

Bir dereceye kadar uygulamadaki açığı kapatmak için resmi, teorik araçlar vardır. Örnekler

  • hafıza hiyerarşisini (ve diğer I / O) dikkate alarak,
  • Ortalama durumun analizi (uygun olan yerlerde),
  • Bireysel ifadelerin sayısının analiz edilmesi (soyut maliyet önlemleri yerine) ve
  • sabit faktörlerin belirlenmesi.

Örneğin, Knuth kelimenin tam anlamıyla farklı ifadelerin sayısını (belirli bir modelde verilen bir uygulama için) saymakla ve algoritmaların kesin olarak karşılaştırılmasını sağlamak için bilinir. Bu yaklaşım soyut düzeyde imkansızdır ve daha karmaşık modellerde yapılması zordur (Java'yı düşünün). Modern bir örnek için [4] 'e bakınız.

Teori ve pratik arasında her zaman bir boşluk olacaktır. Şu anda hem algoritmik maliyetler hem de çalışma süreleri için sağlam tahminler yapmak için her iki dünyanın en iyisini bir araya getirme hedefiyle bir araç üzerinde çalışıyoruz (ortalama olarak), ancak şimdiye kadar bir algoritmanın daha yüksek olduğu senaryolarla başaramadık maliyeti ancak daha az çalışma süresi (bazı makinelerde) eşdeğer olandan (bunu tespit edebilmemiz ve nedenini bulmamızı desteklememize rağmen).

Uygulayıcılara, karşılaştırmaları gerçekleştirmeden önce algoritmaların alanını filtrelemek için teori kullanmalarını öneririm:

if ( input size forever bounded? ) {
  benchmark available implementations, choose best
  schedule new benchmarks for when machine changes
}
else {
  benchmark implementations of all asymptotically good algorithms
  choose the best
  schedule new benchmarks for when machine changes or inputs grow significantly
}

  1. Önbellek kaçırma sayısı arttıkça mutlak ve göreceli performansta çılgınca değişiklikler olabilir; bu, genellikle girdiler büyüdüğünde ancak makine aynı kaldığında meydana gelir.
  2. Bu alanda olduğu gibi, önde gelen araştırmacılar da bunu yapamıyor.
  3. Aracı burada bulun . Örnek bir kullanım, Mühendislik Java 7'nin MaLiJAn Kullanan Dual Pivot Quicksort'unda S. Wild ve diğ. (2012) [ baskı ]
  4. Java 7'nin Dual Pivot Quicksort'unun Ortalama Durum Analizi, S. Wild ve M. Nebel (2012) - [ preprint ]

3
Muhtemelen, algoritmalar teorisini incelemenin saf eylemi gözünüzü keskinleştirir ve soyutlama beyninizi algoritmalar için eğitir ve günlük programlamada kodu değerlendirmek için başka bir araç sunar. Koddan uzaklaşın, ilkeyi değerlendirin, geliştirin ve tekrar koda çevirin. Örnek: "Ah, anlıyorum, bir sözlük programlamak istiyorsunuz. Fakat esasen listeleri programlıyorsunuz; neden ağaçları denemiyorsunuz?"
Raphael

Asimptotik analizin sınırları, daha derine indiğinizde belirginleşir; Quicksort belirgin bir örnektir .
Raphael

1
FWIW, buradaki Landau gösterimi hakkındaki görüşlerimin daha yeni bir görüntüsünü yazdım .
Raphael

11

Bu sorunun asimptotik analiz içeren bir ders vermekten kaynaklandığını varsayıyorum. Bu materyalin neden giriş sınıflarında öğretildiğine dair birkaç olası cevap vardır:

  • Asimptotik analiz, kendisini analize getiren matematiksel bir soyutlamadır. (Tartışmasız) matematikçiler olarak, algoritmaları analiz edebilmek istiyoruz ve karmaşıklıklarını aşmanın tek yolu asimptotik analiz kullanıyor.

  • Bir algoritmanın asimptotik performansını değerlendirmek, pratikte faydalı olan bazı ilkelere işaret eder: örneğin, zamanın çoğunu alan kodun bir kısmı üzerinde yoğunlaşın ve zamanın asimptotik olarak ihmal edilebilecek bir bölümünü alan kodun herhangi bir bölümünü iskonto edin .

  • Asimptotik analiz tekniklerinden bazıları yararlıdır. Burada temel olarak birçok durumda gerçeğin iyi bir tanımı olan "ana teoremi" denilen adıma atıfta bulunuyorum.

  • Tarihsel bir sebep de var: insanlar algoritmaları ilk kez analiz etmeye başladığında, ciddiyetle asimptotik karmaşıklığın pratik kullanımı yansıttığını düşünüyorlardı. Ancak, sonunda yanlış olduklarını ispatladılar. Aynı şey, her ikisi de pratikte yanıltıcı olan, etkili bir şekilde çözülebilen problemler sınıfı P ile, ve anlaşılmaz problemler sınıfı olarak NP oldu.

Şahsen asimptotik analizin müfredatın makul bir parçası olduğunu düşünüyorum. Daha tartışmalı olan kısımlar, biçimsel dil teorisi ve karmaşıklık teorisini (bir Turing makinesiyle ilgili olan her şeyi) içerir. Bazı insanlar bu konuların kendileri için programcı için faydalı olmasa da, iyi bir pratisyen olmak için gerekli olan belli bir zihin-düşüncesini aşıladıklarını savunuyorlar. Diğerleri, teorinin bazen uygulamayı etkilediğini ve bu nadir durumlarda, bu oldukça heyecan verici konuları genel bilgisayar bilimi izleyicisine öğretmeyi haklı göstermek için yeterli olduğunu savunuyor. Tarihi, edebiyatı veya ilgilendikleri diğer konuları öğrenmelerini tercih ederim; Her ikisi de gelecekteki iş olanakları ile ilgilidir ve onlar için insanlar kadar önemlidir.


Sağol Yuval. Motivasyon temel olarak ilgilenen öğrencilere asimptotik analizin faydasını ve algoritmaları gerçek uygulamalarda tasarlama ve kullanma pratiğiyle olan ilişkisini nasıl açıklayacağıdır (çoğu zaman sadece sonlu olarak ilgilendiğimiz açıkça görülmektedir. çok fazla sayıda örnek), müfredatı haklı çıkarmayacak.
Kaveh,

1
Senin öncülünle kafam karıştı. Hedef grubun, hem garip bir kombinasyon olan hem de bilgisayar bilimcilerini nitelendirmeyen hem matematikçiler hem de aday programcılar olduğunu varsayıyorsunuz. (Ayrıca, resmi dillerdeki görüşünüzü paylaşmıyorum, ama bu başka bir konu.)
Raphael

Aksine, hedef grubun programcıları hedeflediğini farz ediyorum. Ancak, müfredatın büyük kısmı teorik bilgisayar bilimcileri uğruna orada. Tabii ki, bu iki grubun birbiriyle çelişen ihtiyaçları var. Lisansın çoğu programcı olacağı için, müfredatın kendilerine yönelik olması gerektiğini düşünüyorum, ancak bazı akademisyenler aynı fikirde değil. Belki gelecekteki profesörlere öğretmek istiyorlar. Belki onların bakış açısını açıklayabilirsin.
Yuval Filmus,

3
@ YuvalFilmus Sıklıkla CS = TCS + Programlama olduğuna inanmadığımı açıkladım. Bir CS kursu öğretiyorsanız (bir üniversitede) ve öğrencilerinizin çoğu programcı olmak istiyorsa, bir şeyler bozulur (imho). Herhangi bir bilgisayar bilimcisinin algoritmalar, biçimsel diller ve hatta bazı karmaşıklık teorilerindeki (ve derleyiciler ve CPU'ların nasıl çalıştığı gibi diğer birçok şeyden) katı eğitimden yararlanabileceğini savunuyorum .
Raphael

2
@Wildcard Bilgisayar mimarisi, bilgisayar grafikleri, AI, programlama dili araştırması, ... - liste sonsuzdur! TCS gerçekten bir niş ve programlama (çoğu) CS araştırmacıları için bir araçtır.
Raphael

7

Çalışma sürelerinin asimptotik analizini kullanmanın iki ciddi nedeni vardır:

  • önemsiz ayrıntıları ortadan kaldırmak için. Önemsiz olmayan algoritmalara ihtiyaç duyduğumuz birçok uygulamada, çoğu zaman orta ila çok sayıda işlem gerektiren sorunlu durumlara harcanır ve genel işlemle tam işlem sayısından daha fazla ilgileniriz. Bu uygulamalarda, küçük için davranış ilginç değildir.n

  • matematiksel izlenebilirliğe izin vermek. İşlem sayısı için kesin ifadeleri bulmanın mümkün olduğu durumlar istisnaidir. Asimptotik çalışmalarını incelemek daha fazla olasılık sunar (karmaşık fonksiyonların asimptotik yaklaşımları kullanışlıdır).

Ve diğerleri var (makine bağımsızlığı, anlamlılık, karşılaştırılabilirlik ... gibi).


“Genel eğilim ile tam işlem sayısından daha fazla ilgileniyoruz” - bu cümle evrensel olarak doğru değil. Tüm uygulamalarda geçerli olmayan bir ders kitabı gerekçesidir. "Algoritma optimizasyonu orta ila çok sayıda işlem için kullanışlıdır" - bu da değil. Her zaman küçük girdilerde yürütülen ve hızlı olan ancak milyarlarca kez yürütülen bir algoritma da en iyi duruma getirmeye değer. Pratik örnek: Her gerçek dünyadaki Quicksort uygulaması küçük için başka bir sıralama algoritmasına geçer . n
Raphael

Bunun bir kural olduğunu sanmıyorum. Ne kadar çok veri atarsanız, ifadeleriniz o kadar zayıf olur. Asimptotik (ve dahası, "big-oh") perspektifi, "Quicksort, Insertionsort'tan daha hızlıdır" gibi ifadeler yaratır; (Evet, algoritma analizinin sıklıkla yanlış öğretildiğini söylüyorum imho.)
Raphael

6

Raphael'in cevabında belirtildiği gibi, en kötü durumdaki çalışma süresinin kesin olarak hesaplanması çok zor olabilir. Kesin hesaplama, RAM modeli zaten yaklaşık olarak kullanılmaya başlandığından da gereksiz olabilir. Örneğin, tüm işlemler gerçekten zaman alıyor mu? Özel uygulamalar (donanım, optimizasyonlar) bir algoritmayı sabit faktörlerle hızlandırabilir. Bir algoritmanın ne kadar etkili olduğunu bu faktörlerden bağımsız olduğunu anlamak istiyoruz . Bu, asimptotik analizlerin kullanımı için büyük bir motivasyondur.


3

Çünkü asimptotikler "basittir" (yani, sonlu durumlar için kesin analiz yapmaktan daha basittir).

Örneğin, asimptotik bir tahminde bulunabilmek için yeterli olan tüm önemli algoritmaların detaylı analizini yapan Knuth'un "Bilgisayar Programcılığı Sanatı" örneğini Knuth'un karşılaştırmasıyla karşılaştırın. ya da sadece bir sınır), çoğu "algoritma" kitaplarında uygulandığı gibi.

Kesinlikle haklısın. Sorun yeterince önemliyse, bir Knuth tarzı (ya da belki biraz daha az ayrıntılı) bir analiz iyi garanti edilebilir. Gelen bir çok durumda, deneysel verilere uyarlandı asimptotik karmaşıklığı bir ipucu (dispersiyon ile, belki de ortalama) yeterlidir. In Çoğu durumda , bir yapılacak kaba bir sınıflandırma birinci ot-out yuvarlak karşılaştıran asimptotikler kesin yeterli olabilir gibi rakip algoritmaların. Ve yarışmacı yoksa, tam maliyetle ilgili kötü haberi dakika dakika içinde detaylandırmak sadece mazoşizmdir.


2
Bu sadece gerçeğin yarısıdır: ilk önce aklınıza "big-oh" yazdığını düşünün (ki bu sorudan bahsetmiyor). İkincisi, "big-oh" asimptotikleri, algoritmalar toplanırken “yabancı ot turları” için başarısızlıkla sonuçlanmaya değerdir: girdiler gerçekte sonludur.
Raphael

3

Burada asimptotik analizle, girişin büyüklüğü sonsuzluğa giderken algoritma davranışını kastettiğimizi farz ediyorum.

Asimptotik analiz kullanmamızın nedeni , algoritmaların pratikteki davranışını tahmin etmede faydalı olmasıdır . Tahminler karar vermemize izin verir, örneğin bir problem için farklı algoritmalar varken hangisini kullanmalıyız? (Yararlı olmak, her zaman doğru olduğu anlamına gelmez.)

Aynı soru, herhangi bir basitleştirilmiş gerçek dünya modeli için de sorulabilir. Neden gerçek dünyanın basitleştirilmiş matematik modellerini kullanıyoruz?

Fizik düşünün. Klasik Newton fiziği, gerçek dünyayı tahmin etmede göreceli fizik kadar iyi değildir. Ancak otomobil, gökdelen, denizaltı, uçak, köprü vb. İnşa etmek için yeterince iyi bir model. Yeterince iyi olmadığı durumlar var. yıldızlar ve gezegenler gibi büyük gök cisimleri veya elektronlar gibi çok yüksek hızlı nesneler. Bir modelin sınırlarının ne olduğunu bilmek önemlidir.

  1. Tipik olarak gerçek dünyanın yeterince iyi bir yaklaşımıdır. Uygulamada sıklıkla daha iyi asimptotik analiz içeren bir algoritmanın pratikte daha iyi çalıştığını görüyoruz. Bir algoritmanın, daha iyi asimptotik davranışı olduğu durum nadiren ortaya çıkar. Dolayısıyla, girdiler yeterince büyükse, algoritmalar davranışının ilk öngörüsü olarak tipik olarak asimptotik analize güvenebiliriz. Girdilerin küçük olacağını bildiğimizden emin değiliz. İstediğimiz performansa bağlı olarak, daha dikkatli bir analiz yapmamız gerekebilir, örneğin girdilerin dağılımı hakkında bilgi sahibi olursak, algoritma verilecek ise, hedeflerimize ulaşmak için daha dikkatli bir analiz yapabiliriz (örneğin hızlı girişlerin yüzdesi). Mesele ilk adımdır asimptotik analiz iyi bir başlangıç ​​noktasıdır. Uygulamada ayrıca performans testleri yapmalı, ancak kendi sorunları olduğunu da aklımızda tutmalıyız.

  2. Uygulamada hesaplamak oldukça kolaydır. Genellikle, bir algoritmanın asimptotik karmaşıklığı üzerinde en azından iyi sınırları hesaplayabiliriz. Kolaylık olması açısından ismindeki bir algoritma olduğunu varsayalım izin her girişe başka bir algoritma geride. diğerlerinden daha iyi olduğunu nasıl bilebiliriz ? Biz asimptotik analiz yapmak ve görebilirsinizA AAAAdaha iyi asimptotik karmaşıklığa sahiptir. Bunların hiçbiri tüm girdilerde diğerinden daha iyi değil mi? Sonra daha zorlaşır ve neye önem verdiğimize bağlıdır. Büyük girişleri mi yoksa küçük girişleri mi önemsiyoruz? Büyük girdilere önem veriyorsak, bir algoritmanın daha iyi asimptotik karmaşıklığa sahip olması yaygın değildir, ancak önem verdiğimiz büyük girdilerde en kötü şekilde davranır. Küçük girdilere daha fazla önem veriyorsak, asimptotik analiz o kadar yararlı olmayabilir. Algoritmaların çalışma süresini, önemsediğimiz girdilerle karşılaştırmalıyız. Uygulamada, karmaşık gereksinimleri olan karmaşık işler için asimptotik analiz o kadar yararlı olmayabilir. Ders kitaplarının algoritmasını kapsayan basit temel problemler için oldukça kullanışlıdır.

Kısacası asimptotik karmaşıklık, basit temel görevler için (algoritmalar ders kitabındaki problemler) algoritmaların gerçek karmaşıklık yaklaşımını hesaplamak için nispeten kolaydır. Daha karmaşık programlar oluşturdukça performans gereksinimleri değişir ve daha karmaşık hale gelir ve asimptotik analiz o kadar yararlı olmayabilir.


Algoritmaların performansını tahmin etmek ve karşılaştırmak için asimptotik analizin diğer yaklaşımlarla karşılaştırılması iyidir. Yaygın bir yaklaşım, rastgele veya kıyaslamalı girdilere karşı performans testleridir. Asimptotik karmaşıklığın hesaplanmasında sıkça karşılaşılması zordur, örneğin, örneğin SAT çözümlemesinde olduğu gibi sezgisel tarama kullanıyorken. Başka bir durum, gereksinimlerin daha karmaşık olduğu durumlarda, örneğin bir programın performansı dış etkenlere bağlı olduğunda ve amacımız, belirli bir zaman diliminde (örneğin, bir kullanıcıya gösterilen arayüzü güncellemeyi düşünün)% 99’unda bir bitime sahip olmak olabilir. girişleri.

Ancak performans analizinin de sorunları olduğunu unutmayın. Daha az performansla ilgili matematiksel hibe vermeyenler, aslında algoritmaya verilecek tüm girdiler üzerinde performans testini yapıyoruz (genellikle hesaplama açısından olanaksız) (ve bazı girdilerin asla verilmeyeceğine karar vermek genellikle mümkün değildir). Biz rastgele bir numune ya da örtük olan bir kriter karşı üzerinde test ederseniz varsayarak bazı düzenliliği algoritmaların performansı hakkında, yani algoritma performans testi parçası değildi diğer girdileri benzer gerçekleştirecek.

Performans testleriyle ilgili ikinci sorun, test ortamına bağlı olmalarıdır. Yani, bir programın performansı yalnız girdiler tarafından değil, dışarıdaki faktörler (örneğin makine tipi, işletim sistemi, kodlanmış algoritmanın etkinliği, CPU kullanımı, bellek erişim süreleri vb.) İle belirlenir. Aynı makinede test. Yine burada, performans testinin gerçekleştirildiği belirli ortamların, programı çalıştırabileceğimiz tüm ortamlar üzerinde performans testleri yapmazsak (ve hangi makinelerin bir sıralamada çalışacağını nasıl tahmin edebileceğimizi tahmin edemezsek), gerçek ortama benzer olduğunu varsayıyoruz. 10 yıl içinde algoritma?).

Bunları, MergeSort ( ) deyiminin asimptotik çalışma zamanını hesaplamak ve bunu SelectionSort ( ) veya BinarySerch ( çalışma zamanıyla karşılaştırmakla karşılaştırın ) LinearSearch ( ) ile birlikte.Θ ( n 2 ) Θ ( lg n ) 0 ( n )Θ(nlgn)Θ(n2)Θ(lgn)O(n)



Şimdi yanıtlayacak kadar bu cevabı seviyorum. İki not: 1) Burada "karmaşıklık" yerine "maliyet" kullanırdım. Kısmen evcil hayvanlara bakma sebeplerinden dolayı, ancak aynı zamanda akla gelebilecek çok sayıda maliyet ölçütü bulunduğundan (bahsettiğiniz tüm hususları zorlaştırır). 2) Bir dil-lehçe geçişi yapmak isteyebilirsiniz. ;)
Raphael

@Raphael, teşekkürler. Yakında başka bir düzenleme yapmayı planlıyorum. :)
Kaveh

-2

O(n2)O(nlogn)O(n2) QuickSort ile karşılaştırıldığında bitirmek için.

Şimdi, beklemede kodun çağrıldığı kadar kodda tekrarlı olduğunu hayal edin . Bir kimse, quicksort algoritmasının bu belirgin üstünlüğünü matematiksel olarak nasıl nicelendiriyor / haklı gösteriyor? (yani, ismi gerçekten haklı mı yoksa sadece bir pazarlama sloganı mı?) asimptotik karmaşıklık ölçümleriyle. Biri, öznel olarak bubblesort'un bir şekilde daha zayıf bir algoritma olduğunu ve asimptotik karmaşıklık analizinin bunu nicel olarak kanıtlayabildiğini hissetmesine neden olan animasyonlara bakmaya bırakıldı . fakat asimptotik karmaşıklık analizinin, algoritmaları analiz etmek için araçlar çantasında sadece bir araç olduğunu ve her zaman nihai olmadığını unutmayın.

ve yan yana koda da bakmaya değer. bubblesort kavramsal olarak daha basit görünüyor ve özyineleme kullanmıyor. QuickSort, "3 ortanca" pivot prensibine göre hemen anlaşılmadı. bubblesort, bir alt-rutini olmayan sadece ilmeklerde uygulanabilir; oysa hızlı-port, tipik olarak en az bir alt-rutini içerebilir. bu, daha fazla kod karmaşıklığının bazen kod basitliği pahasına asimptotik karmaşıklığı artırabildiğini gösterir. Bazen, azalan marjinal getiriler kavramına benzer bir uçurum vardır (ekonomiden kaynaklanmaktadır), çok büyük kod karmaşıklığı harmanları [tamsayıları tam ve tam delilleri gerektiren tüm sayfalar] asimptotik karmaşıklıkta çok küçük iyileştirmeler alır. Bu bir örnek olarak esp ile gösterir.matris çarpımı ve hatta çizilebilir .


"Animasyonlara bakmak" ile kapsamlı çalışma zamanı kıyaslamaları gibi resmi analizler arasında çok fazla alan var. Onlar aslında kendi başlarına geçerli bir alandır, zira çalışma sürelerini etkileyen tüm şeyleri açıklamak için teorimiz yoktur.
Raphael

@ raphael, cevabınıza kıyaslama yaptınız; bu iyi bir cevap. ancak animasyon / görselleştirmenin kıyaslama ile yakından ilgili olabileceğini unutmayın. gerçekte, çalışma sürelerini [diğer cevaplarda ele alındığı] neyin etkilediğine dair birçok açıklama vardır, ancak bir dereceye kadar "gürültüsünü" ve asimptotik karmaşıklığı "gürültüyü düzeltir / ortalar". gerçekte nasıl yaptığını görmek için başka bir egzersiz.
vzn

Yine de animasyonlar gürültüyü filtrelemez. Ayrıca, insan gözü kolayca kandırılıyor ve makul büyüklükteki listelerin makul ölçülerde bir örneğini (örneğin, sıralama algoritmalarını ölçmek için milyonlarca boyut için 1000 liste) ve hangisinin daha hızlı olduğuna karar vermek için animasyonlar izlemek mümkün değil. (ortalama olarak).
Raphael

nn

n
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.