La derivata di un grafico è correlata agli elenchi di adiacenza?


14

Alcune delle opere di Conor McBride, Diff , Dissect , mettono in relazione la derivata dei tipi di dati con il loro "tipo di contesti a foro singolo". Cioè, se prendi la derivata del tipo ti viene lasciato un tipo di dati che ti mostra come il tipo di dati appare dall'interno in un dato punto.

Quindi, ad esempio, se hai un elenco (in Haskell)

data List a = [] | a : List a

questo corrisponde a

data List a = 1 + a * List a

e attraverso un po 'di magia matematica, la derivata è

data ListDeriv a = List a * List a

che viene interpretato nel senso che in qualsiasi punto dell'elenco ci sarà un elenco a sinistra e un elenco a destra. È possibile scorrere l'elenco originale utilizzando la struttura dei dati derivati.

Ora sono interessato a fare qualcosa di simile con i grafici. Una rappresentazione comune di grafici è un insieme di vertici e spigoli, che potrebbe essere implementato ingenuamente con un tipo di dati come:

data Gr a b i = Gr [(i,a)] [(i,i,b)]

Se lo capisco correttamente, un derivato di questo tipo di dati, rispetto all'indice del grafico i, dovrebbe essere qualcosa di simile.

data GrDeriv a b i = d/di (Gr a b i)
     = d\di ( [a*i] * [b*i^2] )
     = (d\di [a*i]) * [b*i^2] ) + [a*i]*(d/di [b*i^2])
     = (a* [a*i] * [a*i]) * [b*i^2] ) 
       + [a*i] * (2*b*i) *[b*i^2]*[b*i^2])
     = InNodes { nodesLeft :: [(a,i)]
               , nodeLbl :: a
               , nodesRight :: [(a,i)]
               , edges :: [(b,i,i)] }
     | InEdges { nodes :: [(a,i)]
               , adjNode :: Either (b,i) (b,i)
               , edgesLeft :: [(b,i,i)]
               , edgesRight :: [(b,i,i)] }

Ho ottenuto questo attraverso l'uso della regola del prodotto e delle regole della catena per i derivati, e sebbene possibilmente ci siano alcuni errori, sembra seguire lo schema generale. In questa struttura sarai focalizzato su Nodi (costruttore InNodes) o Bordi (Nei bordi) e dato il posto vedrai i dati rilevanti.

Ma non è quello che speravo. Speravo in un costrutto più strettamente correlato all'interfaccia della biblioteca grafica funzionale Martin Erwigs. In particolare, voglio vedere in un nodo un contesto che rappresenta l'etichetta del nodo e due elenchi di adiacenza, uno per l'esterno e uno per l'arrivo.

Node a b = ([(i,b)],a,[(i,b)])

Vedo speranza, tuttavia, poiché la rappresentazione di adiacenza ha alcuni termini in comune con il derivato, l'etichetta solitaria a, in ogni posizione del foro, la rappresentazione / dissezione di adiacenza di ciascun bordo.

Poiché una derivata non è la stessa funzione dell'originale, ma un'integrazione della derivata è (kindof), esiste una sorta di analogo dell'integrazione che servirà a trasformare la derivata in una raccolta di contesti di nodi? Non un'integrazione diretta per recuperare la struttura originale, intendiamoci, ma una struttura equivalente all'originale ma in una rappresentazione più algoritmica.

In tal caso, spero che le strutture del tipo di relazione possano essere specificate da un linguaggio semplice "insieme di vertici e spigoli" e che possa derivare una libreria efficiente per lavorare con quella struttura. Una simile implementazione potrebbe essere usata per studiare strutture "al di là della teoria dei grafi": ipergrafie, complessi simpliciali ...

Così. Questa idea sembra fattibile? Utile? C'è stato qualche studio su questo tipo di cose di cui potrei leggere di più?

appendice

Come commentato da Curtis F , un insieme di nodi e bordi non è esattamente un grafico. Tuttavia, tutti i grafici possono essere rappresentati da tale, e trovo che sia una presentazione abbastanza comune. Ho visto (la specifica molto approssimativa) utilizzato nella ricerca che applica la teoria dei grafi alle ottimizzazioni delle reti wireless in vari modi. Ecco un esempio ad accesso aperto, DRAND *. Ciò solleva la questione, qual è il legame tra la presentazione e come alcuni software potrebbero essere implementati in base alla ricerca.G=(V,E)

Detto questo, non sono del tutto contrario a cambiare le specifiche di input da a qualcos'altro. Ad esempio, dato un indice di tipo , etichette dei nodi, , e le etichette di bordo, . Quindi il grafico è (approssimativamente) una funzione dagli indici a un'etichetta e un elenco di spigoli.G=(V,E)IVE

