Timeline for LOWESS implementation in Stata vs. R (and Python)
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 21, 2017 at 23:33 | comment | added | akavalar | Thanks Josef! I don’t think Stata takes ties into account either. | |
| Feb 19, 2017 at 21:53 | comment | added | Josef | Another possibility about Stata's choice. Maybe it was initially an unintentional oversight or wrong analogy, but if it works better in some cases, it might be an intentional choice to keep it that way. | |
| Feb 19, 2017 at 21:29 | comment | added | Josef | Related to design choices for LOWESS: I don't know what the tie handling is supposed to be. statsmodels' lowess has problems when there are a large number of observations with identical x, which do not show up if the underlying data is continuous, e.g. should neighbors include all observations that are tied at the boundary? | |
| Feb 19, 2017 at 21:27 | comment | added | Josef | I don't know what the motivation of Stata developers is for this choice. As statsmodels developer I don't always like the choices of other packages, and then I don't feel compelled to follow them, at least not for the defaults. Sometimes there are also some computational shortcuts that differ across packages. | |
| Feb 19, 2017 at 20:49 | comment | added | akavalar | Interesting, thanks for chiming in. It was indeed the "boundary oversmoothing" that caught my attention, and I agree that calling this a bug is probably not entirely correct. I do find it quite frustrating that they've implemented this in such a non-standard way as it makes it harder to replicate one's results in other software. I still wonder if this was really intentional, or merely a byproduct/oversight of switching from "running-mean and running-line least-squares smoothing" to LOWESS - see Edit I and the subtle note (p9) of this. | |
| Feb 19, 2017 at 6:11 | history | answered | Josef | CC BY-SA 3.0 |