Heap und std::vector und das ganze auf Pointern

life

Bei der einen Laufzeitangabe |E|=|V|^2 vorauszusetzen und bei der anderen nicht, ist jedenfalls nicht ganz fair.

Ob |E|=|V|^2 der typische Fall ist, hängt dann wohl von deiner Anwendung ab. Normalerweise würde ich aber erwarten, dass die Implementierung mittels binären Heap effizienter ist als eine Implementierung mit fib Heap. Fib. heaps sind nämlich ihmo eher nur von theoretischen Interesse ;).

Ergänzung zu @Max3000: Also z.B. push_heap(&heap[0], (&elementToDecrease)+1);

Max3000

@ drakon:
Beim Einfügen in den Heap hab ich das so gemacht. Aber ich will ja ein Element verkleinern, was schon im Heap drin ist.

Also mein einfügen sieht so aus:

heap.push_back(headOfCurrentEdge);
push_heap(heap.begin(), heap.end(), comp);

und mein decreaseKey jetzt so:

headOfCurrentEdge->key = v->key + currentEdge->length;
push_heap(heap.begin(), heap.end(), comp);

wobei ich denke dass es nicht mal nötig ist bei heap.end() anzufangen. Man kann sicherlich auch ab der stelle pushen, wo headOfCurrentEdge liegt, aber an die komm ich leider nicht. Zumindest weiß ich noch nicht wie.

Wo wir grad beim FibonacciHeap sind, ich hab rausgefunden was meinen so ausbremst. Beim deleteMin muss man ja das minimale Element löschen und alle Kinder in die root Liste einfügen und dann verlinken, wenn 2 Elemente den selben Rang haben.
Dazu fügt man einfach alle Elemente in einen Liste an die x-te Stelle, wobei x der Rang ist. Ist da schon eins wird gelinkt, ansonsten nur eingefügt.
Zur zeit habe ich ein Array aus 100 Elementen (bitte verspottet mich jetzt nicht) und resette das vor jedem deleteMin. Welche Datenstruktur ist dafür am besten geeignet?
-std::vector ist mist, weil es sein kann dass ich erst rootList[5], dann rootList[2] u.s.w. zum Beispiel schreiben will.
-std::map sieht ganz gut aus aber damit hab ich mich noch nicht näher befasst.

Irgendwelche Empfehlungen?

Grüße

Max

drakon

life schrieb:

Bei der einen Laufzeitangabe |E|=|V|^2 vorauszusetzen und bei der anderen nicht, ist jedenfalls nicht ganz fair.

Verstehe ich nicht. Wo habe ich das gemacht? - Ich hatte |E|=|V|^2 in dem von dir gequoteten Ausschnitt, wie auch in meiner Antwort darauf..

Ob |E|=|V|^2 der typische Fall ist, hängt dann wohl von deiner Anwendung ab. Normalerweise würde ich aber erwarten, dass die Implementierung mittels binären Heap effizienter ist als eine Implementierung mit fib Heap. Fib. heaps sind nämlich ihmo eher nur von theoretischen Interesse ;).

Das stimmt schon. Ein F-Heap ist nicht unbedingt besser. Bei sehr dichten Graphen ist der normale Algorithmus von Dijkstra ohne das explizite Speichern des Randes sogar effizienter.
Ich denke mal (ohne jeglichen Beweis liefern zu können), dass bei Fällen, wo der der Algortihmus ohne expl. Rand schlechter ist, als einer mit Rand (aber dennoch recht dicht und gross ist), wird ein F-Heap schon besser sein, aber wie du sagst ist das wohl eher nur in Ausnahmefällen der Fall.

Max3000

Das mit der Map hab ich grad ausprobiert und das ist ja noch langsamer als die mit dem array. Ich glaub ich brauch wirklich hilfe ^^.

life

drakon schrieb:

Verstehe ich nicht. Wo habe ich das gemacht? - Ich hatte |E|=|V|^2 in dem von dir gequoteten Ausschnitt, wie auch in meiner Antwort darauf..

"Ein F-Heap hat aber O(nlogn + m)"

@Max3000:

headOfCurrentEdge->key = v->key + currentEdge->length;
push_heap(&heap[0], (&headOfCurrentEdge)+1, comp);

volkard

