Hi! You seem to have the most recent/active fork of mpl_chord_diagram.
It worked out of the box for my problem in 2 min, thanks!
Since you don't have "issues", I'm communicating through a PR, I hope that's okay.
So, while I decide whether to make another project of mine (gph82/mdciao) depend on mpl_chord_diagram (your fork or mine, also undecided), I noticed there's no option to turn off zero-width nodes, so I included one.
If you don't like cluttering the signature, I was thinking perhaps to make it depend on whether the matrix is given as sparse or dense. Sparse triggers the "don't show zeros" option internally automatically.
What do you think?
Hi! You seem to have the most recent/active fork of mpl_chord_diagram.
It worked out of the box for my problem in 2 min, thanks!
Since you don't have "issues", I'm communicating through a PR, I hope that's okay.
So, while I decide whether to make another project of mine (gph82/mdciao) depend on mpl_chord_diagram (your fork or mine, also undecided), I noticed there's no option to turn off zero-width nodes, so I included one.
If you don't like cluttering the signature, I was thinking perhaps to make it depend on whether the matrix is given as sparse or dense. Sparse triggers the "don't show zeros" option internally automatically.
What do you think?

Hi there!
Sorry, I did not see your PR for some reason...
Thanks for contributing, I will try to look at it today!
Hi there!
Sorry, I did not see your PR for some reason...
Thanks for contributing, I will try to look at it today!
Silmathoron
(Migrated from github.com)
requested changes 2 years ago
Silmathoron
(Migrated from github.com)
left a comment
Owner
Ok, actually decided I should do that right away before I forget ^^
I think this definitely very relevant, thank you (should even become the default behavior).
If you can address the minor points that I raised, I'll merge it.
If you can, it would be nice if you could combine everything into one commit afterwards so I can rebase the PR (if I'm not mistaken, I think that should enable to avoid cluttering the log with useless merge commits while still preserving you authorship on the commit).
As for which fork to point to... I guess that's up to you... I can already say that my library (NNGT already points to this one so I'll try to maintain it actively.
PS : activated issues and (hopefully) turned on notifications to avoid having you wait 7 days next time again.
Ok, actually decided I should do that right away before I forget ^^
I think this definitely very relevant, thank you (should even become the default behavior).
If you can address the minor points that I raised, I'll merge it.
If you can, it would be nice if you could combine everything into one commit afterwards so I can rebase the PR (if I'm not mistaken, I think that should enable to avoid cluttering the log with useless merge commits while still preserving you authorship on the commit).
As for which fork to point to... I guess that's up to you... I can already say that my library ([NNGT](https://nngt.readthedocs.io/) already points to this one so I'll try to maintain it actively.
PS : activated issues and (hopefully) turned on notifications to avoid having you wait 7 days next time again.
Thinking about it, I think it is definitely reasonable to make show_zeros=False the default behavior (I know of no cases were people would expect to see non-existent connections)
Thinking about it, I think it is definitely reasonable to make ``show_zeros=False`` the default behavior (I know of no cases were people would expect to see non-existent connections)
OK, last thing I'm wondering about, since it might be useful to avoid clutter to the API, is whether we move show_zeros to **kwargs... any opinion?
OK, last thing I'm wondering about, since it might be useful to avoid clutter to the API, is whether we move ``show_zeros`` to ``**kwargs``... any opinion?
gph82
(Migrated from github.com)
reviewed 2 years ago
Hi there, sorry just wanted to check whether you were actually planning on doing the full PR workflow so it's included with your authorship in the package or if this was just for discussion and I should open a new PR myself.
Hi there, sorry just wanted to check whether you were actually planning on doing the full PR workflow so it's included with your authorship in the package or if this was just for discussion and I should open a new PR myself.
Hi, thanks, sorry, I forgot about this a bit. So I think show_zeros should be moved to kwargs or even deleted completely...is there any reason it should be kept? I was just being conservative when proposing changes
Hi, thanks, sorry, I forgot about this a bit. So I think show_zeros should be moved to kwargs or even deleted completely...is there any reason it should be kept? I was just being conservative when proposing changes
Hi! You seem to have the most recent/active fork of mpl_chord_diagram.
It worked out of the box for my problem in 2 min, thanks!
Since you don't have "issues", I'm communicating through a PR, I hope that's okay.
So, while I decide whether to make another project of mine (gph82/mdciao) depend on mpl_chord_diagram (your fork or mine, also undecided), I noticed there's no option to turn off zero-width nodes, so I included one.
If you don't like cluttering the signature, I was thinking perhaps to make it depend on whether the matrix is given as sparse or dense. Sparse triggers the "don't show zeros" option internally automatically.
What do you think?
Hi there!
Sorry, I did not see your PR for some reason...
Thanks for contributing, I will try to look at it today!
Ok, actually decided I should do that right away before I forget ^^
I think this definitely very relevant, thank you (should even become the default behavior).
If you can address the minor points that I raised, I'll merge it.
If you can, it would be nice if you could combine everything into one commit afterwards so I can rebase the PR (if I'm not mistaken, I think that should enable to avoid cluttering the log with useless merge commits while still preserving you authorship on the commit).
As for which fork to point to... I guess that's up to you... I can already say that my library (NNGT already points to this one so I'll try to maintain it actively.
PS : activated issues and (hopefully) turned on notifications to avoid having you wait 7 days next time again.
Thinking about it, I think it is definitely reasonable to make
show_zeros=False
the default behavior (I know of no cases were people would expect to see non-existent connections)change default (cf. above)
start, end = pos[(i, i)]
start1, end1 = pos[(i, j)]
OK, last thing I'm wondering about, since it might be useful to avoid clutter to the API, is whether we move
show_zeros
to**kwargs
... any opinion?Yeah, default should be zero. It's just I did not want to change API behavior in the PR.
You have my blessing to do so, I'll also let you decide whether it should go into
kwargs
or not... I have no strong opinion on the matterHi there, sorry just wanted to check whether you were actually planning on doing the full PR workflow so it's included with your authorship in the package or if this was just for discussion and I should open a new PR myself.
Hi, thanks, sorry, I forgot about this a bit. So I think show_zeros should be moved to kwargs or even deleted completely...is there any reason it should be kept? I was just being conservative when proposing changes
Yeah, actually you're right, remove it completely 👍
What do you think?
Alright, just some tiny formatting left and we're good to go!
Actually I can just validate them myself ^^
LGTM, expect a new PR on other stuff in a few mins lol
OK, great ^^
And GitHub apparently fixed their squash mechanism so I'm happy to say your authorship was correctly processed!
wait a sec, some changes of the second PR got into this one while selectively committing, gimme a sec
Reviewers
5b6e627e7f
.