Esistono tre modi per archiviare un grafico in memoria:
So come scrivere tutti e tre, ma non sono sicuro di aver pensato a tutti i vantaggi e gli svantaggi di ciascuno.
Quali sono i vantaggi e gli svantaggi di ciascuno di questi modi di memorizzare un grafico in memoria?
Risposte:
Un modo per analizzarli è in termini di memoria e complessità temporale (che dipende da come si desidera accedere al grafico).
Memorizzazione dei nodi come oggetti con puntatori l'uno all'altro
Memorizzazione di una matrice di pesi dei bordi
A seconda di quale algoritmo esegui sul grafico e di quanti nodi ci sono, dovrai scegliere una rappresentazione adeguata.
Un altro paio di cose da considerare:
Il modello a matrice si presta più facilmente a grafici con bordi ponderati, memorizzando i pesi nella matrice. Il modello oggetto / puntatore dovrebbe memorizzare i pesi dei bordi in una matrice parallela, che richiede la sincronizzazione con la matrice del puntatore.
Il modello oggetto / puntatore funziona meglio con i grafici diretti che con i grafici non orientati perché i puntatori dovrebbero essere mantenuti a coppie, cosa che può diventare non sincronizzata.
Il metodo oggetti e puntatori soffre di difficoltà di ricerca, come alcuni hanno notato, ma è abbastanza naturale per fare cose come costruire alberi di ricerca binari, dove c'è molta struttura extra.
Personalmente adoro le matrici di adiacenza perché rendono tutti i tipi di problemi molto più facili, utilizzando strumenti della teoria dei grafi algebrici. (La k-esima potenza della matrice di adiacenza fornisce il numero di cammini di lunghezza k dal vertice i al vertice j, per esempio. Aggiungi una matrice identità prima di prendere la k-esima potenza per ottenere il numero di cammini di lunghezza <= k. Prendi un rango n-1 minore del laplaciano per ottenere il numero di alberi spanning ... E così via.)
Ma tutti dicono che le matrici di adiacenza costano memoria! Hanno ragione solo a metà: puoi aggirare questo problema usando matrici sparse quando il tuo grafico ha pochi bordi. Le strutture di dati a matrici sparse svolgono esattamente il lavoro di mantenere un elenco di adiacenze, ma hanno comunque a disposizione l'intera gamma di operazioni con matrici standard, offrendoti il meglio di entrambi i mondi.
Penso che il tuo primo esempio sia un po 'ambiguo: nodi come oggetti e bordi come puntatori. Puoi tenerne traccia memorizzando solo un puntatore a qualche nodo radice, nel qual caso l'accesso a un dato nodo potrebbe essere inefficiente (supponiamo che tu voglia il nodo 4 - se l'oggetto nodo non è fornito, potresti doverlo cercare) . In questo caso, perderai anche porzioni del grafico che non sono raggiungibili dal nodo radice. Penso che questo sia il caso che f64 rainbow assume quando dice che la complessità temporale per accedere a un dato nodo è O (n).
Altrimenti, potresti anche mantenere un array (o hashmap) pieno di puntatori a ciascun nodo. Ciò consente a O (1) di accedere a un dato nodo, ma aumenta leggermente l'utilizzo della memoria. Se n è il numero di nodi ed e è il numero di archi, la complessità spaziale di questo approccio sarebbe O (n + e).
La complessità spaziale per l'approccio a matrice sarebbe lungo le linee di O (n ^ 2) (supponendo che gli archi siano unidirezionali). Se il tuo grafico è scarso, avrai molte celle vuote nella tua matrice. Ma se il tuo grafico è completamente connesso (e = n ^ 2), questo si confronta favorevolmente con il primo approccio. Come dice RG, potresti anche avere meno cache miss con questo approccio se allochi la matrice come un blocco di memoria, il che potrebbe rendere più veloce il seguire molti bordi attorno al grafico.
Il terzo approccio è probabilmente il più efficiente in termini di spazio per la maggior parte dei casi - O (e) - ma renderebbe la ricerca di tutti i bordi di un dato nodo un compito O (e). Non riesco a pensare a un caso in cui questo sarebbe molto utile.
Dai un'occhiata alla tabella di confronto su wikipedia. Fornisce una buona comprensione di quando utilizzare ciascuna rappresentazione di grafici.
C'è un'altra opzione: i nodi come oggetti, anche i bordi come oggetti, ogni bordo essendo allo stesso tempo in due elenchi doppiamente collegati: l'elenco di tutti i bordi che escono dallo stesso nodo e l'elenco di tutti i bordi che vanno nello stesso nodo .
struct Node {
... node payload ...
Edge *first_in; // All incoming edges
Edge *first_out; // All outgoing edges
};
struct Edge {
... edge payload ...
Node *from, *to;
Edge *prev_in_from, *next_in_from; // dlist of same "from"
Edge *prev_in_to, *next_in_to; // dlist of same "to"
};
L'overhead della memoria è grande (2 puntatori per nodo e 6 puntatori per bordo) ma ottieni
La struttura può anche rappresentare un grafico piuttosto generale: multigrafo orientato con loop (cioè puoi avere più bordi distinti tra gli stessi due nodi inclusi più loop distinti - bordi che vanno da x a x).
Una spiegazione più dettagliata di questo approccio è disponibile qui .
Ok, quindi se i bordi non hanno pesi, la matrice può essere un array binario e l'uso di operatori binari può far andare le cose molto, molto velocemente in quel caso.
Se il grafico è scarso, il metodo oggetto / puntatore sembra molto più efficiente. Tenere l'oggetto / i puntatori in una struttura dati appositamente per convincerli a formare un singolo blocco di memoria potrebbe anche essere un buon piano o qualsiasi altro metodo per farli stare insieme.
L'elenco delle adiacenze - semplicemente un elenco di nodi connessi - sembra di gran lunga il più efficiente in termini di memoria, ma probabilmente anche il più lento.
Invertire un grafo orientato è facile con la rappresentazione a matrice e facile con l'elenco di adiacenza, ma non così eccezionale con la rappresentazione dell'oggetto / puntatore.