Konuşma notu: Şimdiye kadarki her yapı RAM'de yaşadı. Bu hafta diske geçiyoruz; önemli olan birim artık bir karşılaştırma değil, bir blok okuma.
Konuşma notu: Dokuz kısa animasyon tüm dersi taşır; her fikir, tanıtıldığı yerde bir normal ve bir uç/zor çalıştırma alır.
Konuşma notu: Her terim ilk geçtiği yerde tam olarak tanımlanır; bu tablo yalnız onu tekrar nerede bulacağınızı söyler.
Konuşma notu: Canlı çalıştırmak isterseniz şimdi bir terminal açın; her program kendi geçici klasörünü işletim sisteminin temp dizininde oluşturur, asla depo içinde değil.
Konuşma notu: Bu hafta tekrar tekrar aynı temaya dönüyor — verinin yerleşimi izin verdiğinde bir aramayı bir hesaplamayla değiştirmek.
Konuşma notu: Hafta 6'nın hash tablosunu anladıysanız, bölüm 8-10 aynı tablo, yalnız RAM'den bir adım uzakta.
Konuşma notu: Neyi saydığınızdaki bu tek kayma, tüm haftanın düzenleyici fikridir — her şey buradan gelir.
Konuşma notu: Buradaki her kutu aşağıda kendi bölümünü alır, her biri bir animasyon, gerçek bir program ve karmaşıklık/hata tartışmasıyla.
Konuşma notu: Bölüm 1'in kendi animasyonu yok — bu haftanın geri kalanının yeniden kullandığı çizim kuralını ve maliyet modelini kurar.
Konuşma notu: Cevap bir donanım ve dosya sistemi gerçeğidir, hiçbir programın vazgeçebileceği bir tasarım seçimi değil.
Konuşma notu: Bu haftaki her teknik, gerçekte blok okuma ve yazma sayısını en aza indirme stratejisidir.
Konuşma notu: Bu hafta her tek animasyon tam olarak bu düzeni kullanır — birini okuyabilirseniz, dokuzunu da okuyabilirsiniz.
Konuşma notu: Gerçek sistemler çoğu zaman ikisini birden kullanır — toplu işler için sıralı bir dosya, etkileşimli aramalar için hash'lenmiş bir dosya.
Konuşma notu: Burada gerçekte neyin zaman aldığını düşünün — karşılaştırmalar mı, disk erişimleri mi?
Konuşma notu: Bu, buradan sonraki her bölümün neden karşılaştırma değil blok okuma saydığının tam nedenidir.
Konuşma notu: Bölüm 2, bir kaydın birkaç alanını baytlara paketlemek — ve okurken tekrar açmakla ilgili.
Konuşma notu: Aşağıdaki üç cevap, boşa giden yer ile ayrıştırma maliyetini birbirine karşı takas eder ve hiçbiri bedava değildir.
Konuşma notu: Sabit uzunluk boşa giden ya da kayıp baytlarla öder; sınırlandırılmış bir taramayla öder; uzunluk önekli sert bir boyut sınırıyla öder.
Konuşma notu: Bu, haftanın geri kalanını kateden "ara yerine hesapla" temasının tohumudur.
Konuşma notu: Bu üçünden hiçbiri genel olarak "doğru olan" değildir — doğru seçim tamamen kayıtların sabit, hesaplanabilir bir boyuta ihtiyacı olup olmadığına bağlıdır.
Konuşma notu: Normal örnek: 11 kayıt, `NAME_FIXED=8` — hangi adların doldurulduğunu, hangilerinin sessizce kırpıldığını izleyin.
Konuşma notu: Burada sabit yerleşimde her tek kayıt veri kaybediyor — bu teknik için en kötü durum, bilerek maksimuma çıkarılmış.
Konuşma notu: Boş bir ad sabit yerleşimde tamamen doldurulur, sınırlandırılmış yerleşimde sıfır bayt tutar — aynı uç durumu ele almanın iki çok farklı yolu.
Konuşma notu: Kırpma, program bunu bildirmeye karar vermedikçe sessizdir — yukarıdaki kod özellikle bu nedenle bir kayıt kırpıldığında uyarı basar.
Konuşma notu: Hiç sınırlayıcı karaktere gerek yok, adın içinde yasaklanması gereken hiçbir karakter yok — takas 255 baytlık bir uzunluk sınırı.
Konuşma notu: Bu, bu dönem ilginç takasın hiç büyük-O'da olmadığı ender durumlardan biri.
Konuşma notu: Bir addaki virgül gibi bir sınırlayıcı, gerçek bir ad yasal olarak virgül içerdiği anda bozulur — uzunluk önekleme bu hata sınıfını tamamen aşar.
Konuşma notu: Okuyucunun alanın içeriğini okumaya başlamadan ÖNCE hangi bilgiye sahip olduğunu düşünün.
Konuşma notu: Uzunluk önekli düzenin bir baytlık ek yükü, bir taramanın önceden asla sahip olamayacağı bir kesinlik satın alır.
Konuşma notu: Bölüm 3, bölüm 1'in açık bıraktığı bir soruyu yanıtlar — kaç kayıt gerçekten bir disk erişimini paylaşır?
Konuşma notu: Cevap bloklama çarpanıdır — ve israfı ortadan kaldırmaz, yalnız nerede olduğunu değiştirir.
Konuşma notu: Bloklamanın tüm kazancı bu — bf kayıt, bf ayrı erişim yerine tek bir disk erişimi fiyatına.
Konuşma notu: Kısmi bir son blok diskte yine de tam bir blok kaplar — block_flush yine de yazar, israf dahil.
Konuşma notu: Kamyon benzetmesi iki tür israfı da somutlaştırır: sefer başına kullanılmayan kargo alanı, ve çok az kargo için yapılan bir sefer.
Konuşma notu: RAM tamponunun bf'e dolmasını, tek bir blok yazma olarak flush edilmesini, sonra bir sonraki blok için boş başlamasını izleyin.
Konuşma notu: Burada bf 0 hesaplanır — gerçek bir sistem bunu bir tasarım hatası olarak algılayıp reddetmeli, sessizce yanlış davranmamalı.
Konuşma notu: Burada son blok israfı yok — ama iç parçalanma yine de her tam blokta olur, çünkü iki israf türü birbirinden bağımsız.
Konuşma notu: block_flush yalnız ana döngüden sonra bir kez çağrılır — son blok israfını ödeyen odur.
Konuşma notu: Bölüm 4 ve 5'in O(numBlocks) ve O(log numBlocks)'u, bf büyüdükçe doğrudan küçülür, çünkü numBlocks = n / bf.
Konuşma notu: Bu iki israf türünün farklı nedenleri ve farklı çözümleri vardır — birbirine karıştırmak yanlış optimizasyona götürür.
Konuşma notu: bf = floor(100/24) = 4; israf edilen baytlar bf*recSize'dan sonra kalandır.
Konuşma notu: 4 bayt bir blok için önemsiz görünür — animasyondaki "hard" senaryosu bunun birçok blokta nasıl biriktiğini gösterir.
Konuşma notu: Bölüm 4, Hafta 1'in doğrusal aramasının, kayıtların bf'er bf'er geldiği gerçeğine uyarlanmış hali.
Konuşma notu: Yararlanılacak bir sıra düzeni olmadan, bu bölümün verdiği cevap: hayır — her blok kontrol edilmeli.
Konuşma notu: Zaten diskten okunmuş bir bloktaki birkaç fazladan kaydı karşılaştırmak, onları yükleyen disk erişiminin yanında neredeyse bedavadır.
Konuşma notu: Bu, Hafta 1'in doğrusal aramasının disk boyutlu birimlerle yeniden anlatılmış hali — zaman alan içindeki kağıt değil, kutunun kendisi.
Konuşma notu: Normal örnek: bf=4 — gerçek maliyet olarak karşılaştırma sayacını değil, blok okuma sayacını izleyin.
Konuşma notu: Yok olan bir hedef, en son kaydı bulmakla tam olarak aynı maliyeti taşır — her iki durumda da her blok okunur.
Konuşma notu: Bir blok okuma, bir karşılaştırma — bu tekniğin varyansının ulaşabileceği en iyi durum.
Konuşma notu: block_reads blok başına bir kez artar; comparisons kayıt başına bir kez — yalnız ilki bu haftanın gerçek maliyetidir.
Konuşma notu: Bölüm 3'ten daha büyük bir bloklama çarpanı, numBlocks küçüldüğü için sıralı aramayı doğrudan hızlandırır.
Konuşma notu: Bölüm 5'in sıralı dosyasının aksine, sırasız bir sıralı dosya bulunamama durumu için hiçbir kısayol sunmaz.
Konuşma notu: Algoritmanın son bloğu okumadan önce neye karar verebileceğini düşünün.
Konuşma notu: Bu, bölüm 5'in birazdan, dosya sıralı olduğu anda karşılaştıracağı cevapla aynı biçimdedir.
Konuşma notu: Bölüm 5, bölüm 4'ün hiç kullanmadığı gerçeği sorar — dosya sıralı tutulabilseydi ne olurdu?
Konuşma notu: Cevap evet, bir farkla — her karşılaştırmada bir eleman değil, koca bir blok elenir.
Konuşma notu: İkili arama bir bloğa daraldığında, içinde kısa bir doğrusal tarama (bölüm 4'ün fikri, ama bf ile sınırlı) onu bulur ya da bir boşluğu doğrular.
Konuşma notu: Bu, kendi animasyon çalıştırmasını hak eden uç durum — ikili arama HANGİ bloğu daraltır, anahtarın var olup olmadığını değil.
Konuşma notu: Etiket tam olarak bir bloğun ilk/son anahtarıdır — ona bakmak bir göz atma kadar sürer, yanlış taraftaki her şeyi eler.
Konuşma notu: Normal örnek: her karşılaştırmanın bir kerede koca bir bloğun tümünü nasıl elediğini izleyin.
Konuşma notu: Hedef aynı bloktaki iki gerçek anahtarın arasına düşer — içindeki kısa tarama doğru şekilde "bulunamadı" bildirir.
Konuşma notu: Blok 0'ın ilk anahtarıyla yapılan ilk karşılaştırma bile tüm dosyayı eler — başka okumaya gerek yok.
Konuşma notu: Her yineleme tam olarak bir blok okur, tıpkı dizi ikili aramasının tam olarak bir elemanı incelemesi gibi.
Konuşma notu: Hafta 1'in dizide ikili aramaya karşı doğrusal aramasıyla tam olarak aynı hızlanma biçimi, bir kademe yukarıda.
Konuşma notu: Bu algoritma bloğun tüm aralığıyla karşılaştırmalı, çünkü her adımda bir kayıt değil, birkaç kayıtlık koca bir blok içeri/dışarı bırakılıyor.
Konuşma notu: numBlocks = n / bf olduğunu hatırlayın — bunun temelden farklı bir algoritma mı, yoksa aynı algoritma bir kademe yukarıda mı olduğunu düşünün.
Konuşma notu: Dosyada ikili arama, blok yönelimli G/Ç'nin zorunlu kıldığı gruplama nedeniyle, bf kayıtlık gruplar üzerinde yapılan ikili aramadır.
Konuşma notu: Bölüm 6, bu konunun adını aldığı klasik algoritma — koca bir dosyayı kayıt kayıt dokunmadan güncellemek.
Konuşma notu: Bu alternatif, modern veritabanlarından on yıllar önce, erken toplu işleme sistemlerinden geliyor.
Konuşma notu: Bu kalıp, dosya işlemenin en eski fikirlerinden biridir — öğrencilerin ilk aklına gelen veritabanlarından çok daha eskidir.
Konuşma notu: Bu, Hafta 10'un birleştirme sıralamasının birleştirme adımının, iki diziye değil iki dosyaya uygulanmış hali.
Konuşma notu: Hangi işaretçi "geride" ise o ilerler — bu, iki sıralı diziyi birleştirmekle tam olarak aynı karşılaştırma mantığıdır.
Konuşma notu: Reddedilen bir işlem, kimsenin silinmesini istemediği veriyi asla silmemelidir — bu, bu algoritmadaki en önemli kural.
Konuşma notu: Bu iki-okuyucu resmi tam olarak Hafta 10'un birleştirme adımıdır, ve algoritmanın neden asla geri dönmediğini görselleştirmenin en temiz yolu.
Konuşma notu: Normal örnek: 10 ana kayıt, ekle/değiştir/sil karışımı 6 işlem — her iki işaretçinin birlikte nasıl ilerlediğini izleyin.
Konuşma notu: Tek bir çalıştırmada iki hata türü: var olan bir anahtara ekleme ve yok olan bir anahtarı değiştirme/silme.
Konuşma notu: Bu tam olarak "kalan işlemler" döngüsü — bazı kalan eklemeler başarılı olur, bazı kalan değiştirme/silmeler reddedilir.
Konuşma notu: Bu tam olarak Hafta 10'un birleştirme-sıralaması karşılaştırma yapısı — yeni olan tek kısım eşit-anahtar dalı.
Konuşma notu: Ana birleştirme bittikten sonra kalan döngüleri unutmak, bu algoritmadaki en yaygın hatadır.
Konuşma notu: Bu karmaşıklık farkı, toplu sistemlerin her işlem için ayrı ayrı aramak yerine neden sıralı dosyaları birleştirdiğinin tam nedenidir.
Konuşma notu: Herhangi bir yerdeki tek bir sırasız kayıt sessizce yanlış bir birleştirme üretir — bir çökme değil, bir hata mesajı değil.
Konuşma notu: Birleştirme bittiğinde yeni ana dosyanın gerçekte ne içerdiğini düşünün.
Konuşma notu: Bunu bölüm 10'un mezar taşlarıyla karşılaştırın — onlar tam olarak yoklamalı bir dosya baştan yeniden yazılamadığı için açık bir işarete ihtiyaç duyar.
Konuşma notu: Bölüm 7, Hafta 1'in dizi indeksleme fikrinin diske taşınmış hali — hiç arama yok, yalnız aritmetik.
Konuşma notu: Cevap hayır — ve bu, tüm haftanın en hızlı tekniği, açık ara farkla.
Konuşma notu: Bu, dosya yüz kayıt tutsun ya da yüz milyon, tam olarak aynı tek blok okuma maliyetini taşır.
Konuşma notu: Bir konumu aramak yerine hesaplamak, doğrulamayı atlamak anlamına gelmez — tam tersi.
Konuşma notu: Numaralı bir park yeri, hesaplanmış bir adresin en temiz resmi — bilinen bir numara için hiç kimse bir otoparkı kat kat aramaz.
Konuşma notu: Normal örnek: bf=5, 13 kayıt — her isteğin, geçerli ya da geçersiz, tam olarak bir blok okuma maliyeti taşıdığını izleyin.
Konuşma notu: Negatif bir rrn burada temiz biçimde reddedilir — kontrolsüz olsaydı negatif bir blok ve bozuk bir fseek hesaplardı.
Konuşma notu: Bir geçerli rrn, çoğunlukla boş olan bir bloğa doğru şekilde düşer; bir sonraki rrn yine de aralık dışı olarak reddedilmeli.
Konuşma notu: Depolanmış veriyle hiç karşılaştırma yok, hiç döngü yok — bu, tüm haftanın gerçekten en basit algoritması.
Konuşma notu: Bu, bu hafta diğer her tekniğin hesaplanmış ya da hash'lenmiş bir konumla yaklaşmaya çalıştığı kuramsal tavan.
Konuşma notu: Sınırların dışına taşan bir fseek'e hesaplanan doğrulanmamış bir rrn, tam olarak temiz başarısızlık yerine dosyayı bozan bir hata türü.
Konuşma notu: Her tekniğin bir cevaba ulaşmak için kaç bloğu ziyaret etmesi ya da hesaplaması gerektiğini düşünün.
Konuşma notu: numBlocks = n / bf, her iki arama tekniğinin karmaşıklığında açıkça görünür — doğrudan erişimde asla.
Konuşma notu: Bölüm 8, Hafta 6'nın hash tablosunu diske taşır; "bir hücre" artık "bir blok" olur, bir kayıt değil.
Konuşma notu: Evet — ve kilit değişim, buradaki bir hash "hücresinin" tek bir hücre değil, zaten bf anahtar tutabilen bir blok olması.
Konuşma notu: Bu tam olarak Hafta 6'nın ayrık zincirlemesi, "bağlı liste düğümlerinin" artık tek tek kayıt değil, koca disk bloğu olması dışında.
Konuşma notu: Zaten bf mektup tutabilen bir posta kutusu, Hafta 6'nın RAM tablosundan temel farktır; orada her "posta kutusu" tam bir mektup tutardı.
Konuşma notu: Bir taşma bloğu sonunda ayrılmadan önce bir kovada kaç anahtarın biriktiğini izleyin.
Konuşma notu: Tek bir kovayla, ilk bf'ten sonraki her anahtar çakışır — uzun bir taşma zinciri, bilerek maksimuma çıkarılmış en kötü durum.
Konuşma notu: m birden büyükken bile her anahtar çakışıyorsa, bu kötü seçilmiş bir m'yi kötü bir hash sonucundan ayırır.
Konuşma notu: Yeni bir taşma bloğu zincirdeki SON bloğa eklenmelidir, hiçbir zaman doğrudan ana kovaya değil.
Konuşma notu: Bu tam olarak Hafta 6'nın zincirleme bozulması, artık RAM karşılaştırmaları yerine gerçek disk erişimlerinde ödenir.
Konuşma notu: Buradaki bir çakışma "bf'inci anahtar, zaten dolu bir blok için yarışıyor" demektir — aynı m ve anahtar sayısı için önemli ölçüde daha nadir bir olay.
Konuşma notu: Çakışan bir anahtarın aynı tablo yapısında mı kaldığını, yoksa ayrı bir şey mi büyüttüğünü düşünün.
Konuşma notu: Bölüm 9'un ilerleyici taşması diğer aile — tam olarak aynı tablonun içinde farklı bir hücreyi talep ediyor, Hafta 6'nın açık adreslemesi gibi.
Konuşma notu: Bölüm 9, Hafta 6'nın açık adreslemesi diske taşınmış hali — ayrı bir yapı yok, yalnız yoklamaya devam et.
Konuşma notu: Hafta 6'nın açık adresleme fikri, her anahtarı orijinal tablonun içinde tutarak RAM'de tam olarak bu israfı önledi.
Konuşma notu: Yoklanan her hücre, boş olsun olmasın, bir gerçek disk erişimine mal olur — bu tekniğin maliyeti tam olarak bu yüzden yoklamalarla ölçülür.
Konuşma notu: Bölüm 8'in posta tepsilerinin aksine, burada hiç ayrı bir yapı yok — her anahtar gerçekten tek tabloda yaşar.
Konuşma notu: Ana hücre sona yakınken yoklama dizisinin son hücreden 0'a nasıl sarmalandığını izleyin.
Konuşma notu: Yoklama sayıları ekleme sırasıyla kilitlenmiş biçimde 1, 2, 3, ... artar — birincil kümelenmenin ders kitabı imzası.
Konuşma notu: Son ekleme m hücrenin hepsini dener ve hiçbirini boş bulamaz — sonsuz döngü değil, temiz bir "dosya dolu" raporu.
Konuşma notu: `tries < m` koruması olmadan, eşleşen anahtarı olmayan tamamen dolu bir tablo, i = (i + 1) % m'nin sonsuza dek döngüye girmesine neden olurdu.
Konuşma notu: Bu tam olarak Hafta 6'nın açık adresleme bozulması, artık RAM karşılaştırmaları yerine gerçek disk erişimlerinde ödenir.
Konuşma notu: İyi tasarlanmış bir dosya organizasyonu programı, dolu bir dosyayı zarifçe algılamalı ve bildirmeli — yukarıdaki örnek program tam olarak bunu yapar.
Konuşma notu: Hafta 6'daki terimi hatırlayın — ardışık dolu hücrelerden oluşan bir serinin neden büyümeye devam ettiğini düşünün.
Konuşma notu: Yoklama dizisi var olan bir seriye ulaşan her yeni anahtar, onu bir hücre daha uzatmak zorundadır, bu da bir sonraki çakışmayı daha olası yapar.
Konuşma notu: Bölüm 10, bir yoklama zincirinin ORTASINDAKİ bir anahtar silindiğinde bölüm 9'un yoklamasına ne olduğunu sorar.
Konuşma notu: EMPTY tam olarak bir aramanın "bu anahtar hiç eklenmedi, vazgeç" demek için kullandığı sinyaldir.
Konuşma notu: Arama ve ekleme burada temelden farklı sorular sorar — tam olarak bu yüzden bir mezar taşını farklı ele alırlar.
Konuşma notu: Tabela, tek bir resimde mezar taşıdır — geçmekte olan bir aramanın davranışını değiştirir, geçmekte olan bir eklemenin yapabileceğini değiştirmeden.
Konuşma notu: Bir silmenin bir hücreyi TOMB'a çevirmesini, sonra sonraki bir find()'ın onu doğru şekilde atlayıp zincirdeki daha ileri bir anahtara ulaşmasını izleyin.
Konuşma notu: Hiç gerçek-boş hücre kalmıyor — yalnız bölüm 9'un tries < m sınırı find()'ın sonsuza dek yoklamasını durduruyor.
Konuşma notu: Yeniden eklenen anahtar, kendi mezar taşını yeniden kullanarak kendi ana hücresine geri döner — doğru ve tatmin edici bir gidiş-dönüş.
Konuşma notu: TOMB ne "bulundu" ne de "durmak güvenli" demektir — herhangi başka dolu-ama-farklı bir hücre gibi atlanmalıdır.
Konuşma notu: Bir mezar taşını yeniden kullanmak, başka hiçbir anahtarın yoklama zincirini bozmadan silinen yeri geri kazanır.
Konuşma notu: Bir arama zaten dolu hücrelerden geçmek zorundaydı — mezar taşları yalnız "dolu ama geçilebilir" sayılanı genişletir.
Konuşma notu: Son durum, bölüm 9'daki tries < m sınırının neden savunmacı bir incelik değil, yük taşıyan bir gereklilik olduğunu tam olarak gösterir.
Konuşma notu: Hücrenin, gerçek bir anahtar yeniden tuttuktan sonra bir aramaya nasıl göründüğünü düşünün.
Konuşma notu: Başka herhangi bir anahtarın bakış açısından, dolu bir hücre dolu bir hücredir — orijinal anahtarını mı, sonradan geri kazanılmış bir mezar taşına eklenen bir anahtarı mı tutuyor olursa olsun.
Konuşma notu: Şimdi tek tek algoritmalardan geri çekilip beş organizasyonu yan yana karşılaştırıyoruz, ve her birini ne zaman seçeceğimizi.
Konuşma notu: Her satırın paylaştığı tek sütun sayılan birim — bölüm 1'den, karşılaştırma değil, blok okuma ve yazma.
Konuşma notu: Zaten her kaydı ziyaret edecekseniz, hiçbir teknik her bloğu bir kez okumaktan iyi değildir — sıralamak orada hiçbir şey kazandırmaz.
Konuşma notu: Hafta 6'daki gibi, en büyük karar şu: bu dosya anahtara göre verimli arama mı gerektiriyor, yoksa her zaman bütün mü işlenecek?
Konuşma notu: Bu hafta boyunca tek bir soru her bölümü yönlendirdi: her teknik kaç blok okuma ve yazma gerektiriyor?
Konuşma notu: Hafta 1, 6 ve 10'un her fikri burada mantığında değişmeden yeniden görünür, artık RAM işlemleri yerine blok okumalarda ödenir.
Konuşma notu: Bölüm 1'i hatırlayın — bir disk erişimi, içeriği üzerindeki herhangi bir bellek içi işlemden kat kat pahalıdır.
Konuşma notu: Bu, tüm haftanın düzenleyici fikri, bir kez daha bir gözden geçirme sorusu olarak ifade edildi.
Konuşma notu: Bölüm 5'i hatırlayın — her adımda bir kayıt değil, koca bir BLOK içeri/dışarı bırakılıyor.
Konuşma notu: Bu tam olarak dizide ikili arama (Hafta 1) ile dosyada ikili arama (bölüm 5) arasındaki fark.
Konuşma notu: Bölüm 6'yı hatırlayın — ilgisiz, reddedilen bir işlem asla geçerli veriyi yan etki olarak silmemelidir.
Konuşma notu: Bu, bu haftanın kendi referans programları inşa edilirken bulunan ve düzeltilen gerçek bir hataydı — varsayımsal değil, gerçek.
Konuşma notu: Bölüm 10'u hatırlayın — ekleme ve arama temelden farklı sorular soruyor.
Konuşma notu: Bu, açık adresleme + silmenin, herhangi bir dilde, en yaygın yanlış uygulanan tek ayrıntısı.
Konuşma notu: Bölüm 7'yi hatırlayın — aritmetik, kaç kayıt var olursa olsun aynı bir bölme ve bir mod.
Konuşma notu: Bunu bu haftanın her arama tekniğiyle karşılaştırın; maliyetleri doğrudan numBlocks = n / bf cinsinden ifade edilir.
Konuşma notu: Hafta 6'yı hatırlayın — bir çakışmanın kenarda bir yapı büyütüp büyütmediğini, yoksa aynı tablo içinde bir hücre mi talep ettiğini düşünün.
Konuşma notu: Bölüm 9'un ilerleyici taşması diğer Hafta 6 ailesi — aynı tablonun içinde farklı bir hücreyi talep ediyor.
Konuşma notu: Hafta 14, bölüm 8-10'un açık bıraktığı soruyu tam olarak yanıtlıyor: hash'lenmiş bir dosya m'sini aştığında ne olur?
Konuşma notu: Bunlar, haftanın yazılı notlarının sonunda listelenen aynı kaynaklar.
Konuşma notu: Knuth'un doğrusal yoklama analizi, bu haftanın "ilerleyici taşma" terminolojisinin tarihsel kökü.