-
Notifications
You must be signed in to change notification settings - Fork 6
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
Return correct type add_vertex! and add_vertices! #17
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportBase: 92.46% // Head: 91.90% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #17 +/- ##
==========================================
- Coverage 92.46% 91.90% -0.56%
==========================================
Files 5 6 +1
Lines 345 346 +1
==========================================
- Hits 319 318 -1
- Misses 26 28 +2
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Thanks for the issue. This design of returning indices when adding new vertex in I am not willing to change this convention because there exists some packages depending on Graphs.add_vertex!(meta_graph::MetaGraph{Multigraph}, label, data) Please feel free to ask me any questions about this package. |
Thank you for giving the time to look at this PR. I see.
Apart from the fact that this will be type piracy, I think the authors of MetaGraphsNext.jl will not be happy to add an extra dependency to this package. Seeing the dependent packages, it appears that you are involved in them, i.e. you could potentially apply the changes yourself. So forgive me but I would like to ask again, and since I know this change is breaking, please take your time with this. |
There is no need to add dependency of Multigraphs in MetaGraphsNext. Both of these packages are paralleled packages based on the Graphs API. I think the correct place to do the function overloading patch is in your own projects or packages. Would you like to discuss about the use cases of having meta-multigraph? The data structure design in Graphs and Multigraphs are quite different. For example, SimpleGraph uses Array to store the adjacent list while Multigraph uses dictionary. Therefore, removing vertices will change indices in SimpleGraph but not for the Multigraph. Those different cause different API return types. Back to 2020 when we started developing this package, the API suggestion was still not mature. But now the API convention of Graphs is better. But I still did not find the API suggestion about |
Nothing extravagant. I just need a multigraph structure with each edge having some properties and I don't want to carry around an extra data structure.
Up until now, I was relying on the I searched a little bit further in some discussions (JuliaGraphs/Graphs.jl#122, JuliaGraphs/Graphs.jl#146, JuliaGraphs/Graphs.jl#165) and it appears that there are motives to change this. They propose to return the index of the added vertex as an alternative. I suppose in this sense, your package is okey. Maybe add a Multigraphs.jl/src/abstract_multigraph.jl Line 129 in 6ec2766
Now the struggle is the MetaGraphsNext.jl is relying on the current API and Multigraphs.jl is sort of relying in the forthcoming. |
Thanks for the discussion. It seems still too early to change the design. Let us keep track on the Graphs 2.0 API standard. For your current usage, a patch might be the simplest way to intergrate meta-multigraphs. |
add_vertex!
is supposed to return aBool
andadd_vertices!
an integer notating the number of vertices that were added.Usually
add_vertices
uses iterativelyadd_vertex
, but this package deals with this the other way around.really, why do this ? The way it's done now,
add_vertices
doesn't also check for overflows.I stumbled into this problem because I tried playing with MetaGraphsNext.MetaGraph{Multigraph} and it hit an error here: https://github.com/JuliaGraphs/MetaGraphsNext.jl/blob/71cf31d8710fa419896af3ae03b9d4f943844402/src/graphs.jl#L117