G=I(VIE)

Questo, sono abbastanza sicuro che possa essere espresso (teoria delle categorie?) Come

(1)G=(VEI)I

o

G=VIEII

che può essere visto come un insieme di vertici e spigoli - dati abbastanza avvertimenti. Tuttavia, non è chiaro se la derivata di sia significativa:(1)

G=ln(VEI)(VEI)I(ln(E)VEI)

Io per primo penso che mostri qualche promessa, ma mi manca la raffinatezza per andare oltre. So che ci deve essere qualche lavoro là fuori per esplorare ulteriormente la connessione.

* In caso di interruzione del collegamento, citazione: Rhee, Injong, et al. "DRAND: programmazione TDMA randomizzata distribuita per reti wireless ad hoc." Transazioni IEEE su Mobile Computing 8.10 (2009): 1384-1396.


Il link fornito per la ricerca è morto. Puoi dare un link più permanente, come il DOI o il diario in cui è stato pubblicato?
Curtis F,

Risposte:


5

Il tuo tipo Grnon corrisponde realmente ai grafici, perché include molti casi che non sono chiaramente grafici, poiché gli indici dei bordi non devono necessariamente essere indici di vertici reali.

Per esempio,

V={A,B}E={(C,D,e)}

non è un grafico, ma è consentito nel tuo tipo come

Gr [(1, A), (2, B)] [(3, 4, e)]

Piuttosto, il tuo Grcorrisponde letteralmente a un elenco di indici etichettati e a un elenco separato, non correlato, di coppie di indici etichettate. Questo è il motivo per cui si ottiene una derivata così "letterale" Grche non corrisponde ai "buchi" nei grafici.

C'è anche lo sfortunato problema di preoccuparsi dell'ordine dei vertici / spigoli (visibili nella nodesLeft/Righte edgesLeft/Rightdistinzioni) ma questo può essere risolto usando un Setinvece di un elenco.


Ecco un tipo espresso in Haskell che penso corrisponda più da vicino ai grafici (non vuoti):

data Graph v e = Lone v | Joined v (Graph (v, ([e], [e])) e)

Per semplicità, prenderò invece in considerazione grafici completi, semplici e non indirizzati:

data Graph v e = Lone v | Joined v (Graph (v, e) e)

(Per rilassare la completezza, e = Boolsegna la presenza del bordo)

Nota che Graphè ricorsivo (e in effetti, parametricamente ricorsivo). Questo è ciò che ci consente di limitare il tipo a soli grafici e non solo a elenchi di adiacenza combinati con elenchi di vertici.

Scritto più algebricamente,

sol(v,e)=v+v*sol(v*e,e)

evsol

sol(v)=v+v*sol(v*e)

Espandendoci ripetutamente, otteniamo il punto fisso

G(v)=v1e(12)+v2e(22)+v3e(32)+v4e(42)+

Questo ha senso, dato che lo è anche un grafico (completo)

  • Uno vertici e nessun bordo
  • Due vertici e un bordo
  • Tre vertici e tre bordi
  • Quattro vertici e quattro scelgono 2 = 6 bordi
  • ....

KsolK(v)=vKe(K2)sol(v)=sol1(v)+sol2(v)+...

che ha un derivato

ddvsol(v)=Σio=1solio'(v)

Gk(v)=ddv[vkek(k1)2]=kvk1ek(k1)2

Gk1(v)=vk1e(k1)(k2)2Gk(v)=Gk1(v)kek1

kk1k1k1k

data SimpleGraph v e = Lone v | Joined v (SimpleGraph (v, e) e)

data SimpleGraphHole v e = Empty
                         | InsertLater v (SimpleGraphHole (v, e) e)
                         | InsertHere (SimpleGraph (v, e) e)

Ordine di riparazione in questo grafico

Questa versione della struttura di dati Graph è fondamentalmente un elenco collegato e quindi codifica l'ordine dei vertici. Sebbene ciò possa essere risolto nella versione della tua lista di adiacenza usando un Set, qui non è così diretto.

Penso che tu possa modificare una struttura di dati ad albero per fare lo stesso tipo di ricorsione parametrica, con la radice che gioca il ruolo che la "testa" svolge SimpleGraph. Dall'interfaccia degli insiemi di alberi risultanti, l'ordine / la struttura sottostante diventa invisibile (o persino canonico, se non sei interessato agli aggiornamenti rapidi).

Il tuo derivato proposto

Hai proposto un tipo di derivato; Lo cambierò per confondere le etichette e gli indici come ho fatto:([(v,e)], [(v,e)])

1(1ve)2C+v1ve(v, [(v, e)])

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.