-
Notifications
You must be signed in to change notification settings - Fork 74
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
#514 #519
#514 #519
Conversation
… DatetimeIndex before resampling instead."
…n a future version, please use 'YE-DEC' instead."
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #519 +/- ##
=======================================
Coverage 80.57% 80.58%
=======================================
Files 80 80
Lines 4756 4758 +2
Branches 810 810
=======================================
+ Hits 3832 3834 +2
Misses 648 648
Partials 276 276
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
If this PR is approved, I think I will need to go back and remove all the dependent sub functions to not pass in that argument. We will need to modify the tests too. I'm sure Henry has a reason for this, but it's also been a while. I wonder if it was a way to get around some upstream bug. |
someone had an issue where drop_hilo behaved unpredictably. on a column like this 1.2 if you do ex hilo and volume weighted, it wasn't obvious which 1 would be dropped. secondary rank would allow you to specify if you want to drop maybe the oldest 1 or the 1 with the smallest underlying loss. I'm surprise that removing secondary_rank would do anything. it looked to be an optional argument that defaults to blank. |
I see, that makes a lot of sense now after reading the comments again. But this is not currently captured in any of the tests right? That's why this PR is still passing all tests. Removing the argument does fix #514 because these lines are causing problems. The primary is I propose that we accept this PR first, we need to write new tests and maybe start a discussion on how to handle all the conflict collision, especially when dealing with very special cases. |
i don't think secondary_rank is causing the problem. it's optional. you can simply delete obj.iloc[...,:-1,:-1] from the failing line. |
@jbogaardt do you recall what obj.iloc[...,:-1,:-1] was changed to elsewhere in the package to deal with scalene triangles? |
I'm not sure, but my instinct is to rely on the logic that produces the valid entries for a scalene triangle's link_ratios: cl.load_sample('quarterly').link_ratio.nan_triangle |
Thanks @jbogaardt. Found it in the link_ratio code. @kennethshsu can you simply delete obj.iloc... from here? That should fix the issue, as secondary_rank is optional. I'll find time this week to add back the right secondary rank. |
Yap sounds good, thanks Henry, I think that's a good temporary solution for now. I added a couple more tests to hopefully catch this. Once Do we need another round of code review? I know this request is technically already approved. But @jbogaardt, if it looks good feel free to merge! |
By the way @henrydingliu, if you need a triangle to play with as described in your scenario:
data = {
"valuation": [
1981,
1982,
1983,
1984,
1985,
1982,
1983,
1984,
1985,
],
"origin": [
1981,
1982,
1983,
1984,
1985,
1981,
1982,
1983,
1984,
],
"values": [
100,
200,
300,
400,
500,
200,
200,
300,
800,
],
}
tri = cl.Triangle(
pd.DataFrame(data),
origin="origin",
development="valuation",
columns=["values"],
cumulative=True,
)
tri |
This is done by removing secondary_rank.
@henrydingliu, do you remember why you did this? None of the tests failed, and I couldn't figure out what its supposed to do.