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

.loc to avoid warnings #255

Merged
merged 4 commits into from
Feb 7, 2023
Merged

Conversation

AdamOrmondroyd
Copy link
Collaborator

Use to_numpy() on boolean mask in Gaussian example to prevent UserWarnings

I seriously think we need to have something which resists PRs introducing new warnings...

@codecov
Copy link

codecov bot commented Jan 29, 2023

Codecov Report

Merging #255 (fbd71c0) into master (0618a8f) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #255   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           29        29           
  Lines         2422      2422           
=========================================
  Hits          2422      2422           
Impacted Files Coverage Δ
anesthetic/examples/perfect_ns.py 100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@lukashergt
Copy link
Collaborator

I seriously think we need to have something which resists PRs introducing new warnings...

There is the option of the pytest -W error flag, which will turn warnings into errors... However, I think this will get in the way, e.g. this could prevent quickly fixing a bug because of completely unrelated deprecation warnings.

We could think about having a single test run with the pytest -W error flag switched on, which we then set as "allowed to fail". This can prompt both PR author and reviewer to check more closely for warnings and to try to prevent introducing new ones.

Thoughts? @Ormorod @williamjameshandley

@williamjameshandley williamjameshandley changed the title .to_numpy() .loc to avoid warnings Feb 7, 2023
@williamjameshandley
Copy link
Collaborator

I think that a .loc is better from a pandas perspective than a .to_numpy(), and I think that this removes the warnings as well. I've pushed this change, but feel free to revert.

I agree with @lukashergt that a requirement will introduce too much friction, but a check is entirely reasonable. Just add it as an extra block in the CI.yaml file, and I won't flag it as required. I'll approve this, and give you the option to implement the test to encourage users to fix warnings, or just to merge as-is.

@AdamOrmondroyd
Copy link
Collaborator Author

I thought Lukas didn't like .loc, which is why I used .to_numpy()

@AdamOrmondroyd AdamOrmondroyd merged commit 67b9a96 into handley-lab:master Feb 7, 2023
@AdamOrmondroyd AdamOrmondroyd deleted the to_numpy branch February 7, 2023 18:32
@lukashergt
Copy link
Collaborator

lukashergt commented Feb 7, 2023

I think that a .loc is better from a pandas perspective than a .to_numpy(), and I think that this removes the warnings as well. I've pushed this change, but feel free to revert.

I thought Lukas didn't like .loc, which is why I used .to_numpy()

Yes, watch out when trying boolean masks on pandas dataframes. When we think of boolean masks, we tend to have a picture in mind like what you get when applying .to_numpy(), so that would be the safer route than the current WeightedDataFrame that we get from samples.logL_birth < logLend.

All that said, if we want a more pandas way of doing things, then the .query() method is the correct approach, e.g. instead of

samples.loc[(samples.nlive >= nlive)].logL.max()

do

samples.query("nlive >= @nlive").logL.max()

@AdamOrmondroyd AdamOrmondroyd restored the to_numpy branch February 8, 2023 12:04
@AdamOrmondroyd
Copy link
Collaborator Author

AdamOrmondroyd commented Feb 8, 2023

Problem with queries is flake8 thinks logLend is never used 🫥🫥🫥🫥

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants