Skip to content
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

Fix directed gnp_random_graph #954

Merged
merged 21 commits into from
Nov 25, 2023
Merged

Conversation

enavarro51
Copy link
Contributor

@enavarro51 enavarro51 commented Jul 31, 2023

This PR fixes #950. Previously the directed_gnp_random_graph did not properly produce in and out edges and also contained a bug that caused the process to terminate too quickly, resulting in some nodes having a very small number of edges.

  • Add additional tests
  • Release note

@coveralls
Copy link

coveralls commented Aug 1, 2023

Pull Request Test Coverage Report for Build 6989824759

  • 28 of 31 (90.32%) changed or added relevant lines in 1 file are covered.
  • 6 unchanged lines in 1 file lost coverage.
  • Overall coverage decreased (-0.05%) to 95.867%

Changes Missing Coverage Covered Lines Changed/Added Lines %
rustworkx-core/src/generators/random_graph.rs 28 31 90.32%
Files with Coverage Reduction New Missed Lines %
src/shortest_path/all_pairs_bellman_ford.rs 6 95.53%
Totals Coverage Status
Change from base Build 6962831668: -0.05%
Covered Lines: 15588
Relevant Lines: 16260

💛 - Coveralls

@IvanIsCoding IvanIsCoding added this to the 0.14.0 milestone Oct 18, 2023
Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

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

This change LGTM, just a couple of inline questions. Sorry it took so long to review this.

Fixed an issue where the :func:`~rustworkx.generators.directed_gnp_random_graph`
and the :func:`~rustworkx-core.generators.gnp_random_graph` for directed graphs
produced a graph where lower node numbers had only a small number of edges
compared to what was expected and the output was therefore not random.
Copy link
Member

Choose a reason for hiding this comment

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

Wasn't it still technically random output, just with a much lower occurrence of an edge than specified.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's fine. I'll remove the last clause.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done in fd7544a.

let mut v: isize = if directed { 0 } else { 1 };
let mut w: isize = -1;
let num_nodes: isize = num_nodes as isize;
let num_nodes = num_nodes as isize;
Copy link
Member

Choose a reason for hiding this comment

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

I know this is pre-existing code but couldn't this potentially overflow since the num_nodes input is of type usize? Should we have a guard against num_nodes > isize::MAX or use try_into() here?

Copy link
Contributor Author

@enavarro51 enavarro51 Nov 24, 2023

Choose a reason for hiding this comment

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

Yeah, try_into is a good idea. If it overflows, should we set it to isize::MAX or should we error or both?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, should we say something in the docs about num_nodes not exceeding some value?

Copy link
Member

Choose a reason for hiding this comment

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

I think we should probably just error in the case we've exceeded.

We can document it but isize::MAX is 9,223,372,036,854,775,807 on 64 bit platforms and ~2 billion on 32 bit platforms, maybe just say it will return an error if the num of nodes exceeds the isize::MAX directly (for rustworkx-core). But I think the InvalidInputError error struct is probably sufficient to cover this case too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done in fd7544a. I believe this does what you're saying. I wasn't sure how to test this, since anything I tried with very large numbers gave either a capacity overflow or memory allocation error.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually I redid this in b41cf8a using match. I was able to successfully test locally if I changed all the isize to i8, but if I test at isize levels, I still get capacity or memory errors. So I did not add any new tests for this.

Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for the quick updates

@mtreinish mtreinish added the automerge Queue a approved PR for merging label Nov 25, 2023
@mergify mergify bot merged commit a44239c into Qiskit:main Nov 25, 2023
27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge Queue a approved PR for merging
Projects
None yet
Development

Successfully merging this pull request may close these issues.

rustworkx.directed_gnp_random_graph doesn't produce random graphs
4 participants