🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.lang.python
Article #27208

Re: Python a hashmapa

#27208
From: Sebastian Kaliszewski
Date: Tue, 19 Jan 2010 10:42
82 lines
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!news
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>

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