-
Notifications
You must be signed in to change notification settings - Fork 473
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
New package: NahaGraphs v0.1.0 #96626
New package: NahaGraphs v0.1.0 #96626
Conversation
JuliaRegistrator
commented
Dec 6, 2023
•
edited
Loading
edited
- Registering package: NahaGraphs
- Repository: https://github.com/MarkNahabedian/NahaGraphs.jl
- Created by: @MarkNahabedian
- Version: v0.1.0
- Commit: 0dc1de3f3f4b5dc54c2a523445ec9a2861862aed
- Reviewed by: @MarkNahabedian
- Reference: Register this package MarkNahabedian/NahaGraphs.jl#1 (comment)
- Release notes:
Your
Note that the guidelines are only required for the pull request to be merged automatically. However, it is strongly recommended to follow them, since otherwise the pull request needs to be manually reviewed and merged by a human. After you have fixed the AutoMerge issues, simple retrigger Registrator, which will automatically update this pull request. You do not need to change the version number in your If you do not want to fix the AutoMerge issues, please post a comment explaining why you would like this pull request to be manually merged. Then, send a message to the Since you are registering a new package, please make sure that you have also read the package naming guidelines: https://julialang.github.io/Pkg.jl/dev/creating-packages/#Package-naming-guidelines-1 If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text |
UUID: fd225a7d-cc45-47cf-8742-8ffafb057088 Repo: https://github.com/MarkNahabedian/NahaGraphs.jl.git Tree: 5e6fac6731a77b605bbedf634d8c78ade5a0dc10 Registrator tree SHA: 17aec322677d9b81cdd6b9b9236b09a3f1374c6a
b9a16fa
to
97eff1f
Compare
Hi, and congrats on the new package! There are already plenty of options for graph formats, can I maybe ask why you needed to roll out a new one? Also the fact that the package seems named after yourself makes me doubt whether it's intended for wider use. |
@gdalle: The reason I'm considering registering NahaGraphs.jl is that I'm using it in PanelCutting.jl, which I would eventually like to register. I'm looking at MetaGraphs to see if it will meet that use case. It's a bit annoying in that I need to maintain a mapping between that application's objects, which the graph nodes represent, and integers, which seem to be the only things that Graphs.jl and its friends understand. There would still be the question of where to put the code that, given a graph, writes a GraphViz dot file. Maybe I can get it added to https://github.com/JuliaGraphs/GraphViz.jl. I expect the maintainers of that package might welcome code to write dot files, but might not want to support another package's graph representation when that package has its own, which, sadly, is not documented. Lookiing at the source code, this appears to just be a vaneer over a C library. I wich they outright said that. Until I either resolve these or give up on them, registration of NahaGraphs.jl should be blocked. |
I've looked at replacing PanelCutting's use of NahaGraphs with MetaGraphs and Graphs. Neither Graphs nor MetaGraphs provide an efficient way to map between objects of the application and nodes of the graph. I don't understand how those packages can be at all useful without such a mechanism. I can wrap a MetaGraph with a struct that provides a Dict which maps from application objects to graph node numbers. I can't imagine ever using Graohs or MetaGraphs without such a wrapper. Thus, I'd need to put that wrapper and the related code into a package so that it's available where needed. That package might as well be NahaGraphs or whatever I rename it to. |
Actually, both MetaGraphs.jl and its successor MetaGraphsNext.jl do provide this functionality.
Does that answer your needs? |
Thanks for your help. I find the documentation in the form of examples unrelated to my needs to be useless. There's no conceptual overview. The only thing left is to take stabs in the dark using I want to include arbitrary Julia objects as nodes in a graph. Here's a minimal example:
|
While I agree that the documentation is lacking, please remember that no one is paid to take care of it, and that volunteer time is also lacking. |
Here's a working example using MetaGraphsNext.jl, which is more efficient than MetaGraphs.jl. using Graphs
using MetaGraphsNext
let
next_thingy_id = 1
struct Thingy
id
function Thingy()
t = new(next_thingy_id)
next_thingy_id += 1
t
end
end
end
Base.isless(t1::Thingy, t2::Thingy) = isless(t1.id, t2.id)
g = MetaGraph(Graph(); label_type=Thingy)
t1 = Thingy()
t2 = Thingy()
t3 = Thingy()
add_vertex!(g, t1)
add_vertex!(g, t2)
add_vertex!(g, t3)
add_edge!(g, t1, t2)
add_edge!(g, t1, t3)
neighbors(g, code_for(g, t3)) |
Thanks for the working example. Is an
I'd still need to implement methods as an abstraction barrier to those implementation details. I would still also need code for generating a GraphViz dot file from such a graph. GraphViz_jll is poorly documented and does not appear to implement the same graph interface as other graph packages. Based on the documentation, I don't know if it will write dot files or only read them. I'm happy to either trim down (and rename) NahaGraphs to just provide the dot writing code if another graph package meets my other needs. The dot code requires that the graph expose interfaces which iterate over all nodes and all edges of the graph. In addition, it requires the application to provide methods which
I see you're a JuliaGraphs contributor. If you feel that writing GraphViz dot files fits in to that family of packages, wecan talk about integrating it there. I'd need the abstraction barrier described above first though. I look forward to your response. |
Regarding the quality of documentation and the lack of volunteer time: When one registers a package -- unleashes it to the community for broader use -- the community has a right to expect that the package will have a stated purpose which it meets, and is adequately documented and tested. If the developer doesn't have time to do this, they shouldn't register the package. That is at least my expectation. Given what I've seen on the Julia Slack #new-packages-feed, these expectationas are rately met. Before I submitted NahaGraphs for registration, I improved the documentation and made sure it would build and deploy properly on GitHub. "contributing to a flawed, but widely used, package, is often more impactful than rolling out your own" and yet, there are My first impression from the Graphs documentation was "these people are interested in exploring graph algorithms on graphs that are totally abstract and have no grounding in real data or applications. I don't recall if I looked at Graphs.jl before doing my own implementation. Haviing an application in mind, this was off-putting. I expect I searched for graph packages in julia and either only found plotting packages, or found Graphs.jl and decided it would be easier to write my own than to figure out how to use it. The very nature of my application imposed a small node and edge count, so efficiency was not a concern. |
Who decides that? IMO [noblock] |
About the example
Yes because of the way undirected graphs are stored by MetaGraphsNext.jl. You're right, it's not a fundamental requirement in theory, but for our current implementation it seems necessary.
It depends whether your "objects" are the vertex labels or the vertex data. If they are the labels, you can either use
Integers may be an implementation detail in theory, but in practice they are pretty central to the way Graphs.jl and its ecosystem work (for performance reasons). That means all packages for graphs with metadata had to find a way around them somehow. |
About the documentation
In principle I agree. In practice, many of the packages we're talking about have been around for years, since before current standards were widely applied. Besides, their history is rather bumpy. I joined the JuliaGraphs crew later on, so me and others are trying to do our best with what we inherited, even though it's sometimes not ideal.
Again a product of the incremental development of graph formats and ideas. It's easier to criticize with hindsight, and that's also why we're currently reflecting on other ways to do things.
If you take a look at the graphs ecosystem, you will find that Graphs.jl actually has a lot of applications. By nature it is indeed an abstract, foundational package, but many people have used it in many different ways.
That is your choice, and I won't prevent you from registering this package. I have also registered my own package for metagraphs in the past, but I regret it now. Because as I underlined on Discourse recently, there are literally tons of similar libraries with slightly different takes on what an ideal graph should be. My goal is to reduce duplication of efforts and enhance collaboration, which is why I'm still here trying to convince you. |
As a side note, I kindly advise you to try a softer approach when talking to open source contributors. We're all volunteers here, doing the best we can because we believe it's useful to the community.
I must say it is slightly disheartening, and does not put people in the right mood to help you. |
I'm sorry my remarks were offensive. It was not my intent to offend. I did intend to communicate my furstrations though. Rather than making sweeping generalizations, I will point out specific cases as I experience them. For example:
Fortunately MetaGraphs provides a way around this if one provides "labels". |
it seems I'm beiing encouraged to write documentation for a package I know very little about :-). Ok, with your help I'll bite. I'm working on a simple example that is in line with my envisioned use cases for a graph package. I'm having a bit of difficulty with The error is
I believe the problem is that Apparently I need to use all three of Graphs, MetaGraphs, and MetaGraphsNext because some functions are not exported from MetaGraphsNext. I could post the code in this thread or open a PR to add it as an example in the docs directory. |
It is definitely not clear enough in the docs, but most functions in Graphs.jl assume that the vertices are numbered from If you're interested, I have started a project GraphsInterfaceChecker.jl to formalize these implicit assumptions as proper Julia code that can be used to test new graph formats. |
I agree it does look like a trap, but it turns out new users are often the best people to spot holes in the documentation, precisely because they're not accustomed to the code yet.
That's the spirit, thank you! :)
Actually the issue is that MetaGraphsNext is not a complement to MetaGraphs but a full replacement. That explains why In all likelihood, you should only use one of the two packages. If you don't care about performance, MetaGraphs.jl might be easier, but since it's the older and less efficient one, the documentation has received less love. |
When a node is removed then other nodes are renumbered? This would mean that the approach I was taking before you introduced me to MetaGraphs was doomed to failure. I can't imagine how I would function as a programmer in an environment where data objects don't have identity. How does MetaGraphsNext cope with that? Probably takes too long to explain .
On Dec 15, 2023 6:02 AM, Guillaume Dalle ***@***.***> wrote:
add_vertex! adds a vertex to a graph. It does not return that vertex. How does the caller know what that vertex is so that it could add an edge or set a property?
It is definitely not clear enough in the docs, but most functions in Graphs.jl assume that the vertices are numbered from $1$ to $n$. That is why the default add_vertex!(g) takes no argument, because the added vertex is always $n+1$. Note that this gets trickier with rem_vertex!(g, v) because maintaining the invariant requires implicit numbering changes.
—
Reply to this email directly, view it on GitHub<#96626 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIBY3EYXUHFSINV436LFH6LYJQU3NAVCNFSM6AAAAABAJUEOIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJXGY4TAOBQGU>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
I forked MetaGraphsNext to add documentation: https://github.com/MarkNahabedian/MetaGraphsNext.jl. This test was failing on my fresh clone
so I commented it out for now. I added a first draft of a new tutorial (Family Tree) that addresses the kinds of use cases I envision. I wonder if there's a way to fix the URI in the README file to refer to the fork's github pages instead of the root's. |
Indeed, in a
It sure is a strong argument for MetaGraphsNext, or for constructing a graph once and for all before analysis (which in some situations may not be feasible) |
Cool, thanks! |
JuliaGraphs/MetaGraphsNext.jl#75 I look forward to your comments there. |
This pull request has been inactive for 30 days and will be automatically closed 7 days from now. If this pull request should not be closed, please either (1) fix the AutoMerge issues and re-trigger Registrator, which will automatically update the pull request, or (2) post a comment explaining why you would like this pull request to be manually merged. [noblock] |
With much help I was able to get MetaGraphsNext to work in my applications. I'd like to withdraw this pull request, but I don't see a UI component for that. |
You can just leave it there, it will close automatically. |