Skip to content

added parallel implementations for number_ algorithms #117

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

akshitasure12
Copy link
Contributor

@akshitasure12 akshitasure12 commented Jun 7, 2025

added parallel implementations for

These algorithms involve lightweight computations (e.g., simple summations), limiting their performance. Their behaviour should be analysed in context of PR #79.

[edit]: added the should_run parameter discussed in issue #77.

@dschult dschult added the type: Enhancement New feature or request label Jun 7, 2025
@akshitasure12 akshitasure12 marked this pull request as ready for review June 17, 2025 17:39
@akshitasure12
Copy link
Contributor Author

akshitasure12 commented Jun 25, 2025

A few observations:

I ran the following with NETWORKX_BACKEND_PRIORITY_ALGOS=parallel NETWORKX_FALLBACK_TO_NX=False:

python3 test_should_run.py

Contents of test_should_run.py :

import networkx as nx
import logging

nxl = logging.getLogger("networkx")
nxl.addHandler(logging.StreamHandler())
nxl.setLevel(logging.DEBUG)

G = nx.empty_graph(5)
print(nx.number_of_isolates(G))

Output:

Call to 'number_of_isolates' has inputs from {'networkx'} backends, and will try to use backends in the following order: ['parallel', 'networkx']
Backend 'parallel' shouldn't run `number_of_isolates` with arguments: (G=<networkx.classes.graph.Graph object at 0x1055fb6e0>), because: Fast algorithm; not worth converting
Trying next backend: 'networkx'
Call to 'isolates' has inputs from {'networkx'} backends, and will try to use backends in the following order: ['parallel', 'networkx']
Backend 'parallel' does not implement 'isolates'
Trying next backend: 'networkx'
5

Note: Despite setting NETWORKX_FALLBACK_TO_NX=False, the call still proceeds to use the networkx backend.

Copy link
Member

@dschult dschult left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pretty sure the fallback_to_networkx flag applies to the case when you call the function with a graph input that is the backend graph type. That is, "fallback" means we have to convert the backend graph to a NetworkX graph and then call networkx. Perhaps there is a better name for this option. But I think that is why you are still getting the number of isolates. Your input is a NetworkX graph. So it will use the networkx version of the function whatever the value of "fallback_to_networkx" is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: Enhancement New feature or request
Development

Successfully merging this pull request may close these issues.

2 participants