On 2018-12-11 19:35, DMR wrote:
>> Dlaczego nie jakies hashowanie ?
>
>
> Wykombinowanie dobrej funkcji, kolizje, kupa danych... Nie wiem, czy to ogarnę.
> Ale zgłębiam temat. Bo niby - czemu nie? ;-)
>

...a nie lepiej uzyc cus gotowego/sprawdzonego ?
Np takie cos w Pythonie (na dosc slabym kompie-szefc bez butow chodzi:)
dla 10 000 000 'rekordow':

import timeit

dictionary = { key: str(key).zfill(6) for key in range(10000000) }
print(timeit.timeit('temp = { key: str(key).zfill(6) for key in
range(10000000) }', number=1))

print(dictionary[9999999], timeit.timeit('dictionary[9999999]',
number=10000, globals=globals()) / 10000)
print(dictionary[1], timeit.timeit('dictionary[1]',
number=10000, globals=globals()) / 10000)
print(dictionary[5000009], timeit.timeit('dictionary[5000009]',
number=10000, globals=globals()) / 10000)
print(dictionary[100000], timeit.timeit('dictionary[100000]',
number=10000, globals=globals()) / 10000)

daje takie czasy:
D:\>py zzz.py
5.356959160756147
9999999 7.252555713392894e-08
000001 5.5035608509168556e-08
5000009 7.855509932497284e-08
100000 8.065047214307341e-08

i to dla teoretycznie dosc slabych hashy, bo dla liczb naturalnych.
Oczywiscie szybkosc hashowania liniowa wzgledem rozmiaru,
a szybkosc szukania praktycznie niezalezna od rozmiaru.

PS: Oczywiscie to klasyczny dict/set (czyli klucz jest unikalny)
Istnieja oczywiscie: multidict i multiset, choc w Py niestandardowo.
W/w ma glownie obrazowac ze kilkadziesiat tysiecy to dzis raczej
"pryszcz" dla klasycznych/gotowych rzeczy.

AK