Re: st: RD Optimal Bandwidth Algorithm sensitive to scaling?

[Austin Nichols <austinnichols@gmail.com>]

Chris--
I agree it is an undesirable "feature" of the optimal bandwidth
calculation, but some problem of this sort is probably unavoidable--in
this case it arises from estimating local curvature using squared
deviations of the outcome, which is evidently sensitive to scale.
There are alternative approaches which would not face this exact
problem, but there would almost surely be other problems, or other
ways of breaking the estimator.  The sensitivity of bandwidth to scale
is particularly undesirable, but also serves to illustrate what I have
said elsewhere: bandwidth selection is more art than science, and at a
minimum you should assess the sensitivity of your estimates to
bandwidth, which is why graphs for multiple bandwidths are produced by
default in -rd-, and there is an option -bdep- to assess the
dependence graphically.

On Fri, Jul 15, 2011 at 9:45 AM, Stata Chris <statachris@gmail.com> wrote:
> Dear list members,
>
> I am using Austin Nichols' -rd-
> (http://ideas.repec.org/c/boc/bocode/s456888.html) command,
> as well as the related -rdob- by Fuji-Imbens-Kalyanaraman-Fuji
> (http://www.economics.harvard.edu/faculty/imbens/software_imbens)
>
> Now I've discovered that the optimal bandwidth chosen and hence the
> resulting estimates are sensitive to the scaling of the outcome variable.
> To demonstrate this, I make use of an example discussed in this context
> in an earlier post:
>
> sysuse auto, clear
> gen Price = price/1000
> gen z = length - 193
> rd price z
> rd Price z
>
>
> As you can check, when I use as outcome the price in 1000 dollars
> ("Price") rather than in dollars ("price"), I get a different bandwidth
> and hence a very different estimate,
> whereas I think I would wish to get the previous estimate just divided
> by 1000.
>
> This does not seem a very desirable property to me, but I'm not sure
> where in the optimal bandwidth algorithm (see
> http://www.nber.org/papers/w14726 ) this comes from
> and whether it would be possible to avoid this. Probably some of you
> can say more about this?
>
*
*   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/