-
Notifications
You must be signed in to change notification settings - Fork 65
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
Increase docstring coverage and add doctests #232
Increase docstring coverage and add doctests #232
Conversation
@@ -70,6 +175,8 @@ def __init__( | |||
self._input_validation(data, treatment_time) | |||
|
|||
self.treatment_time = treatment_time | |||
# set experiment type - usually done in subclasses | |||
self.expt_type = "Pre-Post Fit" |
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 the only code change. The experiment type had to be added here in order for the summary method to be run on an instance of the PrePostFit class (rather than the SyntheticControl or InterruptedTimeSeries classes).
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.
Firstly, thanks so much for this @jpreszler. This is amazing work. Timing wise I wanted to do a relatively quick pass to keep the ball rolling. But I've not done a thorough read of all the parameter explanations in the docstrings for example, so I will almost certainly have a few minor points about that before we merge.
One thought I had about the docstring examples was about the maintainability. I've not used this yet, but my feeling is that we will probably avoid major headaches in the future if we test these docstring examples with doctest
(e.g. https://realpython.com/python-doctest/; https://docs.python.org/3/library/doctest.html). That may also require changes to the GitHub actions so that these tests are run locally and remotely. If we run into trouble there, then @lucianopaz may be able to give you pointers.
There's a comment in there about when/if we include text output in the docstring examples. I've noted down my first thought, but I'd definitely appreciate input from @juanitorduz and @lucianopaz on this. As I say, I've not used doctest
, so it might be that we do need to include (some) text output.
PS: We're likely to merge #213 very soon, so there will be a couple of new classes added there.
I've rendered the docs locally with your changes and they look really great. This is an excellent contribution.
Codecov Report
@@ Coverage Diff @@
## main #232 +/- ##
==========================================
+ Coverage 73.86% 73.89% +0.02%
==========================================
Files 19 19
Lines 1148 1149 +1
==========================================
+ Hits 848 849 +1
Misses 300 300
|
Wow, this is amazing -- much appreciated @jpreszler! |
percentiles = self.causal_impact.quantile([0.03, 1 - 0.03]).values | ||
ci = r"$CI_{94\%}$" + f"[{percentiles[0]:.2f}, {percentiles[1]:.2f}]" | ||
ci = "$CI_{94%}$" + f"[{percentiles[0]:.2f}, {percentiles[1]:.2f}]" |
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.
I had to remove this \
for linting. With it, the docstring output fails flake8 and doctest issues a deprecation warning for an invalid escape sequence. Is this needed for another reason - such as being able to put these strings into LaTEX documents?
percentiles = self.causal_impact.quantile([0.03, 1 - 0.03]).values | ||
ci = r"$CI_{94\%}$" + f"[{percentiles[0]:.2f}, {percentiles[1]:.2f}]" | ||
ci = r"$CI_{94%}$" + f"[{percentiles[0]:.2f}, {percentiles[1]:.2f}]" |
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.
Same as in the DiD experiment summary above.
91ccbd9
to
ef10948
Compare
I've cleaned up the example output, added doctest to the CI workflow and all examples pass locally. I've also added examples for the new IV model and experiment added in #213 . This is ready for a new review @drbenvincent when you have a chance. |
Hi @jpreszler. Thanks for the updates. I'll try to carve out some time (I now have an 11 day old son now!) to review properly. But in the mean time I triggered the remote checks and it looks like we've got a failure. The test output looks like it could be just a missing import of |
@drbenvincent , it looks like statsmodels wasn't being installed into the remote environment so I added it to the dependencies. That should fix the test failure. Congratulations on the baby boy! |
Looks like there's a little instability in the summary output that I'm looking into fixing. |
…ts and some pymc models
1f798f9
to
b5e6dc6
Compare
I should have all the instability addressed, the doctests passed in the remote environment on my fork as well as locally. |
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.
Great stuff. I did a quick pass and left a few more change requests. It's really coming along.
@drbenvincent Thanks for the helpful comments. I've made the improvements so this is ready for another look when you have time. |
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 really getting there! Not far to go I think.
Sorry for the iterative nature of this, but having had time to stare at this for a while, I've had some thoughts.
I think the docstring examples are great. But perhaps we've overdone it. I feel that one example for each class makes a lot of sense, but examples for accessing properties (like result.idata
) and some/all methods (e.g. result.plot()
) are overkill. My feeling is that these are relatively self explanatory and we can perhaps leave it to the example notebooks for users to see more complete worked examples in its full context.
I'm open to counter-arguments, but if you agree then let's just keep one core example per class.
I think there's definitely a bit of redundancy in the examples, and with doctest that adds a lot of time to running tests. I've reduced the redundancy and moved all meaningful examples (like |
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.
Great stuff. I just noticed 2 minor issues in pymc_models.py
:
- Under the
LinearRegression
, there seems to be something going wrong with the note admonition where it saysGenerally, the
.fit()method should be used rather than calling
.build_model()directly.
This could just be an issue with my local build of the docs, but if it's an issue for you also, let's see if we can fix it. - Under the
InstrumentalVariableRegression
class, the:code:
priors = {"mus":...has a line break so it's separate from the
:param priors:` block.
I'm sure there are a bunch of other small errors that we might find or slight improvements, but I'm happy to merge after these minor updates :)
Those issues were not just local to you. I've fixed them and looked for other problems, but didn't spot much besides the same issue in The tests have also passed on my fork after some small adjustments. |
Quick question as I've never used As far as I can tell doctests are run with |
Good call. The same command can run all doctests locally, but I also added a This is my first venture into doctests, but the system is pretty straightforward. A good thing to note is that the |
This is great. When running the doctests I just noticed that it produces new files, |
That's from a few of the doctests for the simulated data, I've skipped the lines that write out the csvs, but leaving the example of how to do so. |
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.
Approving. Thanks for the contribution! The first of many perhaps :)
This addresses issue #129:
Potential future work:
Main items for review: