Qual è lo scopo di implementare uno Stack usando due code?

Ho la seguente domanda per i compiti:

Implementare i metodi stack push (x) e pop () usando due code.

Mi sembra strano perché:

• Uno stack è una coda (LIFO)
• Non vedo perché occorrano due code per implementarlo

Ho cercato in giro:

• GeeksForGeeks
• StackOverflow

e ho trovato un paio di soluzioni. Questo è quello che ho finito con:

public class Stack<T> {
    LinkedList<T> q1 = new LinkedList<T>();
    LinkedList<T> q2 = new LinkedList<T>();

    public void push(T t) {
        q1.addFirst(t);
    }

    public T pop() {
        if (q1.isEmpty()) {
            throw new RuntimeException(
                "Can't pop from an empty stack!");
        }

        while(q1.size() > 1) {
            q2.addFirst( q1.removeLast() );
        }

        T popped = q1.pop();

        LinkedList<T> tempQ = q1;
        q1 = q2;
        q2 = tempQ;

        return popped;
    }
}

Ma non capisco quale sia il vantaggio rispetto all'utilizzo di una singola coda; la versione a due code sembra inutilmente complicata.

Supponiamo che scegliamo che i push siano i più efficienti dei 2 (come ho fatto sopra), pushrimarrebbero gli stessi e poprichiederebbero semplicemente di ripetere l'ultimo elemento e di restituirlo. In entrambi i casi, pushsarebbe O(1)e popsarebbe O(n); ma la versione a coda singola sarebbe drasticamente più semplice. Dovrebbe richiedere solo un singolo ciclo.

Mi sto perdendo qualcosa? Qualsiasi approfondimento qui sarebbe apprezzato.

Non c'è alcun vantaggio: questo è un esercizio puramente accademico.

Un molto tempo fa, quando ero una matricola al college avevo un esercizio simile ¹ . L'obiettivo era insegnare agli studenti come utilizzare la programmazione orientata agli oggetti per implementare algoritmi invece di scrivere soluzioni iterative usando forloop con contatori di loop. Invece, combina e riutilizza le strutture di dati esistenti per raggiungere i tuoi obiettivi.

Non userai mai questo codice in Real World ^TM . Quello che devi togliere da questo esercizio è come "pensare fuori dagli schemi" e riutilizzare il codice.

Tieni presente che dovresti utilizzare l' interfaccia java.util.Queue nel tuo codice anziché utilizzare direttamente l'implementazione:

Queue<T> q1 = new LinkedList<T>();
Queue<T> q2 = new LinkedList<T>();

Ciò consente di utilizzare altre Queueimplementazioni, se lo si desidera, oltre a nascondere ² metodi LinkedListche potrebbero aggirare lo spirito Queuedell'interfaccia. Questo include get(int)e pop()(mentre il tuo codice viene compilato, c'è un errore logico in là dato i vincoli del tuo compito. Dichiarare le tue variabili come Queueinvece di LinkedListrivelarlo). Lettura correlata: Comprensione della "programmazione di un'interfaccia" e Perché le interfacce sono utili?

