ich hab ein Problem mit dem unordered_set Datentyp der Standard-Library. Und zwar würde ich dieses gerne mittels std::sort sortieren, was allerdings nicht hinhaut. Nach Recherche mittles Google geht das nicht und der einzige Wege wäre das unordered_set in einen anderen Container zu kopieren und dann wieder zurück zu kopieren.

Diesen zusätzlichen Kopier-Vorgang will ich aber vermeiden. Gibt es wirklich keine andere, effizientere Möglichkeit ein unordered_set zu sortieren?

Grüße,
hs

Aber warum kein normales set wenn du die Elemente sortiert haben möchtest?

Aber warum kein normales set wenn du die Elemente sortiert haben möchtest?

Weil ich pro Iteration viele Elemente in die Datenstruktur einfüge. Das Sortieren kann erst ganz am Ende erledigt werden, wenn alle Elemente hinzugefügt wurden. Ein normales set sortiert ja nach jedem Einfügevorgang, was in so einem Fall ja sehr schlecht ist.

manni66 schrieb:

Nein

Danke für diese konstruktive Antwort
Welche Datenstruktur würde sich dann besser für mein Vorhaben eignen?

Ein normales set sortiert ja nach jedem Einfügevorgang, was in so einem Fall ja sehr schlecht ist.

Nein, da wird nichts nachträglich sortiert. Das Element wird gleich an die richtige Stelle eingefügt.

happystudent schrieb:

Welche Datenstruktur würde sich dann besser für mein Vorhaben eignen?

std::set natürlich.

Nein, da wird nichts nachträglich sortiert. Das Element wird gleich an die richtige Stelle eingefügt.

Ja, aber das "an der richtigen Stelle Einfügen" kostet doch auch?

std::set::insert hat logarithmische Komplexität für die Einfügeoperation
std::unordered_set::insert hat konstante Komplexität für die Einfügeoperation

Also ist das hier auf jeden Fall ungünstiger. Ich will erst ganz am Ende sortieren, wenn schon alle Elemente eingefügt sind.

Also ist es insgesamt besser, gleich ein set zu nehmen, als in ein unordered_set einzufügen und nachträglich zu sortieren.

Ich will erst ganz am Ende sortieren, wenn schon alle Elemente eingefügt sind.

Warum nimmst Du dann nicht einfach einen std::vector?

_Edit: Und wenn nötig, nach dem Sortieren halt noch std::unique().

Sortieren: O(n * log(n))
Einfügen in unordered_set: O(1)

Also ist es insgesamt besser, gleich ein set zu nehmen, als in ein unordered_set einzufügen und nachträglich zu sortieren.

Das kann man nicht so allgemein sagen. Angenommen, es werden n verschiedene Elemente je m mal eingefügt.

Dann ist unordered_set+sortieren insgesamt O(n*m+n log n) und set O(n*m*log n) Wenn m asymptotisch grösser ist als log n (z.B. m=n), kann unordered_set+sortieren besser sein.

Warum nimmst Du dann nicht einfach einen std::vector?

Weil ich gleichzeitig Elemente in O(1) finden können will.

5rthsdfaser schrieb:

Das kann man nicht so allgemein sagen. Angenommen, es werden n verschiedene Elemente je m mal eingefügt.

Dann ist unordered_set+sortieren insgesamt O(n*m+n log n) und set O(n*m*log n) Wenn m asymptotisch grösser ist als log n (z.B. m=n), kann unordered_set+sortieren besser sein.

Jo.

Caligulaminus schrieb:

Warum nimmst Du dann nicht einfach einen std::vector?

Weil ich gleichzeitig Elemente in O(1) finden können will.

Warte mal, du willst Elemente konstant finden. Und unordered_set sortieren.
Wenn du es sortiert hast, kannst du es aber nicht mehr in konstanter Zeit finden.
In dubio pro std::vector, sag ich nur.

Warte mal, du willst Elemente konstant finden. Und unordered_set sortieren.
Wenn du es sortiert hast, kannst du es aber nicht mehr in konstanter Zeit finden.

Echt? Wieso dass denn? Das wäre ja blöd

Nathan schrieb:

