Perché std :: list :: reverse ha complessità O (n)?

Perché la funzione inversa per la std::listclasse nella libreria standard C ++ ha un runtime lineare? Penso che per elenchi doppiamente collegati la funzione inversa avrebbe dovuto essere O (1).

L'inversione di un elenco doppiamente collegato dovrebbe comportare solo il cambio dei puntatori di testa e coda.

Ipoteticamente, reverseavrebbe potuto essere O (1) . Lì (di nuovo ipoteticamente) avrebbe potuto esserci un membro dell'elenco booleano che indica se la direzione dell'elenco collegato è attualmente la stessa o opposta a quella originale in cui è stato creato l'elenco.

Sfortunatamente, ciò ridurrebbe le prestazioni di praticamente qualsiasi altra operazione (anche se senza cambiare il runtime asintotico). In ogni operazione, un booleano dovrebbe essere consultato per valutare se seguire un puntatore "successivo" o "precedente" di un collegamento.

Dato che questo era presumibilmente considerato un'operazione relativamente poco frequente, lo standard (che non impone implementazioni, solo complessità), specificava che la complessità poteva essere lineare. Ciò consente ai puntatori "successivi" di indicare sempre la stessa direzione in modo inequivocabile, accelerando le operazioni del caso comune.

Si potrebbe essere O (1) se la lista potrebbe memorizzare un flag che permette di scambiare il significato del “ prev” e “ next” puntatori ogni nodo ha. Se invertire l'elenco sarebbe un'operazione frequente, tale aggiunta potrebbe in effetti essere utile e non conosco alcun motivo per cui implementarla sarebbe vietata dalla norma attuale. Tuttavia, avere una tale bandiera renderebbe la corsa ordinaria dell'elenco più costosa (se non altro per un fattore costante) perché invece di

current = current->next;

nella operator++lista dell'iteratore, otterresti

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

che non è qualcosa che potresti decidere di aggiungere facilmente. Dato che gli elenchi vengono solitamente attraversati molto più spesso di quanto non siano invertiti, sarebbe poco saggio che lo standard imponga questa tecnica. Pertanto, l'operazione inversa può avere una complessità lineare. Si noti, tuttavia, che t ∈ O (1) ⇒ t ∈ O ( n ), quindi, come menzionato in precedenza, l'implementazione della "ottimizzazione" tecnicamente sarebbe consentita.

Se provieni da uno sfondo Java o simile, potresti chiederti perché l'iteratore deve controllare la bandiera ogni volta. Non potremmo invece avere due tipi di iteratori distinti, entrambi derivati ​​da un tipo di base comune, e avere std::list::begine std::list::rbeginrestituire polimorficamente l'iteratore appropriato? Se possibile, ciò renderebbe il tutto ancora peggio perché far avanzare l'iteratore sarebbe una chiamata di funzione indiretta (difficile da incorporare) ora. In Java, si paga comunque questo prezzo regolarmente, ma ancora una volta, questo è uno dei motivi per cui molte persone cercano C ++ quando le prestazioni sono fondamentali.

Come sottolineato da Benjamin Lindley nei commenti, poiché reversenon è consentito invalidare gli iteratori, l'unico approccio consentito dallo standard sembra essere quello di memorizzare un puntatore all'elenco all'interno dell'iteratore che provoca un accesso alla memoria doppio indiretto.

Sicuramente poiché tutti i contenitori che supportano gli iteratori bidirezionali hanno il concetto di rbegin () e rend (), questa domanda è controversa?

È banale costruire un proxy che inverte gli iteratori e acceda al contenitore attraverso quello.

Questa non operazione è effettivamente O (1).

ad esempio:

#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;
}

uscita prevista:

mat
the
on
sat
cat
the

Alla luce di ciò, mi sembra che il comitato per le norme non abbia impiegato del tempo per imporre O (1) l'ordine inverso del contenitore perché non è necessario, e la biblioteca standard è in gran parte costruita sul principio di imporre solo ciò che è strettamente necessario mentre evitando la duplicazione.

Solo il mio 2c.

Perché deve attraversare ogni nodo ( ntotale) e aggiornare i loro dati (il passaggio di aggiornamento è effettivamente O(1)). Questo rende l'intera operazione O(n*1) = O(n).

Scambia anche il puntatore precedente e successivo per ogni nodo. Ecco perché ci vuole Linear. Sebbene possa essere fatto in O (1) se la funzione che utilizza questo LL prende anche informazioni su LL come input, come se accedesse normalmente o al contrario.

Solo una spiegazione dell'algoritmo. Immagina di avere un array con elementi, quindi devi invertirlo. L'idea di base è quella di iterare su ciascun elemento cambiando l'elemento nella prima posizione nell'ultima posizione, l'elemento nella seconda posizione per penultima posizione e così via. Quando raggiungi il centro dell'array avrai tutti gli elementi cambiati, quindi in (n / 2) iterazioni, che è considerato O (n).

È O (n) semplicemente perché deve copiare l'elenco in ordine inverso. Ogni singola operazione di elemento è O (1) ma ce ne sono n nell'intero elenco.

Naturalmente ci sono alcune operazioni a tempo costante coinvolte nell'impostazione dello spazio per il nuovo elenco e nella successiva modifica dei puntatori, ecc. La notazione O non considera le singole costanti una volta incluso un fattore n del primo ordine.