^{1 _{Ricordo ancora: l'esercizio era di invertire uno Stack utilizzando solo metodi nell'interfaccia Stack e nessun metodo di utilità in java.util.Collectionso altre classi di utilità "solo statiche". La soluzione corretta prevede l'utilizzo di altre strutture di dati come oggetti di memorizzazione temporanei: devi conoscere le diverse strutture di dati, le loro proprietà e come combinarle per farlo. La maggior parte della mia classe CS101 non ha mai programmato prima.}}

^{2 _{I metodi sono ancora presenti, ma non è possibile accedervi senza i tipi cast o reflection. Quindi non è facile usare quei metodi non in coda.}}

Non ci sono vantaggi Hai capito correttamente che l'uso di Code per implementare uno Stack porta a un'orribile complessità temporale. Nessun programmatore (competente) farebbe mai qualcosa del genere nella "vita reale".

Ma è possibile Puoi usare un'astrazione per implementarne un'altra e viceversa. Uno Stack può essere implementato in termini di due code e allo stesso modo è possibile implementare una coda in termini di due stack. Il vantaggio di questo esercizio è:

• ricapitoli Stack
• ricapitolando le code
• ti abitui al pensiero algoritmico
• impari algoritmi relativi allo stack
• puoi pensare a compromessi negli algoritmi
• realizzando l'equivalenza di code e pile, colleghi vari argomenti del tuo corso
• ottieni esperienza pratica di programmazione

In realtà, questo è un ottimo esercizio. Dovrei farlo da solo adesso :)

C'è sicuramente un vero scopo per fare una fila di due pile. Se si utilizzano strutture di dati immutabili da un linguaggio funzionale, è possibile inserire in una pila di oggetti pushable ed estrarre da un elenco di oggetti poppable. Gli oggetti visualizzabili vengono creati quando tutti gli oggetti sono stati eliminati e la nuova pila estraibile è il contrario della pila sospendibile, dove la nuova pila sospendibile è vuota. È efficiente.

Per quanto riguarda uno stack composto da due code? Ciò potrebbe avere senso in un contesto in cui sono disponibili molte code veloci e di grandi dimensioni. È decisamente inutile come questo tipo di esercizio Java. Ma potrebbe avere senso se si tratta di canali o code di messaggistica. (ovvero: N messaggi accodati, con un'operazione O (1) per spostare (N-1) gli elementi in primo piano in una nuova coda.)

L'esercizio è inutilmente concepito da un punto di vista pratico. Il punto è costringerti a utilizzare l'interfaccia della coda in modo intelligente per implementare lo stack. Ad esempio, la soluzione "Una coda" richiede che si esegua l'iterazione sulla coda per ottenere l'ultimo valore di input per l'operazione "pop" dello stack. Tuttavia, una struttura di dati in coda non consente di scorrere i valori, è necessario accedervi nel primo in, primo in uscita (FIFO).

Come altri hanno già notato: non esiste alcun vantaggio nel mondo reale.

Ad ogni modo, una risposta alla seconda parte della tua domanda, perché non semplicemente usare una coda, è oltre Java.

In Java anche l' Queueinterfaccia ha un size()metodo e tutte le implementazioni standard di quel metodo sono O (1).

Ciò non è necessariamente vero per l'elenco link ingenuo / canonico implementato da un programmatore C / C ++, che manterrebbe solo i puntatori al primo e ultimo elemento e ogni elemento un puntatore al successivo elemento.

In tal caso size()è O (n) e dovrebbe essere evitato nei cicli. O l'implementazione è opaco e fornisce solo il minimo indispensabile add()e remove().

Con una tale implementazione dovresti prima contare il numero di elementi trasferendoli nella seconda coda, trasferire gli n-1elementi nella prima coda e restituire l'elemento rimanente.

Detto questo, probabilmente non inventerebbe qualcosa del genere se vivi in ​​Java-land.

È difficile immaginare un uso per tale implementazione, è vero. Ma la maggior parte del punto è dimostrare che può essere fatto .

In termini di usi reali per queste cose, tuttavia, posso pensare a due. Un uso per questo è l'implementazione di sistemi in ambienti vincolati che non sono stati progettati per questo : ad esempio, i blocchi di pietra rossa di Minecraft si presentano per rappresentare un sistema completo di Turing, che le persone hanno usato per implementare circuiti logici e persino intere CPU. Nei primi giorni di gioco basato su script, molti dei primi robot di gioco sono stati implementati in questo modo.

Ma puoi anche applicare questo principio al contrario, assicurandoti che qualcosa non sia possibile in un sistema quando non vuoi che sia . Ciò può emergere in contesti di sicurezza: ad esempio, potenti sistemi di configurazione possono essere una risorsa, ma ci sono ancora gradi di potenza che potresti preferire non dare agli utenti. Ciò limita ciò che è possibile consentire al linguaggio di configurazione, affinché non venga sovvertito da un utente malintenzionato, ma in questo caso è quello che si desidera.