Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Methode getEdge #7

Open
Yomguithereal opened this issue Feb 18, 2017 · 7 comments
Open

Methode getEdge #7

Yomguithereal opened this issue Feb 18, 2017 · 7 comments

Comments

@Yomguithereal
Copy link

Ici tu utilises la méthode getEdge qui n'existe plus dans les dernières versions de graphology.

Ses seuls cas d'usage étaient effectivement de récuperer la clé d'un arc pour lire des attributes mais comme les méthodes d'attributs peuvent prendre des combo {source,target} il a été décidé de les enlever parce qu'elle sont curieuses: elles ne marchent pas sur un graph multi et il n'existe pas de méthode getNode.

Mais ton cas est interessant là et demande peut-être qu'on réattaque la question sous un angle différent.

@luccitan
Copy link
Owner

Je n'avais même pas remarqué la possibilité d'utiliser la méthode getEdgeAttribute via le combo {source, target}

Puisque le cas du multigraphe n'est pas géré pour le moment, je vais privilégier cette manière alors

@luccitan luccitan added the to-do label Feb 20, 2017
@luccitan
Copy link
Owner

Pardon, je m'étais avancé trop vite dans la problématique de l'issue.
En effet j'utilise getEdge pour récupérer un edge depuis ses deux extrémités, son poids étant stocké au début pour réduire le temps de calcul.

Je ne vois pas de solution plus optimale sans l'utilisation de getEdge et/ou l'utilisation d'un objet mappant ces poids.

@luccitan luccitan added discussion and removed to-do labels Feb 21, 2017
@Yomguithereal
Copy link
Author

Alors, je sais que c'est moi qui t'avais dit que machin truc chose c'était utile de stocker les poids qqpart mais en réalité c'est peut être pas si utile et un:

graph.getEdgeAttribute(source, target, 'weight');

Après ça risque de merder pour les graphes mixed.

Je considère le rajout d'une méthode #.edge qui ne marcherait que pour les graphes simples.

@Yomguithereal
Copy link
Author

Je suis en train de considérer le rajout de ce genre de méthode mais il y a quand même un catch. Même avec la méthode getEdge, dans les graphe mixed tu as un soucis dans la mesure où les accesseurs à base {source,target} renvoie l'arc directed si les deux existent. Que se passe-t-il dans ton algo exactement si on y passe un graphe mixed?

@luccitan
Copy link
Owner

Dans le cas que tu as pointé , il n'y a pas de souci avec les graphes mixtes.
Pouur le calcul du between.old, une arête est comptée 2x, comme si c'était une doublette d'arcs opposés. Puisque le graphe n'est pas multi, il ne peut pas y avoir d'arête ET des arcs entre deux noeuds

--> soit il y a 1 ou 2 arcs, et alors leur poids sera rajouté s'ils sont présents
--> soit il y a une seule arête, et elle sera comptée deux fois.

@Yomguithereal
Copy link
Author

Si c'est le cas un graph.getEdgeAttribute(source, target, 'weight') suffit.

@Yomguithereal
Copy link
Author

Je suis en train de rajouter une méthode #.edge et consorts sur la v0.7.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants