Add `inedges`, `outedges` and `edges(g, v)`

Aperta
#255 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
julia
Ambito
data

Direzione di ricerca

Inizia esaminando l’interfaccia AbstractEdge e gli entry point esistenti inneighbors, outneighbors, neighbors, all_neighbors ed edges menzionati nell’issue. Determina se gli iteratori degli archi specifici per vertice debbano appartenere all’interfaccia e come debbano essere costruiti i tipi di arco specifici del grafo; il lavoro è completato quando il design dell’API è concordato e sono definiti il suo impatto sull’interfaccia e sulla sua adozione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Since the AbstractEdge type is part of the graphs interface, I think it would make sense to have something similar to inneighbors, outneighbors and neighbors, which behaves in pretty much the same way, but returns the appropriate edges, starting/ending at the given vertex.

Something like:

inedges(g,v) = Edge.(inneighbors(g,v), v)
outedges(g,v) = Edge.(v, outneighbors(g,v))
edges(g,v) = outedges(g,v)

(with appropriate types and all that of course)

  • The last definition would overload the edges function used to get an iterator over ALL edges, when called without a vertex, which seems sufficiently different to maybe find a different name for that function?
  • We seem to have all_neighbors, which could similarly be extended to all_edges(g, v) (If done, having edges(g, v) and all_edges(g, v) but not all_edges(g) would be very strange and confusing)

Since every graph type can come with its own edge type(s), I guess these functions would need to go into the interface and every subsequent package would need to define their own version, calling their own edge constructors. Is that right? Or is there any way around that? (Since most packages seem to use the SimpleGraphs edge anyway, this might not be too big of a problem in terms of adoption?)

If this proposal seems sensible , I would build a PR for it, but, since changing the interface seems quite fundamental, I would like to first get some feedback and suggestions on this.

Lingua principale
Julia
Stelle
540
Fork
130
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di JuliaGraphs/Graphs.jl

Tutte le issue di JuliaGraphs/Graphs.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.