Comments (2)
Let me check if I understand what you are requesting:
- This function will lay out subgraphs corresponding to each specified community individually
- It will then merge these layout without taking into account the connections between the communities
I am not in favour of including such a feature in igraph because:
- Since connections between communities are not taken into account, the layout will typically be quite poor.
- The layout obtained this way does not actually reveal information about any community structure.
- For those who really want this anyway, it can already be accomplished with
merge_coords()
There are more advanced layout methods that can take communities into account, and it would make sense to implement those. One example is hierarchical edge bundling. But this naive approach doesn't really produce good results.
The reason for the existence of layout_components()
is that most layout algorithms were not designed to be able to handle disconnected graphs. The proper approach is to lay out each weakly connected component separately, then merge the layouts by some method. Currently igraph only has a rudimentary support for this, but we hope to be able to do more in the future.
To be clear, the ultimate decision about this it with @krlmlr, not me.
from rigraph.
Thank you very much for your detailed answer.
Let me check if I understand what you are requesting:
- This function will lay out subgraphs corresponding to each specified community individually
- It will then merge these layout without taking into account the connections between the communities
Yes, that is what I was considering. The initial reason was I thought it would be useful to visually examine how nodes with already established labels (cluster information) relate to other nodes on the network with the known relationship by explicitly disjointing them (like in the visualization of the gene regulatory network with information on the genes).
![](https://private-user-images.githubusercontent.com/31095487/292368437-5ad7b619-7324-4d43-9177-e6f164ea4381.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQzOTU0NDMsIm5iZiI6MTcyNDM5NTE0MywicGF0aCI6Ii8zMTA5NTQ4Ny8yOTIzNjg0MzctNWFkN2I2MTktNzMyNC00ZDQzLTkxNzctZTZmMTY0ZWE0MzgxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MjMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODIzVDA2MzkwM1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTUzMDg3YmI1NGFhZTI1NWZiMGM2Zjg0OGNkNzg3NDNiM2EyMGE4YjkxYzg4NmMxZWMyOGEwMGVlZDU5MzVlOWUmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.HfBPab32LmSRHVl8Z-5WjpxIe49HML96nvkTBt7jF0U)
However, as you stated, this indeed performs poorly and can be already accomplished with merge_coords()
.
I am not in favour of including such a feature in igraph because:
- Since connections between communities are not taken into account, the layout will typically be quite poor.
- The layout obtained this way does not actually reveal information about any community structure.
- For those who really want this anyway, it can already be accomplished with merge_coords()
Thank you for your clarification on the points that this is not an expected feature in igraph
, and I completely agree with these. In particular, I am very convinced by the reason for the existence of layout_components()
.
Again, thank you for taking the time to consider this issue and for maintaining this important project.
from rigraph.
Related Issues (20)
- revdeps HOT 13
- V(g) not the same as 1:vcount HOT 5
- `cluster_label_prop()` crashes R when using fixed labels HOT 6
- Export `.from` etc. with behavior similar to `dplyr::across()` HOT 1
- use lifecyle for layout.fruchterman.reingold()
- Remove/deprecate the functions using constructor_spec()? HOT 1
- deprecate neimode argument in bfs() for good
- `feedback_arc_set()` needs tests
- Add `igraph_feedback_vertex_set()`
- A weights vector in `local_scan`
- TODOs in `rinterface_extra.c`
- TODOs in tests HOT 17
- TODO in `src/igraph_vector.hpp` HOT 2
- TODOs in `socnet.R` HOT 7
- TODO in tkplot
- ensure max.print is used consistently in all of print.R
- Update `is_separator()` docs
- can indexing be made faster HOT 1
- can we remove the "## TODO: speed this up" in make.R?
- Add `igraph_find_cycle()`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rigraph.