In dubio pro std::vector, sag ich nur.

Naja, vector ist hier glaub ich einfach nicht geeignet. Ich hab folgendes Szenario: Eine sehr lange Liste von Typen die Sortiert sein muss (nennen wir sie LISTE_1). Und eine zweite, ebenfalls sehr lange Liste vom gleichen Typ die nicht sortiert ist und auch nicht sortiert sein muss (das wäre dann LISTE_2).

Ich will jetzt Elemente von LISTE_2 nach LISTE_1 kopieren, aber nur wenn LISTE_1 diese noch nicht enthält. Danach sollen aus LISTE_1 alle Elemente entfernt werden, die nicht in LISTE_2 sind, außer eine gewisse Anzahl an fixen Elementen die nicht gelöscht werden. Nach allen Einfügevorgängen soll LISTE_1 wieder in einem sortieren Zustand vorliegen.

Mit nem vector hätte ich da etwa O(n^2), was ich unbedingt vermeiden will.

Hier ein kleines Beispiel, die fixen Werte sind mit x bezeichnet:

// Ausgangslage
LISTE_1    LISTE_2
b          a
c          d
d
x

// Alle Elemente aus LISTE_2 zu LISTE_1 hinzufügen, die noch nicht in LISTE_1 sind:
LISTE_1    LISTE_2          
b          a
c          d
d
x
a

// Jetzt alle Elemente aus LISTE_1 entfernen, die nicht in LISTE_2 sind, außer fixe Elemente x:
LISTE_1    LISTE_2
d          a
x          d
a

// Abschließend soll LISTE_1 wieder in einen sortieren Zustand gebracht werden:
LISTE_1    LISTE_2
a          a
d          d
x

Das will ich letztendlich erreichen halt möglichst effizient.

vector<int> liste_1, liste_2;
liste_1.erase(remove_if(liste_1.begin(), liste_2.end(), ist_fixes_element));
unordered_set<int> tmp(liste_2.begin(), liste_2.end());
liste_1.insert(liste_1.end(), tmp.begin(), tmp.end());
sort(liste_1.begin(), liste_1.end());

Nathan schrieb:

Warte mal, du willst Elemente konstant finden. Und unordered_set sortieren.
Wenn du es sortiert hast, kannst du es aber nicht mehr in konstanter Zeit finden.

Echt? Wieso dass denn? Das wäre ja blöd

Schau dir mal an wie Hashtables funktionieren.
http://de.wikipedia.org/wiki/Hashtabelle

¹D.h. average-case-konstanter Zeit. Mit dem konstant komplexen Zugriff in Hashtables ist das so ne Sache; wenn zum Beispiel jemand dir nicht wohlgesonnenes die Schlüssel manipulieren kann, musst du mit linearer Komplexität rechnen.

Kannst du nicht einfach alle x in Liste 2 einfügen?

Könnte ich schon, aber das wäre sehr ungünstig weil Liste 2 in jedem Durchgang neu erstellt wird. Das heißt ich müsste die resultierende Liste auch in jedem Durchgang sortieren, was viel zu aufwändig wäre. Daher mach ich überhaupt erst das hin und her kopieren, dass die resultierende Liste 1 wirklich nur dann sortiert werden muss wenn wirklich nötig.

humm schrieb:

Also:

vector<int> liste_1, liste_2;
liste_1.erase(remove_if(liste_1.begin(), liste_2.end(), ist_fixes_element));
unordered_set<int> tmp(liste_2.begin(), liste_2.end());
liste_1.insert(liste_1.end(), tmp.begin(), tmp.end());
sort(liste_1.begin(), liste_1.end());

Ja, damit kopiert man dann halt wieder etliche Werte hin und her...

otze schrieb:

wie lang sind denn die Listen von denen wir hier reden?

Es sind string Listen wobei Liste 1 ca 7000 fixe Einträge hat (die also nie gelöscht werden). Dazu kommen noch die dynamischen Einträge aus Liste 2, deren Anzahl letztenlich der Benutzer bestimmt. Typische Größenordnung ist hier von ca. 1000 - 5000 Einträge.

Die strings in den Listen selbst sind etwa zwischen 1 und 20 chars lang, im Schnitt etwa 5-6 chars.

