Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upTake a better approach to scaling using normalized (log(x)) formula. #46
Conversation
@@ -155,16 +155,18 @@ extern int layout_graph(igraph_t *graph, char layout) { | ||
extern int set_size(igraph_t *graph, igraph_vector_t *v, int max) { | ||
long int gsize = (long int)igraph_vcount(graph); |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ruebot
Aug 28, 2018
Member
The error amounts to a typo in fact (I used
vcount(graph)
instead ofecount(graph)
Is this comment still relevant?
ruebot
Aug 28, 2018
Member
The error amounts to a typo in fact (I used
vcount(graph)
instead ofecount(graph)
Is this comment still relevant?
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
greebie
Aug 28, 2018
Collaborator
The ecount(graph) would have prevented the issue of negative values, but when I looked into it further the approach proposed here solves both the negative issue and creates a better output for Gephi.
(tl;dr no).
greebie
Aug 28, 2018
•
Collaborator
The ecount(graph) would have prevented the issue of negative values, but when I looked into it further the approach proposed here solves both the negative issue and creates a better output for Gephi.
(tl;dr no).
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
greebie
added some commits
Aug 28, 2018
ianmilligan1
reviewed
Aug 30, 2018
I'm still testing out GraphPass, but after looking at over 30 sigma.js diagrams in AUK, a few quick thoughts.
Most of the diagrams - 26 of the 30 - were perfect. It seems similar to before: nice layouts, legible, etc. I think if possible we'd like to:
- perhaps shrink minimum node sizes for legibility.
Example of a Great Diagram
Some Nodes Are too Big
In 2 or 3 of the 30 (one would be a judgement call), the node size seemed bigger than we had in the past version. Is there a way to maybe allow smaller nodes (set the min node size down a bit?). See the examples below:
Some Files are too Big
This is perhaps out of scope, but some of the GraphPass files are potatoing the browser. They're simply too big, usually due to the sheer number of edges (i.e. a 37k node diagram with 61k edges and we have a 670MB GEXF file (!)). Any thoughts on what to do in these cases? The Gephi files are usable but Sigma borks.
ianmilligan1
referenced this pull request
Aug 30, 2018
Closed
Reduce Sigma.js Minimum Node Size #190
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ianmilligan1
Aug 30, 2018
Member
OK chatted with @greebie and sounds like:
- node sizes would be better handled in sigma rather than GraphPass (and testing in this issue bears that out);
- file sizes better handled in AUK perhaps?
Will continue testing. I'd like to eye ball another 30-40 graphs.
OK chatted with @greebie and sounds like:
Will continue testing. I'd like to eye ball another 30-40 graphs. |
ianmilligan1
dismissed
their
stale review
Aug 31, 2018
Node sizes will be handled in Sigma (opened up issue there); File sizes might be better handled in AUK.
ianmilligan1
approved these changes
Aug 31, 2018
OK. I've now tested this version of GraphPass on 117 GEXF files and it works very nicely (loading up all the files into the sigma browser was a lot of repetitive strain).
Some of the files were still too large to visualize in sigma but they worked nicely in Gephi so it would be nice to keep them going through GraphPass.
Two of the files rendered in Gephi but not in Sigma due to Sigma parsing issues but they still worked in Gephi.
I think this is ready to merge and put into production.
ruebot
merged commit ceda07c
into
master
Sep 2, 2018
ruebot
deleted the
issue-45
branch
Sep 2, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This has been put into production. |
greebie commentedAug 28, 2018
GitHub issue(s):
If you are responding to an issue, please mention their numbers below.
#45 & #25
What does this Pull Request do?
Taking the approach described in detail in #25, creates a more attractive output for gexf graphs out of the box (more closely connected to the promise outlined in the README.md).
How should this be tested?
make clean all
should pass all tests../graphpass --dir {enter filepath if file is not in /assets} --file {enter test graphml filename} -qg
should put a gexf copy of the graphml in /OUT
Test file in Gephi.
Test file in SigmaJS / auk.
Additional Notes:
This approach may change the default output in SigmaJS, having impacts in auk. While the changes should be minor, we will need to look out for:
1 - wonky node sizing issues (similar to #25)
2 - the graph being overrun with text due to more equitable approach to nodesizes.
3 - that the aesthetics generally work for an auk output.
4 - that the scaling up/down feature in auk is a) still working okay and b) still useful.
Interested parties
@ianmilligan1 @ruebot
Thanks in advance for your help with the Archives Unleashed Project!