Warum hat std :: list :: reverse O (n) Komplexität?

Warum hat die Umkehrfunktion für die std::listKlasse in der C ++ - Standardbibliothek eine lineare Laufzeit? Ich würde denken, dass für doppelt verknüpfte Listen die Umkehrfunktion O (1) gewesen sein sollte.

Das Umkehren einer doppelt verknüpften Liste sollte nur das Umschalten der Kopf- und Endzeiger beinhalten.

Hypothetisch reversekönnte O (1) gewesen sein . Es könnte (wieder hypothetisch) ein boolesches Listenmitglied gegeben haben, das angibt, ob die Richtung der verknüpften Liste derzeit dieselbe oder entgegengesetzt zu der ursprünglichen ist, in der die Liste erstellt wurde.

Leider würde dies die Leistung grundsätzlich jeder anderen Operation verringern (allerdings ohne die asymptotische Laufzeit zu ändern). Bei jeder Operation müsste ein Boolescher Wert herangezogen werden, um zu prüfen, ob einem "nächsten" oder "vorherigen" Zeiger eines Links gefolgt werden soll.

Da dies vermutlich als relativ seltene Operation angesehen wurde, spezifizierte der Standard (der keine Implementierungen vorschreibt, sondern nur die Komplexität), dass die Komplexität linear sein könnte. Dies ermöglicht, dass "nächste" Zeiger immer eindeutig dieselbe Richtung bedeuten, was Operationen im allgemeinen Fall beschleunigt.

Es könnte sein , O (1) , wenn die Liste ein Flag speichern würde , die die Bedeutung der „ermöglicht Swapping prev“ und „ next“ Zeiger jeder Knoten. Wenn das Umkehren der Liste eine häufige Operation wäre, könnte eine solche Hinzufügung tatsächlich nützlich sein, und ich kenne keinen Grund, warum die Implementierung nach dem aktuellen Standard verboten wäre . Ein solches Flag würde jedoch das gewöhnliche Durchlaufen der Liste verteuern (wenn auch nur um einen konstanten Faktor), weil statt

current = current->next;

im der operator++Liste Iterator würden Sie bekommen

if (reversed)
  current = current->prev;
else
  current = current->next;

Das ist nicht etwas, das Sie einfach hinzufügen möchten. Angesichts der Tatsache, dass Listen normalerweise viel häufiger durchlaufen werden als umgekehrt, wäre es für den Standard sehr unklug, dies zu tun beauftragen , diese Technik. Daher darf die umgekehrte Operation eine lineare Komplexität aufweisen. Beachten Sie jedoch, dass t ∈ O (1) ⇒ t ∈ O ( n ) ist, sodass, wie bereits erwähnt, die technische Implementierung Ihrer „Optimierung“ zulässig ist.

Wenn Sie aus Java oder einem ähnlichen Hintergrund stammen, fragen Sie sich möglicherweise, warum der Iterator das Flag jedes Mal überprüfen muss. Könnten wir nicht stattdessen zwei unterschiedliche Iteratortypen haben, die beide von einem gemeinsamen Basistyp abgeleitet sind std::list::beginund std::list::rbeginden entsprechenden Iterator haben und polymorph zurückgeben? Während dies möglich wäre, würde dies das Ganze noch schlimmer machen, da das Vorrücken des Iterators jetzt ein indirekter (schwer zu inline) Funktionsaufruf wäre. In Java zahlen Sie diesen Preis ohnehin routinemäßig, aber dies ist einer der Gründe, warum viele Menschen nach C ++ greifen, wenn die Leistung kritisch ist.

Wie Benjamin Lindley in den Kommentaren reversehervorhob, scheint der einzige Ansatz, der vom Standard zugelassen wird, darin zu bestehen, einen Zeiger zurück auf die Liste im Iterator zu speichern, was einen doppelt indirekten Speicherzugriff verursacht.

Da alle Container, die bidirektionale Iteratoren unterstützen, das Konzept von rbegin () und rend () haben, ist diese Frage sicherlich umstritten.

Es ist trivial, einen Proxy zu erstellen, der die Iteratoren umkehrt und über diesen auf den Container zugreift.

Diese Nichtoperation ist in der Tat O (1).

sowie:

#include <iostream>
#include <list>
#include <string>
#include <iterator>

template<class Container>
struct reverse_proxy
{
    reverse_proxy(Container& c)
    : _c(c)
    {}

    auto begin() { return std::make_reverse_iterator(std::end(_c)); }
    auto end() { return std::make_reverse_iterator(std::begin(_c)); }

    auto begin() const { return std::make_reverse_iterator(std::end(_c)); }
    auto end() const { return std::make_reverse_iterator(std::begin(_c)); }

    Container& _c;
};

template<class Container>
auto reversed(Container& c)
{
    return reverse_proxy<Container>(c);
}

int main()
{
    using namespace std;
    list<string> l { "the", "cat", "sat", "on", "the", "mat" };

    auto r = reversed(l);
    copy(begin(r), end(r), ostream_iterator<string>(cout, "\n"));

    return 0;
}

erwartete Ausgabe:

mat
the
on
sat
cat
the

In Anbetracht dessen scheint es mir, dass sich das Normungskomitee keine Zeit genommen hat, um O (1) die umgekehrte Reihenfolge des Containers zu bestimmen, da dies nicht erforderlich ist, und die Standardbibliothek basiert weitgehend auf dem Prinzip, nur das zu beauftragen, was währenddessen unbedingt erforderlich ist Vermeidung von Doppelarbeit.

Nur mein 2c.

Weil es jeden Knoten ( ninsgesamt) durchlaufen und seine Daten aktualisieren muss (der Aktualisierungsschritt ist in der Tat O(1)). Dies macht den gesamten Vorgang O(n*1) = O(n).

Außerdem werden der vorherige und der nächste Zeiger für jeden Knoten ausgetauscht. Deshalb braucht es Linear. Obwohl dies in O (1) möglich ist, wenn die Funktion, die dieses LL verwendet, auch Informationen über LL als Eingabe verwendet, z. B. ob sie normal oder umgekehrt zugreift.

Nur eine Algorithmuserklärung. Stellen Sie sich vor, Sie haben ein Array mit Elementen und müssen es dann invertieren. Die Grundidee besteht darin, bei jedem Element zu iterieren und das Element an der ersten Position in die letzte Position, das Element an der zweiten Position in die vorletzte Position usw. zu ändern. Wenn Sie in die Mitte des Arrays gelangen, werden alle Elemente geändert, also in (n / 2) Iterationen, die als O (n) betrachtet werden.

Es ist O (n), einfach weil es die Liste in umgekehrter Reihenfolge kopieren muss. Jede einzelne Elementoperation ist O (1), aber es gibt n davon in der gesamten Liste.

Natürlich sind einige Operationen mit konstanter Zeit erforderlich, um den Platz für die neue Liste einzurichten und anschließend die Zeiger zu ändern usw. Die O-Notation berücksichtigt keine einzelnen Konstanten, sobald Sie einen n-Faktor erster Ordnung einschließen.