Es sind string Listen.

Gut, dann halt

#include <iterator> // damit du dich nicht über Compiler-Fehler wunderst
vector<string> liste_1, liste_2;
liste_1.erase(remove_if(liste_1.begin(), liste_2.end(), ist_fixes_element));
unordered_set<string> tmp(make_move_iterator(begin(liste_2)), make_move_iterator(end(liste_2.end)));
liste_1.insert(liste_1.end(), make_move_iterator(begin(tmp)), make_move_iterator(end(tmp)));
sort(liste_1.begin(), liste_1.end());

Ich wette mit dir, dass das schneller ist, als alle deine optimierten Selbstversuche.

Gut, dann halt

#include <iterator> // damit du dich nicht über Compiler-Fehler wunderst
vector<string> liste_1, liste_2;
liste_1.erase(remove_if(liste_1.begin(), liste_2.end(), ist_fixes_element));
unordered_set<string> tmp(make_move_iterator(begin(liste_2)), make_move_iterator(end(liste_2.end)));
liste_1.insert(liste_1.end(), make_move_iterator(begin(tmp)), make_move_iterator(end(tmp)));
sort(liste_1.begin(), liste_1.end());

Ich wette mit dir, dass das schneller ist, als alle deine optimierten Selbstversuche.

Nee, schon allein deswegen nicht weil hier in jedem Schritt alle dynamischen Elemente aus Liste 1 entfernt werden (ich geh mal davon aus du meinst ist_nicht_fixes_element als Filter Funktion, oder?). Daher müsste mit dieser Lösung in jedem Schritt sortiert werden, auch wenn es gar keinen neuen Elemente für Liste 1 gibt.

Also eigentlich will ich Source-Code parsen und Benutzer-Definierte keywords wie Klassennamen etc. zu einer Liste hinzufügen. Das heißt ja dass im Großteil der Fälle in denen der Benutzer tippt auch kein keyword verändert wird und daher die Liste nicht neu aufgestellt werden muss.

Deswegen lauf ich über den Code und adde alle solche Keywords wenn sie noch nicht in der Liste sind. Wenn bereits alle keywords in der Liste sind muss auch nichts verändert und damit nichts sortiert werden.

Problem ist halt wenn der Benutzer was löscht, zum Beispiel den letzten Buchstaben von "MyClasss" (nachdem er sich verschrieben hat zum Beispiel). Dann muss der Algorithmus ja checken dass das keyword "MyClasss" nicht mehr exisitiert und es löschen. Daher hab ich eine zweite Liste, in der alle aktuell tatsächlich gefundenen Einträge gespeichert werden. Diese zweite Liste wird dann mit der ersten Liste abgeglichen.

Ist das die normale Vorgehensweise für dieses Problem oder gibt es bessere Lösungen dafür?

happystudent schrieb:

Ist das die normale Vorgehensweise für dieses Problem oder gibt es bessere Lösungen dafür?

libclang
Das willst du nicht alles selber schreiben.

Warum nicht gleich die aktuelle Liste nehmen bzw. einmal swap aufufen?

Weil ich dann keine keywords, die sich nicht mehr im Code befinden, löschen kann!

Klar kann ich die aktuelle Liste nehmen und einfach gefundene keywords hinzufügen. Aber wenn der Benutzer ein bereits vorhandenes keyword verändert, dann soll das alte keyword gelöscht werden.

nwp3 schrieb:

libclang
Das willst du nicht alles selber schreiben.

Ja also so umfangreich zumindest nicht, aber prinzipiell schon. Ich will das halt lernen sowas zu bauen.

Klar kann ich die aktuelle Liste nehmen und einfach gefundene keywords hinzufügen. Aber wenn der Benutzer ein bereits vorhandenes keyword verändert, dann soll das alte keyword gelöscht werden.

Nicht hinzufügen, ersetzen.

list = parseDocument();
wait_until_user_changed_document();
list = parseDocument();
//Tadaaa! Alle neuen keywords vorhanden und keine alten Keywords mehr drin

Und das findest du wirklich schoener als

for( auto& a : tmp )
    liste_1.push_back( move(a) );