Forum: help


RE: lmtree plot [ Reply ] By: Achim Zeileis on 2017-02-07 08:26 | [forum:43847] |
Indeed. breakpoints() uses an algorithm that is of order O(n^2) but that is guaranteed to yield the optimal (wrt residual sum of squares) breakpoint estimates. In contrast, recursive partitioning is of order O(n) but is only locally optimal in each step. So as long as the computation time does not become prohibitively long I would use the optimal results. Another "plus" is that the resulting objects look nicer and are geared directly towards time series. |
RE: lmtree plot [ Reply ] By: Markus Loecher on 2017-02-07 06:30 | [forum:43846] |
Thx again, it indeed works very well and finds very similar break points. Interestingly, breakpoints() seems to be much more computationally demanding (an order of magnitude longer execution time) than lmtree, which I assume is due to the different optimization algorithms.? Best Markus |
RE: lmtree plot [ Reply ] By: Achim Zeileis on 2017-02-05 19:49 | [forum:43844] |
If your data are time series then I would simply carry out a structural change (or structural break) analysis rather than relying on recursive tests and splits. The "strucchange" package provides all the necessary tools, specifically breakpoints() will be of interest to you. Let me know if you need more specific advice. (I couldn't look at the Timeseries.png file because it appears to be corrupted, possibly only partially uploaded or so.) BTW: The tools in "strucchange" are what lead to the development of mob() and lmtree(). I had developed this package for parameter instability tests and break point estimation in time series - and Torsten and Kurt had worked on ctree() for recursive partitioning. And then I thought that we could simply merge both tools... |
RE: lmtree plot [ Reply ] By: Markus Loecher on 2017-02-05 13:14 | [forum:43842]![]() |
Thanks a lot, Achim, as always, extremely helpful. I am also very glad you mentioned the technical detail as my data are indeed time series! So I should look up the modified parameter instability test. (The which=1 parameter also worked great; with time series, there is now an interesting choice to be made on the x axis. The default seems to be to set the axis limits to the entire range, whereas it would be visually more pleasing to have leaf node dependent ranges, see attached graph) Thanks! Markus |
RE: lmtree plot [ Reply ] By: Achim Zeileis on 2017-02-04 20:40 | [forum:43841] |
Hi Markus: (1) Conceptually, it is ok to use the same variable for regression and for partitioning. Technical detail: In the asymptotics it is required that for n -> infty you should _not_ have x -> infty. This usually holds in cross-sectional data but might be an issue for time series data, e.g., if x = time. In that case, one should use a modified parameter instability test. (2) At the point in the code where the default display is decided there is no access to the formula (y ~ x | x) but only to the model frame (with y and x). And because there are no variables in addition to the partitioning variables the default decides to use a display without regressors. This can be easily worked around though by setting which = 1 in the panel function R> m <- lmtree(dist ~ speed | speed, data = cars, alpha = 0.8) R> plot(m, tp_args = list(which = 1)) (3) The default panel function employed in the case with regressors is node_bivplot(), see ?node_bivplot for the details. |
lmtree plot [ Reply ] By: Markus Loecher on 2017-02-04 12:45 | [forum:43840] |
Dear authors, thanks for the very useful lmtree function. Allow me to forward the following questions: - From a conceptual point of view, is there any issue in conditioning on the same variables as the ind. regression variable, e.g.: lmtree(y ~ x | x,...). - The plots of an lmtree object examples in the vignettes and help files all produce (nice) "lm type plots", i.e. a scatter plot with a regression line overlaid. In my case, I get a boxplot, what could be the reason? - Are there help pages for plot.lmtree() and in particular the allowed options for "terminal_panel " ? Thanks! Markus |