5 ms·
Very pretty! Out of interest, I'm thinking how this sort of method works if you ignore the semi-arbitrary distinction between your own code and other libraries
by sideshowb 3y ago
Very pretty!
Out of interest, I'm thinking how this sort of method works if you ignore the semi-arbitrary distinction between your own code and other libraries. If, say, an array class is used everywhere, wouldn't that look like a bad pattern on the dependency graph? Or is there a way to read the graph that tells you that your pervasive use of np.array is still appropriately decoupled?
- gabimtme 3y agoThat's taken into account while rendering the graph. The attraction force between two nodes is inversely proportional to the number of edges a node has. If a node is depended upon a lot, all the resulting edges induce weaker forces to adjacent nodes, so this accounts for the fact that some files will be depended upon a lot, and that's fine. There's also the option to just exclude that kind of files from the analysis with the --exclude flag. I've found that to be useful for massive auto-generated files.
- olejorgenb 3y agoWhile excluding nodes which a huge portion of the code depends on is one solution to make the graph less messy, I think an interesting alternative would be to allow certain nodes to be duplicated. If the "energy" of the system could be reduced above some threshold by duplicating a node, duplicate it and connect the edges to minimize the "energy". Alternative let me configure that these nodes can be copied N times.