On Tuesday, August 22, 2017 at 12:27:45 AM UTC+2, M.M. wrote:
> On Monday, August 21, 2017 at 10:58:34 PM UTC+2, bartekltg wrote:
> > On Monday, August 21, 2017 at 2:09:05 AM UTC+2, M.M. wrote:
> > > Pierwszy raz się z czymś takim spotykam. Podobno są tak samo wydajne jak drzewa
czerwono czarne, ale są prostsze w implementacji.
> > >
> > > Cytat ze stacka:
> > > [
> > > An alternative to all these trees are AA-Trees. As this PDF paper suggests,
AA-Trees (which are in fact a sub-group of RB-Trees) are almost equal in performance
to normal RB-Trees, but they are much easier to implement than RB-Trees, AVL-Trees,
or B-Trees. Here is a full implementation, look how tiny it is (the main-function is
not part of the implementation and half of the implementation lines are actually
comments).
> > > ]
> >
> >
> > Zapomniałeś dać linka do źródła cytatu:>
> >
> > >
> > > Prawda czy fałsz?
> >
> > Które są szybsze zależy od tego, co będziesz robił.
> > https://stackoverflow.com/questions/22435912/red-bla
ck-trees-versus-andersson-trees
> >
> > pzdr
> > bartekltg
>
> Racja:
> [
> So there's a trade-off here: when comparisons are cheap but updates are frequent, a
red-black tree might outperform an AA tree; otherwise, when comparisons are expensive
but lookups are more frequent than updates, the AA tree might win.
> ]

I jest jeszcze to, że RB mają mniejszy rozrzut czasów.
Nieraz też to jest istotne.

> Myślę jednak, że te różnice są niewielkie. Gdy jest naprawdę dużo
> porównań, to jak już pisałem, można zaimplementować rb-tree na
> tablicy i posortować w czasie O(N) przed długą serią wyszukiwań.
> Gdy są dosłownie wyszukiwania (dosłownie, czyli nie ma lowerBound, ani
> upperBound), to można też w czasie O(N) zbudować hash-table - ale
> to wymaga dodatkowej pamięci.


Miałem o tym pisać jak wróce do wątku z implementacją RB, ale
tu też będzie dobrze. Nie, to sortowanie to dość mało
przydatna rzecz;-)

Jeśli mam serię wstaweń (i ewentialnie usuwań) a potem wyszukiwania
to wstawiam w nieposortowany vector, potem go sortuję (jeśli coś
usuwam to do osobnej listy, sortuję, a potem std::set_difference)
i teraz wyszukuję na posortowanym wektorze.

Wstawianie mam liniowo (i znacznie szybciej niż Ty), sortowanie
też nieco szybciej.


Jeśli mówię, że drzewo będzie używane z przewagę wstawień/usunieć,
albo wyszukiwań, to znaczy, że np 5 jednych będzie przeplatane tym drugim,
nie, że wystąpią one po kolei.

Uporządkowanie tych działań to bardzo spacyficzne zastosowanie,
i, jak widać powyzej, da sie je zrobić nawet szybciej.

A tu dyskutujemy o uniwersalnych drzewkach.


> Oczywiście jest jeszcze i taka możliwość, że w losowej chwili
> robimy jedną modyfikację na 5-30 wyszukiwań. Gdy jest to 5, to
> może lepsze będą rb-tree, gdy 30, to może AA-tree. Trudno
> powiedzieć bez zmierzenia.
>
> Chwilowo mam taką sytuację w której mogę przewidzieć, że po jednej
> modyfikacji będą miliony wywołań lowerBound, więc rb-tree na tablicy z
> sortowaniem wydaje się najlepsze.

Jeśli masz miliardy elementów - niekoniecznie;-)

A jeśli Ci się opłaca sortować po wstawieniu jednego elementu,
to tym bardziej opłaca Ci się... wstawić liniowo element do posortowanego
ciagu.
Chyba dokładnie to robi flat_set z boosta. Wyszukujesz właściwe miejsce,
wstawiasz tam nowy element, a wszytkie kolejne przesuwasz o oczko w prawo.
Wstawienie jest O(n), ale szybkie (tylko raz dotykasz pamieci, i to średnio
tylko połowy), w porównaniu do Twojego, gdzie efektywnie masz wstawienie
o koszcie O(n log n).
> Wrzuciłem na bloga ulepszony program do przetestowania:
> https://drzewa-czerwono-czarne.blogspot.ch/p/kod-zro
dowy-programu-testujacego.html

Widziałem, nadal nie mam kiedy czytac.

> A także skrypt automatyzujący test:
> https://drzewa-czerwono-czarne.blogspot.ch/p/skrypt-
do-wykonania-testu-implementacji.html
>
> Kod drzewka pod starym adresem:
> https://drzewa-czerwono-czarne.blogspot.ch/p/kod-zro
dowy-c-drzewa-czerwono-czarne.html

pzdr
bartekltg