Conor McBride'ın bazı çalışmaları Diff , Dissect , veri türlerinin türevini "tek delikli bağlamlar" ile ilişkilendirir. Yani, türün türevini alırsanız, veri türünün herhangi bir noktada içeriden nasıl göründüğünü gösteren bir veri türüyle kalırsınız.
Örneğin, bir listeniz varsa (Haskell'de)
data List a = [] | a : List a
bu karşılık gelir
data List a = 1 + a * List a
ve biraz matematiksel bir sihir sayesinde,
data ListDeriv a = List a * List a
Bu, listenin herhangi bir noktasında solda bir liste ve sağda bir liste olacağı anlamına gelir. Türev veri yapısını kullanarak orijinal listede gezinebiliriz.
Şimdi, grafiklere benzer bir şey yapmak istiyorum. Grafiklerin ortak bir temsili, aşağıdakiler gibi bir veri türüyle saf bir şekilde uygulanabilen bir dizi köşe ve kenardır:
data Gr a b i = Gr [(i,a)] [(i,i,b)]
Doğru anlıyorsam, bu veri tipinin bir türevi, grafik indeksine göre i
, böyle bir şey olmalıdır.
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)] }
Bunu türevler için ürün kuralı ve zincir kurallarını kullanarak aldım ve muhtemelen bazı hatalar olsa da, genel şemayı takip ediyor gibi görünüyor. Bu yapıda Düğümlere (InNodes yapıcısı) veya Kenarlara (Kenarlarda) odaklanacak ve ilgili verileri görebileceğiniz yere verilecektir.
Ama umduğum bu değildi. Martin Erwigs Fonksiyonel Grafik Kütüphanesi'nin arayüzü ile daha yakından ilgili bir yapı umuyordum. Özellikle, bir düğümde düğümün etiketini temsil eden bir bağlam ve biri giden, diğeri gelen olmak üzere iki bitişik liste görmek istiyorum.
Node a b = ([(i,b)],a,[(i,b)])
Bununla birlikte, bitişiklik gösteriminin türev, yalnız etikel, a
her bir delik konumunda, her bir kenarın bitişiklik gösterimi / diseksiyonu ile ortak bazı terimleri olduğu için umut görüyorum .
Bir türev, orijinal ile aynı işlev olmadığından, ancak türevin bir entegrasyonu (kindof) olduğundan, türevi bir düğüm bağlamları koleksiyonuna dönüştürmeye yarayacak bir çeşit entegrasyon analogu var mı? Orijinal yapıyı kurtarmak için doğrudan bir entegrasyon değil, dikkat edin, ancak orijinaline eşdeğer bir yapı ama daha algoritma dostu bir sunumda.
Varsa, ilişki türü yapıların bazı kolay "köşe ve kenar kümesi" diliyle belirtilebileceğini ve bu yapı ile çalışmak için verimli bir kütüphane elde edebileceğimi umuyorum. Böyle bir uygulama "grafik teorisinin ötesinde" yapıları incelemek için kullanılabilir: hiper grafikler, basit kompleksler ...
Yani. Bu fikir uygulanabilir görünüyor mu? İşe yarar? Bu tür şeyler hakkında daha fazla bilgi edinebileceğim bir çalışma oldu mu?
ek
Curtis F tarafından yorumlandığı gibi , bir dizi düğüm ve kenar tam olarak bir grafik değildir. Ancak, tüm grafikler bu şekilde temsil edilebilir ve bunu yeterince yaygın buluyorum. Kablosuz ağların optimizasyonuna grafik teorisini çeşitli şekillerde uygulayan araştırmalarda kullanılan çok kaba şartname) gördüm . İşte açık erişim örneği DRAND *. Bu, sunum arasındaki bağlantı ve araştırmaya dayalı olarak bazı yazılımların nasıl uygulanabileceği sorusunu gündeme getirmektedir.
Bununla birlikte, giriş spesifikasyonunun den başka bir şeye değiştirilmesine tamamen karşı değilim . Örneğin, bir indeks türü verilen , düğüm etiketler, , ve kenar etiketler, . Daha sonra grafik, dizinlerden etiket ve kenar listesine kadar (yaklaşık olarak) bir işlevdir.
Bu, eminim (Kategori teorisi?)
veya
Yeterli uyarı verildiğinde, bir dizi köşe ve kenar olarak görülebilir. Bununla birlikte, in türevinin anlamlı olup olmadığı açık değildir :
Biri için bir vaat gösterdiğini düşünüyorum, ama daha ileri gitmek için sofistike değilim. Orada daha fazla bağlantı keşfetmek bazı çalışmalar olması gerektiğini biliyorum.
* Bağlantının kopması durumunda alıntı: Rhee, Injong, et al. "DRAND: Kablosuz ad hoc ağlar için dağıtılmış rasgele TDMA zamanlama." Mobil Hesaplamada IEEE İşlemleri 8.10 (2009): 1384-1396.