Forum: developers


RE: treatment effect API [ Reply ] By: Ott Toomet on 2015-01-26 17:35 | [forum:41845] |
Well, I would say a-c should depend on the amount of code shared between these estimators. I don't know yet, I guess there will be a lot of similar but not identical code. So let's see, I will currently develop it under sampleSelection (alternatively--under econmisc?) The progress will probably not be that fast ;-) An obvious next model to include is the binary-outcome treatment effect model. I will also upload the tex file and make a vignette out of it. Cheers, Ott |
RE: treatment effect API [ Reply ] By: Arne Henningsen on 2015-01-25 22:00 | [forum:41841] |
...and the name treatReg() fits with censReg() and intReg() :-) I think that it is a good idea to add the tex file as a "vignette." Should treatReg() ... a) be included in the sampleSelection package, b) be moved to a new package "treatReg", or c) be included in the sampleSelection package for now but moved to a new package "treatReg" later (e.g. if we have implemented further model specifications)? I do not have a strong opinion on that but option "a" is probably my least favourite. What's about you? |
RE: treatment effect API [ Reply ] By: Ott Toomet on 2015-01-25 21:26 | [forum:41840] |
Hmm... Why not. It is in any case not such a model that is commonly called sample selection model. So treatReg might work. I added the code (now called heckitTfit) to the repo and made corresponding changes to the documentation and NAMESPACE. Maybe rename it later. What do you think about adding the tex file I created to the repo? (in inst/doc) In short run it might simply be a vignette, in long run a journal paper. Seems like our R papers are well cited ;-) |
RE: treatment effect API [ Reply ] By: Arne Henningsen on 2015-01-25 18:37 | [forum:41833] |
Hi Ott! It is great that you have started to work on treatment effects models, as many R users will be very happy if they are implemented in R :-) I agree with you that "a" is not the best solution. I propose another option: c) treatReg( selection, outcome, ... ), where argument "outcome" is the outcome equation, where the explanatory variables could either include (c1) or not include (c2) the treatment variable (dependent variable of the selection equation). In case of c2, the dependent variable of the selection equation is automatically added as further explanatory variable. This option would allow us to implement further specifications of treatment effects models, e.g. similar to the STATA function ivtreatreg: http://www.stata.com/meeting/italy11/abstracts/italy11_cerulli.pdf What do you think? Best wishes, Arne |
treatment effect API [ Reply ] By: Ott Toomet on 2015-01-23 02:59 | [forum:41825]![]() |
The current treatment effect model (see the pdf) includes two single equations: * selection * outcome that includes the selection outcome as explanatory variable. What is a good way to call it? a) call it in the same way as tobit2. Insert a piece of code that figures out if selection outcome is used as an outcome explanatory variable. b) call it the same way, but introduce another argument like "model=" where the user can specify either "tobit2" or "treatment" (this is mentioned in our paper). Myself, I am in favor of b as it is more straightforward to code, less errors, and less unexpected behavior. |