Manager

[yarpen]

Obliczenia pewnie wziete stad: http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/821008399831 Tyle teorii.

[Krzysiek K.]

Ciekawi mnie jak to obliczyłeś

Z prawdopodobieństwa. Mamy możliwych N wartości hashy (tu N = 2^32), losowo wybieramy K wartości (tu K = 10000) i chcemy poznać prawdopodobieństwo kolizji. Pierwszy wybór na pewno nie skoliduje (bo nie ma z czym), drugi ma 1/N szans na kolizję (z pierwszym kluczem), a i-ty klucz ma (N-i+1)/N szans na skolidowanie. O ile dobrze pamiętam, dla małych N i K takie rzeczy się liczyło ręcznie w szkole średniej, ale tu nie ma problemu zaprząc co tego kompa.

Naprawdę "Duzo prosciej zmienic nazwe" niż się tym zajmować dłużej niż 2min A 4 zmiany nazwy "nie będą męczące dla zespołu" Można nawet wyznaczyć nagrodę dla tego szczęśliwca który jako pierwszy zobaczy: "Żwirek" i "Muchomorek nie mogą występować razem.

Dla prawdopodobieństwa kolizji rzędu 1% w pełni się zgadzam, ale gdy kolizje będą występowały pospolicie (wspomniane 50% przy 80000 kluczy), to każdy kto będzie miał dostęp do edytora będzie musiał wymyślać zastępcze nazwy kilkanaście/kilkadziesiąt razy dziennie.

[Esidar]

Ciekawi mnie jak to obliczyłeś

Z prawdopodobieństwa.

Aa.. czyli teoria ze strony którą podał Yarpen
A tutaj jest praktyka http://burtleburtle.net/bob/hash/doobs.html kolumna COLLIDE-32 to ilość kolizji przy hash'u 32bit.
Prawdę mówiąc szkoda tylko że przy FNV nie ma wyników, bo właśnie tego używam

[Edit]

każdy kto będzie miał dostęp do edytora będzie musiał wymyślać zastępcze nazwy kilkanaście/kilkadziesiąt razy dziennie

A praktyka mówi, że nigdy się to nie zdarzyło w czasietworzenia Wiedźmina

[yarpen]

Faktem jest, ze nie sadze bysmy dobijali do 80k wartosci (test slownika zreszta tez nie). Niemniej bylo tego troche. Trzeba brac pod uwage, ze wszystkie te wzory zakladaja calkowicie losowe dane. W "realnych" przypadkach tak nie jest.

[albireo]

Naprawdę "Duzo prosciej zmienic nazwe" niż się tym zajmować dłużej niż 2min A 4 zmiany nazwy "nie będą męczące dla zespołu" Można nawet wyznaczyć nagrodę dla tego szczęśliwca który jako pierwszy zobaczy: "Żwirek" i "Muchomorek nie mogą występować razem.

Dla prawdopodobieństwa kolizji rzędu 1% w pełni się zgadzam, ale gdy kolizje będą występowały pospolicie (wspomniane 50% przy 80000 kluczy), to każdy kto będzie miał dostęp do edytora będzie musiał wymyślać zastępcze nazwy kilkanaście/kilkadziesiąt razy dziennie.

O ile ta 50% (w przybliżeniu) szansa wystąpienia kolizji w zbiorze 80000 kluczy się zgadza, to już dalsze rozumowanie jest błędne, szansa, że dodanie kolejnego klucza spowoduje kolizję, wynosi w tym przypadku w przybliżeniu 1 do 50000.
Co nie zmienia faktu, że i tak bym na tym nie polegał.

[Krzysiek K.]

O ile ta 50% (w przybliżeniu) szansa wystąpienia kolizji w zbiorze 80000 kluczy się zgadza, to już dalsze rozumowanie jest błędne, szansa, że dodanie kolejnego klucza spowoduje kolizję, wynosi w tym przypadku w przybliżeniu 1 do 50000.

Fakt, jednak błąd w rozumowaniu zrobiłem. Wycofuję się ze stawianych zarzutów.

[Reg]

Hashowałem kiedyś łańcuchy, które były keszowane do renderowania w moim starym systemie GUI. Za jego pomocą pokazywałem m.in. jakiś licznik który liczył po kolei "1", "2", "3" itd. Długo zastanawiałem się, czemu czasami pokazują się złe liczby, aż wpadłem na to że hashe się powtarzają Od tamtej pory używam MD5 albo innego hasha dłuższego niż 32 bity.

Natomiast w moim obecnym managerze zasobów, zasoby identyfikuję po stringu. Mam za to założenie, żeby nie wyszukiwać ich w każdej klatce, tylko jak najrzadziej. Na przykład obiekt encji pobiera sobie w konstruktorze wskaźnik do zasobu siatki na podstawie jego nazwy albo obiekt materiału pobiera w konstruktorze wskaźnik do zasobu tekstury na podstawie jego nazwy, a potem już używa go przez wskaźnik. Co myślicie o takim rozwiązaniu?

[spax]

Natomiast w moim obecnym managerze zasobów, zasoby identyfikuję po stringu. Mam za to założenie, żeby nie wyszukiwać ich w każdej klatce, tylko jak najrzadziej. Na przykład obiekt encji pobiera sobie w konstruktorze wskaźnik do zasobu siatki na podstawie jego nazwy albo obiekt materiału pobiera w konstruktorze wskaźnik do zasobu tekstury na podstawie jego nazwy, a potem już używa go przez wskaźnik. Co myślicie o takim rozwiązaniu?

I w tym wypadku hasha juz nie uzywasz? Pytam sie bo mam dokladnie takie samo zalozenie (w konstruktorze) tyle ze wlasnie z hashem

[Krzysiek K.]

Hashowałem kiedyś łańcuchy, które były keszowane do renderowania w moim starym systemie GUI. Za jego pomocą pokazywałem m.in. jakiś licznik który liczył po kolei "1", "2", "3" itd. Długo zastanawiałem się, czemu czasami pokazują się złe liczby, aż wpadłem na to że hashe się powtarzają Tongue Od tamtej pory używam MD5 albo innego hasha dłuższego niż 32 bity.

Najwidoczniej użyłeś jakiegoś dziwacznego i dosyć kiepskiego hasha, albo miałeś tych hashy bardzo dużo (ponad wspomniane 10000).

[Reg]

I w tym wypadku hasha juz nie uzywasz? Pytam sie bo mam dokladnie takie samo zalozenie (w konstruktorze) tyle ze wlasnie z hashem

Nie, już nie. Mam std::map<wstring, IResource*>. Ale nie twierdzę że to najlepsze rozwiązanie. Po prostu tak to wymyśliłem ponad rok temu i tak zostało, od tej pory skupiałem się na innych kawałkach kodu a ten manager zasobów dobrze mi służy przez tak długi czas