DAGitty – draw and analyze causal diagrams
dagitty.net
dagitty.net
I did my PhD in algorithms at the time and was intrigued when I started reading Greenland, Pearl, and Robins (https://pubmed.ncbi.nlm.nih.gov/9888278/) and then Pearl's "Causality". I soon found that it was not obvious at all how you could speed up that MS-DOS program, and it led to a paper at UAI in 2011 (https://arxiv.org/abs/1202.3764). I made dagitty as a demonstration that you could actually use the algorithms we developed in that paper, and it took off from there -- started with 10 users per day, growing to the hundreds and thousands as causal inference became more popular.
It's now a bit dated, and I don't have as much time anymore to keep it "fresh" as I would like. But I am still grateful and amazed at about how many people I got to know due to this. Highlights included collaborating with Pearl himself on a solution manual for his book "Causal Inference: A Primer" when it first came out, and so many e-mails I got out of the blue from users all over the world. Just last summer I stayed at the house of the author of one of the builtin examples in dagitty.
As these 14 years flew by, I now am happy to do play a small part in supporting the next generation of causal inference software -- if you're interested in causal inference, be sure to check out pgmpy.org, a Python library for Bayesian networks that includes several causal inference functions (https://arxiv.org/abs/2304.08639). Ankur, the author, did his PhD with me and will soon defend his thesis!
Also, R users, be sure to check out ggdag, a great package by Malcolm Barrett that wraps dagitty functionality in a much nicer and tidyverse-compatible way.
[0] Pearl 2021: https://ftp.cs.ucla.edu/pub/stat_ser/r370.pdf
Tails: Nodes with no dependents.
Someone could implement this as a feature in graphviz. It might take a day to implement.
There are probably other "solutions" that already handle this more gracefully, but otherwise don't have a very complete set of features relative to graphviz.
It's reasonable (and constructive) for you to complain, but your "issue" is representative of a wide set of "issues" we've seen, and the real problem is we're just a little unimportant niche service and all this work is being done by volunteers and they mainly work on the things they know how to do.
So far it has automatic layout that will position (and create a rendering) for hierarchical graphs - even if your data isn't hierarchical in nature. This is how the algorithm works internally as it is a reflection of Dagrejs.
I plan to support more layout types in the future.
As for placement of 'root' nodes (aka source and sink nodes) - in reference to the parent comment - my hope is to expose graph theory methods that you can run before layout/render which would help facilitate this automatically, but it's non-trivial to codify as it requires a substantial refactor to the layout algorithm(s).
I still miss R and tidy quite a bit, but polars at least gets closer.
Networkx visualizations are ugly out of the box but you can make the network look however you want. The best out of the box visualizations I think are a matter of taste and use case. Same with the layouts.
In a more abstract sense, I think it is hard to not have a 1000 node network visualization not be a useless hairball unless the network is quite sparse.
If you mean with do-calculus though I really have no idea.
I would find a python port useful, as R is more of a special use case in my own workflows, but my use case shouldn't deter the authors.
I will use it when I have a chance.
I really like the "How to menu", I may recommend to do it a little more prominent on first usages or show me once that it's there.
Congrats!