Notice: On March 31, it was **announced** that Statalist is moving from an email list to a **forum**. The old list will shut down on April 23, and its replacement, **statalist.org** is already up and running.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From |
Alistair Windsor <alistair.windsor@gmail.com> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: Re: st: Bootstrap error message |

Date |
Wed, 11 May 2011 11:34:01 -0500 |

/* capture is necessary since some project have no students on some semester standings and this causes a crash unless capture is present */

- capture confirm matrix e(b) e(V) - if !_rc { - tempname fullmat - _check_omit `fullmat', get = _check_omit __000001, get - local checkmat "checkmat(`fullmat')" = local checkmat "checkmat(__000001)" - }

= _check_omit __000001, check result(omit)

ON THE FAILURE OF THE BOOTSTRAP FOR MATCHING ESTIMATORS Author: Abadie, A. Imbens, G. W. Journal title TECHNICAL WORKING PAPER- NATIONAL BUREAU OF ECONOMIC RESEARCH INCORPORATED Bibliographic details 2006, ISSU 325, pages ALL

Elizabeth Stuart wrote a paper "Matching Methods for Causal Inference:

Yours, Alistair

From: Stas Kolenikov <skolenik@gmail.com> Subject: Re: st: Bootstrap error message Date: Wed, 11 May 2011 10:21:25 -0500

Alistair Windsor is bootstrapping some complicated results of a propensity score matching procedure, and reports an obscure "e(b) not found" message. My reactions: If you have a -capture-, you should have -if _rc{ }- following it with treatment of the exception. Otherwise you just sweep the errors (that you obviously are expecting to occur) under the carpet. (In my code, I might leave an empty -else- and explain in the comments that no treatment is needed, and state the reason why.) Which part of code produces the message about missing e(b)? Apparently, you don't refer to it directly, but some of the code (in the -bootstrap-? in the -psmatch2-?) wants to get it. You would want to -set trace on- and may be -set tracedepth 3- or so to see who produces the message (increasing the tracedepth as needed if you can't find the culprit; without the tracedepth, you can get quite deeply into say the bootstrap code, with several nested levels of subroutines, and it will be difficult to tell where the problem really is). I have reservations about applicability of the bootstrap procedures with matching. I can buy a bootstrap procedure when the statistic is smooth. Matching, on the other hand, is intrinsically non-differentiable: when you take a new subsample, you will probably jump to a different neighbor. And jumps are bad. If somebody has a reference to a paper by say Imbens in say Journal of Econometrics where consistency of the bootstrap is established, I would be so-o-o relieved.

* * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**Follow-Ups**:**Re: Re: st: Bootstrap error message***From:*Stas Kolenikov <skolenik@gmail.com>

- Prev by Date:
**Re: st: Bootstrap error message** - Next by Date:
**Re: Re: st: Bootstrap error message** - Previous by thread:
**st: Re: Bootstrap error message** - Next by thread:
**Re: Re: st: Bootstrap error message** - Index(es):