On 16.09.2015 12:31, M.M. wrote:
> On Wednesday, September 16, 2015 at 11:34:13 AM UTC+2, bartekltg wrote:
>> Dlatego proponowałem (unordered_)set zamiast (...)map.
>> Jest/nie ma w pomocniczym zbiorze.
> To jest najszybsza metoda w praktyce. Czasami możemy trafić na
> dane, dla których funkcja hash da mnóstwo kolizji. Problem
> kolizji trochę rekompensuje odpowiednia implementacja hash-table,
> ponieważ można ją przeglądać tak jak lubi pamięć cache. W
> przypadku RBTree nigdy nie jest przyjaźnie dla cache, ale
> jest gwarancja N*Log(N) dla każdych danych.


A, jeszcze jedno, tutaj nie musimy używać set<int>, bo to rzeczywiście
nam nieźle zwolni.
Weźmy trudniejszą wersję, czyli pytacz chce przetwarzać liczby
w takiej kolejności w jakiej są w tablicy, tylko pominąć już raz
przetworzone. Ale skoro liczby mamy dane z góry, możemy je sobie
skopiować, posortować, (opcjonalnie machnąć std::unique aby pozbyć
\się duplkatów z posortowanej wersji). Do tego trzymamy tablicę
booli (vector<bool>) o tej samej długości.

Dostając liczbę, wyszukujemy ją binarnie w pomoczniczej posortowanej
tablicy, sprawdzamy czy bit w teblicy booli jest zapalony.

Będzie szybsze niż operacja na drzewach, i prawdopodobnie zajmie
mniej pamięci niż obie pozostałe wersje.
Prawdopodobnie, bo dla złośliwego przypadku - bardzo dużo podobnych
danych, ale niewiele różnych liczb, lepiej jest tworzyć
pomocniczy zbiór na żywo.

pzdr
bartekltg