Change in the default bandwidth of -lpoly- from Stata 15/16 to 17

[Bert Jung]

Hello Stata and Statalisters,

The default bandwidth of -lpoly- appears to have changed from Stata 16 to 17.

For the below graphs I abbreviated the example in the lpoly help. The resulting graphs are different and the reason is that the default bandwidth that lpoly calculates has changed, from 5.03 in Stata 16 to 2.79 in Stata 17. Indeed, I get the same graphs when I manually change the default bandwidth, e.g., using the bandwidth that MP16 calculates as input for MP17 (also below). Stata 15 gives the same default result as 16. Using -version- under Stata 17 does not resolve this issue.

As far as I can see, this change has not been documented. The description for the default bandwidth under "Methods and formulas" seem to be identical in the manuals for Stata 16 and 17, here and here respectively. However, the default behavior is clearly different.

Is this an intended change or an error?

sysuse auto, clear
lpoly weight length

[Leonardo Guizzetti]

I can't reproduce your problem, using fully updated Stata 16.1 and 17 for Windows. The bandwidth in each is 2.79.

[Bert Jung]

Thanks so much Leonardo.

I am using a fully updated Stata MP17 on Windows. My comparison in the initial post is from an older version of Stata MP16 on Unix (14 Nov 2019) that I lack permission to update. Apologies, I should have noted that.

But a colleague was able to reproduce my above result using her fully updated Stata 16 for Windows. She also gets a default bandwidth of 5.03.

[William Lisowski]

In the output of

help whatsnew16

we see

-------- update 15dec2020 ----------------------------------------------
...
     4. lpoly, in the default case of kernel epanechnikov with the
        rule-of-thumb bandwidth estimator, produced an incorrect value
        for the bandwidth estimate.  This also affected the default
        pilot bandwidth used for the standard-error computation with
        kernel epanechnikov.  The estimated bandwidth value was larger
        than it should have been, which led to oversmoothing.  The
        constant in the rule-of-thumb estimator incorrectly integrated
        over the interval [-1, 1] instead of the correct interval
        [-sqrt(5), sqrt(5)].  This has been fixed.
...

[Bert Jung]

Thanks very much William and Leonardo.