-
Notifications
You must be signed in to change notification settings - Fork 4
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
Address FutureWarning
From pandas.concat
In gempyor
#245
Address FutureWarning
From pandas.concat
In gempyor
#245
Conversation
Consolidated multiple pd.concat calls into one in compute_all_multioutcomes building hpar df. Addresses pandas FutureWarning in concating an empty df and slightly more performant.
…precation-warnings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is all good to me, thanks @TimothyWillard . You are correct that the index is not used so you can remove the call to add this index and it is good to merge. After that, you might want to request review from @emprzy or @saraloo as well so you are sure to have two reviews fast :)
…precation-warnings
`set_index` call maintained prior behavior of creating an index like 0,1,...,N,0,1,...,N. Now the index goes 0,1,...,2N. This index does not get used so it is a harmless breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TimothyWillard sorry to be delayed, but thanks!
Thanks y'all! |
…e-future-weprecation-warnings Address `FutureWarning` From `pandas.concat` In `gempyor`
Small change to the
compute_all_multioutcomes
function to build thehpar
data frame from a list in one call topandas.concat
rather than multiple sequential calls. The benefits are:FutureWarning
in Address Warnings Produced Bygempyor
Test Suite #244 by avoiding concatenation of an empty data frame.pandas.concat
can be expensive. Although since the outputs are relatively small this is a just a nice plus rather than a major benefit.The explicit call to
set_index
is to replicate the old behavior, which is an index of something like 0, 1, ..., N, 0, 1, ..., N which came from concatenating 2 explicit data frames. I can remove that if we don't use this index anywhere, I'm just not familiar enough with the code OTOH to know right now. My guess would be we don't though.Also, not 100% sure I requested the appropriate reviewers, if not please let me know.