Pull Request for #8: Package Speedup

[mcaceresb]

@jerrayc I've moved the contamination bias decomposition to be computed separately from the main estimation. This speeds up the function run significantly as this took the bulk of the runtime. Please check:

• [x] The help files have been correctly updated and are understandable.
• [x] The decomposition is not computed by default.
• [x] The decomposition can be computed after the main run with cached results.
• [x] lambda, tau can be computed after the main run with cached results.
• [x] The decomposition can be computed along the main run.
• [x] lambda, tau can be computed along the main run.
• [x] The examples run.
• [x] The unit tests run.
• [ ] The help files are consistent with a public github repo.
• [ ] The README is (ibid.)

[jerrayc]

@mcaceresb Reviewing this PR and making edits/comments now. A few initial things to flag:

• Peter said that they want to make the Stata package repo public, and hold off on ssc submission until after they allow people to make comments on the paper after it is released. Can you make it public after we finish this PR?
• Consequently, the helpfile note to download the example_star.dta data using "ssc install multe, all" should be changed to a note that mentions the example data is available for download from the repo.
• Is it possible to lower the version requirement on MulTE()? I'm getting an error when trying to run multe on Stata/SE 16.1:

. use test/example_star.dta

. multe score treatment, control(school)
(MulTE() in lmulte, compiled by Stata 17.0, is too new to be run by this version of
Stata and so was ignored)
                 <istmt>:  3499  MulTE() not found
r(3499);

[mcaceresb]

@jerrayc I rebuilt the mata file with 14.1. Should be good. Let's make it a task in this PR to make sure the repo makes sense if it should be public. This includes:

• Making sure the help files are consistent with a public github repo.
• Make sure the README is (ibid.)

I'll work on the above and update the top level tasks when I do.

[jerrayc]

@mcaceresb Does it make sense to make a new branch that is meant to be public, or should we somehow store parts of this repo away that we might not want to be part of the repo (i.e. some of the files in test)?

Or is there a way to set up the repo to keep some files private while others are public?

The other thing is if we want to eventually submit this to SSC, then we would want to save the SSC submission file somewhere until we are ready to submit it.

[mcaceresb]

@mcaceresb Does it make sense to make a new branch that is meant to be public, or should we somehow store parts of this repo away that we might not want to be part of the repo (i.e. some of the files in test)?

Or is there a way to set up the repo to keep some files private while others are public?

The other thing is if we want to eventually submit this to SSC, then we would want to save the SSC submission file somewhere until we are ready to submit it.

@jerrayc It is the nature of git that all is public, as it goes. We can, of course, "clean" the main branch and leave the rest in a side-branch, but this would all be public in the end (though perhaps obfuscated). I believe it should be possible to keep the repository private and make a public website for it. This might be something to look into after we wrap this up.

Either way when we merge this, we should open an issue called "Taking the package public" just to get confirmation from the team, or do you think that's overkill? We can also ask in that issue whether it's OK to make the whole repo public or if they'd prefer parts remain private. If the latter, I think a website might be the solution (though I haven't tried the private/public thing before, it's supposed to be doable).

[jerrayc]

@mcaceresb Besides the open question about what to do with the timer code, and besides the preparation for public repo (last two top level tasks), I have confirmed the rest of the top level tasks and reviewed all code changes.

[jerrayc]

@mcaceresb Update re making repo public: I talked to Peter and we agreed to make it public, and that it's fine to leave the extraneous files (e.g. SSC submission text, test do files, etc.). I think a reasonable course of action would be:

1. Make the file public for the initial NBER draft release
2. Make a separate branch to work on SSC submission
3. Once the SSC submission is ready, merge to main, submit the package to SSC, and make the repo private again.

Does this sound good to you?

[mcaceresb]

@jerrayc I have never switched a private-gone-public repo back to private, but it looks simple enough. I should note that clones and forks of the repository will not be undone.

I have deleted references to the timer. To be clear:

• Once you have approved this PR, I will merge to main and make the repo public? That is, since you talked to Peter already it sounds we don't need further confirmation from the team.
• Once the repo is public, I will open a new issue and branch called "SSC Submission"?

LMK.

[jerrayc]

@mcaceresb Yes, that is what I mean re: bullet points.

Sounds fine if forks and clones will not be undone -- I don't imagine many of those will exist anyway.

Sounds good re: removing timer references.

Ready to squash and merge when you are!

[mcaceresb]

Summary here.