You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+12-8
Original file line number
Diff line number
Diff line change
@@ -62,19 +62,23 @@ nxp.betweenness_centrality(H)
62
62
63
63
### Notes
64
64
65
-
1. Some functions in networkx have the same name but different implementations, so to avoid these name conflicts we differentiate them by the `name` parameter in `_dispatchable` at the time of dispatching (ref. [docs](https://networkx.org/documentation/latest/reference/generated/networkx.utils.backends._dispatchable.html#dispatchable)). So, `method 4`is not recommended. Instead, mentioning either the full path of the algorithm or the `name` parameter is recommended. For example:
65
+
1. Some functions in networkx have the same name but different implementations, so to avoid these name conflicts at the time of dispatching networkx differentiates them by specifying the `name` parameter in the [`_dispatchable`](https://networkx.org/documentation/latest/reference/generated/networkx.utils.backends._dispatchable.html#dispatchable) decorator of such algorithms. So, `method 3` and `method 4`are not recommended. But, you can use them if you know the correct `name`. For example:
# using `name` parameter - nx-parallel as an independent package
69
+
nxp.all_pairs_node_connectivity(H) # runs the parallel implementation in `connectivity/connectivity`
70
+
nxp.approximate_all_pairs_node_connectivity(H) # runs the parallel implementation in `approximation/connectivity`
71
+
```
72
+
73
+
Also, if you are using nx-parallel as a backend then mentioning the subpackage to which the algorithm belongs is recommended to ensure that networkx dispatches to the correct implementation. For example:
71
74
72
-
# using `name` parameter
73
-
nx.all_pairs_node_connectivity(H) # runs the parallel implementation in `connectivity/connectivity`
74
-
nx.approximate_all_pairs_node_connectivity(H) # runs the parallel implementation in `approximation/connectivity`
75
+
```.py
76
+
# with subpackage - nx-parallel as a backend
77
+
nx.all_pairs_node_connectivity(H)
78
+
nx.approximation.all_pairs_node_connectivity(H)
75
79
```
76
80
77
-
2. Right now there isn't much difference between `nx.Graph` and `nxp.ParallelGraph` so `method 3` would work fine but it is not recommended because in future that might not be the case.
81
+
2. Right now there isn't much difference between `nx.Graph` and `nxp.ParallelGraph` so `method 3` would work fine but it is not recommended because in the future that might not be the case.
78
82
79
83
Feel free to contribute to nx-parallel. You can find the contributing guidelines [here](https://github.com/networkx/nx-parallel/blob/main/CONTRIBUTING.md). If you'd like to implement a feature or fix a bug, we'd be happy to review a pull request. Please make sure to explain the changes you made in the pull request description. And feel free to open issues for any problems you face, or for new features you'd like to see implemented.
Copy file name to clipboardExpand all lines: _nx_parallel/__init__.py
+11-2
Original file line number
Diff line number
Diff line change
@@ -37,12 +37,19 @@ def get_info():
37
37
"additional_docs": "The function parallelizes the calculation of two neighborhoods of vertices in `G` and checks closure conditions for each neighborhood subset in parallel.",
"additional_docs": "The parallel computation is implemented by dividing the nodes into chunks and then checking whether each node is reachable from each other node in parallel.",
"additional_docs": "The parallel implementation first divides a list of all permutation (in case of directed graphs) and combinations (in case of undirected graphs) of `nbunch` into chunks and then creates a generator to lazily compute the local node connectivities for each chunk, and then employs joblib's `Parallel` function to execute these computations in parallel across all available CPU cores. At the end, the results are aggregated into a single dictionary and returned.",
48
+
"additional_parameters": {
49
+
'get_chunks : str, function (default = "chunks")': "A function that takes in `list(iter_func(nbunch, 2))` as input and returns an iterable `pairs_chunks`, here `iter_func` is `permutations` in case of directed graphs and `combinations` in case of undirected graphs. The default is to create chunks by slicing the list into `n` chunks, where `n` is the number of CPU cores, such that size of each chunk is atmost 10, and at least 1."
"additional_docs": "The parallel implementation first divides the a list of all permutation (in case of directed graphs) and combinations (in case of undirected graphs) of `nbunch` into chunks and then creates a generator to lazily compute the local node connectivities for each chunk, and then employs joblib's `Parallel` function to execute these computations in parallel across all available CPU cores. At the end, the results are aggregated into a single dictionary and returned.",
"additional_docs": "The parallel computation is implemented by dividing the nodes into chunks and computing betweenness centrality for each chunk concurrently.",
55
-
"additional_parameters": None,
62
+
"additional_parameters": {
63
+
'get_chunks : str, function (default = "chunks")': "A function that takes in a list of all the nodes as input and returns an iterable `node_chunks`. The default chunking is done by slicing the `nodes` into `n` chunks, where `n` is the number of CPU cores."
0 commit comments