Path: csiph.com!news.mixmin.net!newsreader4.netcologne.de!news.netcologne.de!newsfeed.freenet.ag!feeder2.ecngs.de!ecngs!feeder.ecngs.de!81.171.118.63.MISMATCH!peer03.fr7!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!newsfeed2.atman.pl!newsfeed.atman.pl!.POSTED!not-for-mail
From: bartekltg <bartekltg@gmail.com>
Newsgroups: pl.comp.programming
Subject: =?UTF-8?Q?Re:_Tablica_int_i_usuwanie_duplikat=c3=b3w?=
Date: Wed, 16 Sep 2015 16:49:44 +0200
Organization: ATMAN - ATM S.A.
Lines: 36
Message-ID: <mtbvi8$1ro$1@node1.news.atman.pl>
References: <q1dqtorkbx55$.vtwhsmj03gkt$.dlg@40tude.net> <mt7umm$ulv$1@node1.news.atman.pl> <3aivb8qrco1q$.13cffg23pn4pg.dlg@40tude.net> <almarsoft.2913144209340693774@news.v.pl> <mtav82$r76$1@node2.news.atman.pl> <almarsoft.1833076260504397560@news.v.pl> <mtbd2l$9d5$1@node2.news.atman.pl> <50609ffa-fe60-473f-8adc-5be498ec3dc2@googlegroups.com>
NNTP-Posting-Host: 89-73-81-145.dynamic.chello.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: node1.news.atman.pl 1442414984 1912 89.73.81.145 (16 Sep 2015 14:49:44 GMT)
X-Complaints-To: usenet@atman.pl
NNTP-Posting-Date: Wed, 16 Sep 2015 14:49:44 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
In-Reply-To: <50609ffa-fe60-473f-8adc-5be498ec3dc2@googlegroups.com>
X-Received-Bytes: 2763
X-Received-Body-CRC: 2558236297
Xref: csiph.com pl.comp.programming:27513

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