On Mon, 9 Oct 2017, Artur T. wrote: > Dear all, > > just by chance I've found a  bug (at least realized using 4-day old > git on ubuntu). When adding a lagged intercept to the ordered probit > model, gretl gets captured in infinite computation (I would call this > a 'crash'): > > <hansl> > open ooballot -q > smpl Status > 0 --restrict > # works > probit Vote 0 CPI > # crashes (infinite computation) > series const_1 = const(-1) > probit Vote 0 const_1 CPI > </hansl> The problem lies in the function we use for removing the constant from a list (list_purge_const in discrete.c), which doesn't handle well the "lagged constant" case. However, I was thinking: can lagging the constant ever make sense, in any situation? Shouldn't const(-1) be a no-op?

On Mon, 9 Oct 2017, Artur T. wrote: >> However, I was thinking: can lagging the constant ever make sense, >> in any situation? Shouldn't const(-1) be a no-op? > I cannot think of any situation where const(-1) does make sense at > all. It was just by coincidence included in a list of regressors I > worked with. Nevertheless, I guess it would be good if gretl would > return an error in this case. Wouldn't it make sense to pre-check > whether there is any series (apart from the intercept) with variance=0? The problem is not as simple, as we need to guard against "constants in disguise", as for example exhaustive sets of dummies. The more I think about this, the more I'm convinced we should throw an error at any attempt to create lags of "const".

On Mon, 9 Oct 2017, Artur T. wrote: > Dear all, > > just by chance I've found a  bug (at least realized using 4-day old git on > ubuntu). When adding a lagged intercept to the ordered probit model, gretl > gets captured in infinite computation (I would call this a 'crash'): > > <hansl> > open ooballot -q > smpl Status > 0 --restrict > # works > probit Vote 0 CPI > # crashes (infinite computation) > series const_1 = const(-1) > probit Vote 0 const_1 CPI > </hansl> The problem lies in the function we use for removing the constant from a list (list_purge_const in discrete.c), which doesn't handle well the "lagged constant" case.

However, I was thinking: can lagging the constant ever make sense, in any situation? Shouldn't const(-1) be a no-op?

On Mon, 9 Oct 2017, Allin Cottrell wrote: > On Mon, 9 Oct 2017, Riccardo (Jack) Lucchetti wrote: > >> However, I was thinking: can lagging the constant ever make sense, >> in any situation? Shouldn't const(-1) be a no-op? > > I suppose it could be used as a tricksy way of getting a series > that's all 1s apart from NA at observation 1. We could ban the > operation but I'm not sure that would be worthwhile. Looking further into this, I see that we already flagged an error if "const" was passed to the lags() function -- but, inconsistently, we accepted it in simple form such as "const(-1)". So now I've made it an error in either case, with a new error message, "The constant cannot be lagged". I think that's right, it's a nonsensical operation. Allin