Article View: pl.comp.lang.python
Article #27208Re: Python a hashmapa
From: Sebastian Kaliszewski
Date: Tue, 19 Jan 2010 10:42
Date: Tue, 19 Jan 2010 10:42
82 lines
6373 bytes
6373 bytes
Jako że grupę czytują również "dzieci" (np. takie co to właśnie uczą się o złożoności asymptotycznej, itd). to rozwinę. Żeby w ogóle mówić o (nietrywalnej) złożoności asymptotycznej (czyli dla rozmiaru danych dążącego do nieskończoności) realizowany (abstrakcyjny) algorytm nie może mieć ograniczenia na wielkość danych. Jeśli wielkość danych jest ograniczona (przez stałą), to mówienie o złożoności dla dowolnie wielkich danych jest bez sensu, w najlepszym razie mamy przypadek trywialny, czyli złożoność (asymptotycznie) stałą -- O(1). Należy pamiętać że jeśli gdzies jest mowa o stałej to to może byc 1, 2, 3, 100, 0.000001, ale także 2**35, albo i 2**(2**35) albo i dowolnie gorzej. Jeśli już przejdziemy do dowolnie wielkich danych to złożoność różnych teoretycznie prostych algorytmów będzie różna w zależności od użytego modelu. Np. banalne odwołanie do k-tego indeksu w zwykłej tablicy w zależności od modelu będzie miało złożoność O(1), O(log n) albo i O(n) lub gorzej, to ostatnie dotyczy zwykłej maszyny Turinga choćby i z wieloma taśmami -- bo w niej dostęp jest sekwencyjny i już. Przy czym w modelach o dostępie swobodnym może być zarówno O(log n) jak i O(1) zależnie od tego czy mamy model z ograniczonymi rejestrami[*] (mamy alfabet symboli rejestrowych i nieskończenie wiele rejestrów) czy też, jam maszyna RAM z nieograniczonymi rejestrami (każda "komórka pamięci" tej abstrakcyjnej maszyny przechowuje dowolną liczbę naturalną, czyli ma nieograniczoną pojemność i tych komórek znowu jest nieskończenie wiele). Pozostaje jeszcze liczenie liczby tzw. operacji dominujących, np. liczby porównań, kopiowań, dostępów do pamięci itd. Ale to również musi być zanużone w jakimś modelu abstrakcyjnej maszyny. Oczywiście, jeśli np. będziemy liczyli liczbę kopiowań przechowywanych danych, czy np. liczę odwołań do tablicy to można mieć trywialnie koszt O(1), ale to i w wielu opeacjach drzewiastych liczba kopiowań na wstawienie jest stała (równa 1). Zatem z operacjami dominującymi trzeba uważać -- muszą być rzeczywiście dominujące. [*] ograniczone są wszystkie rejestry poza jednym -- trzeba jakoś zaindeksować dowolny rejestr. Zatem... w zależności od tego co nas interesuje stosujemy różne modele. Ale nie wolno zapomnieć o powyższym (różnych złożonościach tego samego rozwiązania). Różnice złożoności między różnymi modelami (Turing complete, nie wliczamy tu zliczania operaci dominujących bo to trochę co innego) mogą być duże, ale też zwykle nie przekraczają O(n**3) a i też gwarantuje się że ogólna klasa O(wielomian(n)) czy O(2**wielomian(n)) itd jest zachowana. Wynika to z tego, że każdy z tych modeli może zasymulować inny z narzutem wielomianowym (i ten wielomian jest konkretny, zwykle nie gorszy niż 3 stopnia). Co do samego hashowania i jego liniowości nawet w modelu RAM (nieskończenie wiele nieograniczonych rejestrów z dostępem swobodnym) to jest jeszcze problem zasadniczy (o którym napisałem na górze) -- funkcja mieszająca ma po pierwsze bardzo często stałej wielkości wyniki (dotyczy zdecydowanej większości realnie używanych hashy, czy to różnych prostych xor/shift/mod czy crc, czy md4, czy md5 czy sha1, itd) więc dla odpowiednio dużych danych przestaje działać (co z tego, że mamy 2**36 pozycji w tablicy skoro użyty hash crc32 da 2**32 różnych wyników). Po drugie nawet na maszynie RAM z dodatkami (typu operacje arytmetyczne i bitowe a nie tylko inkrementacja) typowy sensowny hash liczy się w czasie liniowo zależnym od wielkości hashowanych danych a nie w czasie stałym. W innych modelach maszyn niż RAM-podobne (nieskończenie wiele nieograniczonych rejestrów) w ogóle nie ma co mówić o stałym koszcie liczenia hasha. No chyba że używamy zliczania operacji dominujących i za taką uznajemy policzenie hasha, ale to jest masło maślane. Do tego nie wolno zapomnieć, że w dzisiejszych rzeczywistych komputerach (poza drobnymi komputerkami wbudowanymi (embedded)) dostęp do pamięci nie jest jednolity -- nawet bez swapowania różnice w czasie dostępu sięgają 3 rzędów wielkości (do ok. 1000 razy) i zależą nie tylko od trafień w cache ale np. dostęp sekwencyjny do większych bloków średnio bywa kilkanaście-kilkadziesiąt razy szybszy niż stricte swobodny. Ale to już temat na osobną bajkę. \SK -- "Never underestimate the power of human stupidity" -- L. Lang -- http://www.tajga.org -- (some photos from my travels)
Technical Details
Message-ID:
<krbg27-k7m.ln1@bozon.softax.pl>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.glorb.com!postnews.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!atlantis.news.neostrada.pl!news.neostrada.pl!bozon.softax.pl!newsReferences:
<hi9a48$c1b$1@zeus.man.szczecin.pl> <20100109102348.d563af8e.natural-born-killer@dontmailme.com> <hi9nmc$iqv$1@zeus.man.szczecin.pl> <hi9rbf$1ke$2@solani.org> <hiapsg$4mg$1@zeus.man.szczecin.pl> <hiavmd$i2o$1@solani.org> <hib2ff$96o$1@zeus.man.szczecin.pl> <ag6127-2bm.ln1@bozon.softax.pl> <83ed19bf-352f-434d-9079-202e4e20225c@b2g2000yqi.googlegroups.com> <28u527-5oa.ln1@bozon.softax.pl> <d0733461-ac40-4d64-8695-8578c649b415@s31g2000yqs.googlegroups.com> <6ppd27-g2g.ln1@bozon.softax.pl> <27447498-df29-4a45-91da-531458afb575@q4g2000yqm.googlegroups.com> <6rbe27-1ad.ln1@bozon.softax.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.gazeta.pl!newsfeed.pionier.net.pl!news.glorb.com!postnews.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!atlantis.news.neostrada.pl!news.neostrada.pl!bozon.softax.pl!news From: Sebastian Kaliszewski <s.bez_spamu@remove.this.informa.and.that.pl> Newsgroups: pl.comp.lang.python Subject: Re: Python a hashmapa Date: Tue, 19 Jan 2010 11:42:34 +0100 Organization: TP - http://www.tp.pl/ Lines: 82 Message-ID: <krbg27-k7m.ln1@bozon.softax.pl> References: <hi9a48$c1b$1@zeus.man.szczecin.pl> <20100109102348.d563af8e.natural-born-killer@dontmailme.com> <hi9nmc$iqv$1@zeus.man.szczecin.pl> <hi9rbf$1ke$2@solani.org> <hiapsg$4mg$1@zeus.man.szczecin.pl> <hiavmd$i2o$1@solani.org> <hib2ff$96o$1@zeus.man.szczecin.pl> <ag6127-2bm.ln1@bozon.softax.pl> <83ed19bf-352f-434d-9079-202e4e20225c@b2g2000yqi.googlegroups.com> <28u527-5oa.ln1@bozon.softax.pl> <d0733461-ac40-4d64-8695-8578c649b415@s31g2000yqs.googlegroups.com> <6ppd27-g2g.ln1@bozon.softax.pl> <27447498-df29-4a45-91da-531458afb575@q4g2000yqm.googlegroups.com> <6rbe27-1ad.ln1@bozon.softax.pl> NNTP-Posting-Host: 83.18.189.42 Mime-Version: 1.0 X-Trace: nemesis.news.neostrada.pl 1263895873 18927 83.18.189.42 (19 Jan 2010 10:11:13 GMT) X-Complaints-To: usenet@news.neostrada.pl NNTP-Posting-Date: Tue, 19 Jan 2010 10:11:13 +0000 (UTC) User-Agent: Thunderbird 2.0.0.23 (X11/20090817) In-Reply-To: <6rbe27-1ad.ln1@bozon.softax.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit