Estimator return types #264
Conversation
🦙 MegaLinter status:
|
| Descriptor | Linter | Files | Fixed | Errors | Elapsed time |
|---|---|---|---|---|---|
| black | 29 | 1 | 1.32s | ||
| ✅ PYTHON | pylint | 29 | 0 | 4.71s |
See detailed report in MegaLinter reports
MegaLinter is graciously provided by
|
Added logic to handle both |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #264 +/- ##
==========================================
- Coverage 95.72% 95.59% -0.13%
==========================================
Files 22 22
Lines 1566 1567 +1
==========================================
- Hits 1499 1498 -1
- Misses 67 69 +2
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
|
Different estimators and estimate methods ( |
|
I've renamed this PR to be about estimator return types. I think the issue these commits solve is sufficiently different from the interaction terms to be 2 separate PRs at this point. |
…/CausalTestingFramework into interaction-terms
| @@ -46,7 +46,7 @@ def fitness_function(ga, solution, idx): # pylint: disable=unused-argument | |||
|
|
|||
| ate = surrogate.estimate_ate_calculated(adjustment_dict) | |||
|
|
|||
| return contradiction_function(ate) | |||
| return contradiction_function(ate[0]) | |||
There was a problem hiding this comment.
I'm a little worried about the scalability of this as it will only work for float values. If you have categorical data types, this will reduce to a binary treatment between the first and second values in alphabetical order. If you really want to only support float values for this, it would be good to have an explicit check for this to make sure that the user is getting what they expect to get.
…hing to single values
Fetch factors from interaction terms using Patsy ModelDesc class