uporządkowany ciąg

Mam problem z zakodowaniem tego algorytmu:
Mam dwie tablice a[n] oraz b[n];
Wybieram losowo dowolny element tablicy, np. a[i]
Teraz szukam takiego elementu b[x], żeby a[i]==b[x].
Nastepnie szukam takiego elementu a[y], żeby b[x]=a[y], itd powtarzam ta operację. Kiedy już dojdę do końca, tj. a[i]==b[z] tworzę nowe tablice o znalezionych elementach.
Przykład:
5 1 2 4 6 3 7 8
1 2 3 5 7 4 8 6
odpowiedź
1 2 3 4 5
2 3 4 5 1

oraz
6 7 9
7 8 6

Jeśli łatwiej jest zrobić to na wektorach to również proszę o pomoc.
Z góry dziękuję

a ze sie tak wrednie spytam - co juz masz zrobione? w czym masz problem?

ogólnie nie mam pomysłu na caly ten algorytm. Tzn, mój pomysł jest taki, żeby wziąć pierwszy element tablicy a, poszukać go w tablicy b, i tak dalej.
Ale to będzie raczej wykonywało się za długo O(n^2)?
Może coś bardziej optymalnego

z tego co zrozumialem w tablicy A i w tablicy B elementy nigdy sie nie powtarzaja? tzn. o ile w tab. A bedzie jakakolwiek czworka, to bedzie co najwyzej jedna czworka w A i conajwyzej jedna w B?

w takim razie, posortuj rownolegle te tablice wg. wartosci w B (koszt nlgn), uzyskasz:

B = 1 2 3 4 5 6 7 8
A = 5 1 2 3 4 8 6 7

wykorzystujac fakt ze wartosci w B sa rozne, rosnace i ciagle, mozesz odnalezc element o danym B metoda o koszcie O(1) *), czyli wrzucic calosc w tablice intow gdzie na indeksie B-tym bedzie siedziec wartosc A-ta.

aby dopasowac do kazdego elementu A jego 'kontynuacje' w B, niestety tak czy owak trzeba przejrzec wszystkie elementy co daje koszt (nwyszukanie), co w sumie daje zlozonosc calosci:
f(n) = O(nlgn) + O(n1) = O(nlgn)

*) jesli elementy w B nie beda ciagle, to wyszukiwanie binarne = lgn, czyli calosc wyjscie nlgn

Na wejściu podaje n par liczb(numerów wierzchołków grafu). Jak mogę znaleźć ile grafów da się utworzyć z takich danych?
Przykład:
1 2
6 5
2 4
8 9
5 3
7 7
9 10
3 6
10 8
4 1

Odpowiedź 4:
uzasadnienie:
(1 2)(2 4)(4 1)
(7 7)
(8 9)(9 10)(10 8)
(3 6)(6 5)(5 3)

Nie mam żadnego pomysłu na rozwiązanie tego problemu. Prosiłbym o pomoc.

//q:jakims trafem Twoj nowy watek ma dziwnie podobna problematyke do poprzedniego. wez sie zdecyduj.. i nie tworz N watkow na jeden temat, bo sklejanie ich potem jest naprawde irytujace

W praktyce to mam do zrobienia kilkanaście zadan tego typu. Zostały mi tylko te dwa. Dopiero teraz zauważyłem, że rzeczywiście, te dwa problemy są do siebie bardzo podobne. Może więc rzeczywiście użycie grafu tutaj byłoby bardziej optymalne? Jesli tak, to prosiłbym o podpowiedź.
Prosze również o pomoc z sortowaniem równoległym. Czy powinienem zrobić to tak jakbym np. sortował tablicę a i przy okazji zmieniał indeksy w tablicy b takie jak w a?

Bodajze sie to nazywalo permutacje i... lap linka --> http://pl.wikipedia.org/wiki/Permutacja
Ps. Najprawdopodobniej chodzi o 'cykle'<nie chce="chce" mi="mi" sie="sie" sprawdzac="sprawdzac">

Hmmm... w zasadzie sam zabralbym sie za rozwiazanie tego problemu poprzez zmodyfikowanie algorytmu na przechodzenie grafu DFS'em<?> ktory bym puscil w petli od 0 do max_wierzcholkow i... hmm nie wystarczyla by listowa implementacja grafu + pare bajerow?

permutacje nic mi nie dają, a ogólnikowo omówiony algorytm dla grafu jeszcze bardziej namieszał, czy mógłbyś napisać boardziej precyzyjne rozwiazanie?