Max3000 schrieb:

@ drakon:
Beim Einfügen in den Heap hab ich das so gemacht. Aber ich will ja ein Element verkleinern, was schon im Heap drin ist.

Also mein einfügen sieht so aus:
heap.push_back(headOfCurrentEdge);
push_heap(heap.begin(), heap.end(), comp);
und mein decreaseKey jetzt so:
headOfCurrentEdge->key = v->key + currentEdge->length;
push_heap(heap.begin(), heap.end(), comp);
wobei ich denke dass es nicht mal nötig ist bei heap.end() anzufangen. Man kann sicherlich auch ab der stelle pushen, wo headOfCurrentEdge liegt, aber an die komm ich leider nicht. Zumindest weiß ich noch nicht wie.

Darf nicht! heap.end() ist falsch.
Mußt &(dingWasVersickernSoll)+1 nehmen.

drakon

life schrieb:

drakon schrieb:

Verstehe ich nicht. Wo habe ich das gemacht? - Ich hatte |E|=|V|^2 in dem von dir gequoteten Ausschnitt, wie auch in meiner Antwort darauf..

"Ein F-Heap hat aber O(nlogn + m)"

Ok, hätte das m noch substituieren sollen. Aber das ändert nichts an meiner Aussage. O(n^2) ist besser, als O(n^2 * logn).

@volkard
Imo stimmt das schon. Du fügst zuerst mit push_back was ein und dann rufst du die Funktion auf. Das sollte schon hinhauen oder verstehe ich deinen Einwand falsch?

volkard

drakon schrieb:

Imo stimmt das schon. Du fügst zuerst mit push_back was ein und dann rufst du die Funktion auf. Das sollte schon hinhauen oder verstehe ich deinen Einwand falsch?

Ja, Einfügen geht so.
Aber decreaseKey eines igendwo in der Mitte liegenden Elements nicht.

drakon

Achso. Das meintest du. Ja dort stimme ich dir zu.

Max3000

headOfCurrentEdge->key = v->key + currentEdge->length;
push_heap(&heap[0], (&headOfCurrentEdge)+1, comp);

Das geht leider nicht.
heap ist ein std::vector und das push_heap und alle anderen heap-funktionen wollen einen iterator über meinen vector als argument.
statt &heap[0] sollte also heap.begin() sein.
statt (&headOfCurrentEdge)+1 brauch ich doch sowas wie heap.begin()+positionOfHeadOfEdge+1, oder nicht?

Hab sowieso grad mit diesen Iteratoren zu kämpfen und ich nie weiß an welcher stelle mein Element in der Liste ist.
Das selbe versuch ich grad mit erase, also als kleines Beispiel:

Node<T> *minRoot;
  std::vector<Node<T>*> roots;

  // ...

  roots.erase(minRoot); // wie mach ich sowas?

Also minRoot ist dann in der roots-Liste, aber ich weiß später nicht mehr wo weil ich zuviel hinzufüge.
Der Aufruf erase ist natürlich falsch, weil die Funktion einen Iterator benötigt.

life

Doch das geht so. Probiers doch einfach mal aus.

Abgesehen davon, dass es kompiliert, ist es sogar korrekt: Es ist garantiert, dass die Elemente des vectors direkt hintereinander im Speicher stehen.

Entsprechend kannst du auch die Position eines Elements folgendermaßen erhalten: std::size_t pos = &my_element - &my_vector[0] .

Max3000

Das minRoot ist aber auch ein Pointer. Könnte es daran liegen?
Ich bekomme den Fehler:

error: no matching function for call to ‘std::vector<Node<Vertex>, std::allocator<Node<Vertex>> >::erase(Node<Vertex>**)’

life

Ich bezog mich auf push_heap . erase benötigt tatsächlich einen Iterator.

volkard

life schrieb:

Doch das geht so. Probiers doch einfach mal aus.

Abgesehen davon, dass es kompiliert, ist es sogar korrekt: Es ist garantiert, dass die Elemente des vectors direkt hintereinander im Speicher stehen.

Entsprechend kannst du auch die Position eines Elements folgendermaßen erhalten: std::size_t pos = &my_element - &my_vector[0] .

Wenn ich recht verstanden habe, kommt er deswegen nicht dran:

Node* hierGuck=vec[0];
pop_heap(vec.begin(),vec.end(),comp);vec.pop_back();
for each Node* dortMach in hierGuck.getNeighbors(){
   dortMach->neuBewert();
   push_heap(vec.begin(),/*mistWoLiegtDennDortMach?*/);
}

Max3000

Genau das ist mein Problem ;).
Vielleicht nehm ich ja auch die falsche Datenstruktur?
Ich bräuchte ne verlinkte Liste, wobei ich ein beliebiges Element daraus löschen kann. Dazu müsste ich die Pointer zu den Nachbarn kennen. Also gibts da irgendeinen STL Datentyp, z.b. List mit ListNode, von der ich erben könnte oder sowas? Man könnte sich das zwar selber programmieren, aber das wird sicherlich sehr aufwendig wenn mans ordentlich macht und nicht so schnell wie so ein STL Typ, oder?

volkard

Max3000 schrieb:

Genau das ist mein Problem ;).
Vielleicht nehm ich ja auch die falsche Datenstruktur?
Ich bräuchte ne verlinkte Liste, wobei ich ein beliebiges Element daraus löschen kann. Dazu müsste ich die Pointer zu den Nachbarn kennen. Also gibts da irgendeinen STL Datentyp, z.b. List mit ListNode, von der ich erben könnte oder sowas? Man könnte sich das zwar selber programmieren, aber das wird sicherlich sehr aufwendig wenn mans ordentlich macht und nicht so schnell wie so ein STL Typ, oder?

Das Problem ist, daß Du keine Zeiger auf Nodes nehmen kannst, wenn Du zugleich die Nodes im binären Heap verschieben könen willst.
Da fallen mir auch irgendwie nur häßliche Tricks ein.
Zum Beispiel der:
Du verwaltest nicht Node* im heap, sondern

struct MovableNodePrt{
  Node* ptr;
  MovableNodePrt(Node* p){
    assert(p->revptr==0);//zwei MovableNodePrts für einen Node böse sein
    ptr=p;
    ptr->revptr=this;
  }
  ~MovableNodePrt(){
    ptr->revptr=0;
  }
  friend void swap(MovableNodePrt& a,MovableNodePrt& b){
     swap(a.ptr,b.ptr);
     swap(a.ptr->revptr,a.ptr->revptr);//Damit die Nodes ihren MovableNodePrt im heap 
  //nicht vergessen
  }
  friend bool operator<(MovableNodePrt const& a,MovableNodePrt const& b){
    return *a.ptr<*b.ptr;//juhu, wir sind comp losgeworden
  }
};

Oder Nodes swappeble machen und evtl eine (globale?) Indextabelle dazwischenschalten, auf den der Comparator zugreift. Oder den binären Heap zwar binär lassen aber nicht mehr in ein Array legen, sondern als normalen Baum, allerdings Heap und nicht Sortierbaum. Alles recht unhandlich.

Max3000

Was macht das swap? Wird das intern von dem vector bzw. den heap-funktionen aufgerufen?

Ich habe hier noch das gefunden:
http://www.cplusplus.com/reference/stl/list/

Da kann man ein erase(value) machen.
Die Frage ist nur was passiert im Hintergrund?
Irgendwie muss der dann ja auch erstmal sein node-Element für den Wert finden oder?

life

Am einfachsten wärs wohl in der Node zu speichern, wo die Node im Heap liegt. Problem ist nur, dass man diese Info updaten muss, wenn man push_heap etc aufruft. -> push_heap müsste man selbst implementieren

Also vielleicht doch lieber volkards Lösung ;).

Max3000

Was ist revptr?
Versuch das ganze grad noch zu verstehen ;).
Aber vielen Dank schonmal. Ich glaube auch dass es anders gar nicht mehr geht.

volkard

Max3000 schrieb:

Was macht das swap? Wird das intern von dem vector bzw. den heap-funktionen aufgerufen?

Ja.
Um sicherzugehen noch den Kopierkostruktor wegmachen. Ich editier's oben rein. Dann KANN nur noch swap benutzt werden und DU hast die Garantie, daß alles klappt. Nee, ohne Kopierkonstruktor kein push_back. Oh. Also auch temporär zwei MoveableNodes für einen Node. *heul*