On Fri, 23 Aug 2019, Sven Schreiber wrote: This should do it: <hansl> set verbose off open denmark.gdt --quiet list X = LRM LRY IBO IDE var 4 X --silent matrix U = $uhat cnameset(U, varnames(X)) gnuplot --matrix=U --with-lines --time-series --output=display </hansl> this could be made nicer with a column for time; unfortunately, I can't think of any easy automatic way to construct this, other than introducing a couple of new functions to retrieve the "t1" and "t2" integers that are contained in the matrix info. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

On 23.08.19 12:49, Riccardo (Jack) Lucchetti wrote: OK now that Allin has fixed the $system.t1 (and t2) bug, we can get those numbers. However, it's not clear to me how these can be used to get the associated time period labels showing up on the x-axis. (Side question: How to inject such t1 and t2 info into an existing matrix?) Obviously you get the time labeling for free if you work with series and lists. So here's a little function that does it that way. (Current git is needed because of the bug fixed just recently.) <hansl> function void plotsysres(bundle sys)     start = sys.t1 # requires 2019d / current git     stop = sys.t2     smpl start stop     strings nn = varnames(sys.ylist)     list L     loop i=1..cols(sys.uhat) -q         L += genseries(nn[i], sys.uhat[,i])     endloop     gnuplot L --with-lines --time-series --output=display end function open denmark.gdt --quiet list X = LRM LRY IBO IDE var 4 X --silent plotsysres($system) </hansl> But I repeat, all this is quite clumsy IMHO. My proposal would be that the data in $uhat (or $system.uhat) should also be retrievable as a list, with automatic names in the pattern <var1>_res or something like that, similar to how lags and differences and other pre-defined name patterns are handled. thanks sven

On Mon, 26 Aug 2019, Sven S wrote: I agree. I have another idea: at present, we allow <hansl> series x = matrix </hansl> provided the matrix in question has the right number of rows and one column. In many cases, it'd be very useful to have a parallel "multivariate" construct, such as <pseudo-hansl> list X = matrix </pseudo-hansl> which would generate the series X_01, X_02, etc (of course, if rows(matrix) == $nobs). The identifiers could be taken from the column labels, if present, or the list name by default as in my example. This would be quite handy, I think. ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

On Mon, 26 Aug 2019, Sven S wrote: This is an excellent idea. Having a dedicated function like cnameset() would make perfect sense to me. limitset(), perhaps, or something like that? ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

On Mon, 26 Aug 2019, Sven S wrote: Yes, that's what happens in the single-series case and it would be natural to do it for the list case too. Sorry, I haven't been following this very closely, but what's the case where you'd need to inject such information (I mean, where it wouldn't already be attached by gretl)? Allin

Am 26.08.2019 um 16:55 schrieb Riccardo (Jack) Lucchetti: Yes; however, I have to admit that I had lost track of the fact that $uhat already has the t1 and t2 infos, which was the original issue here. cheers sven

On Mon, 26 Aug 2019, Riccardo (Jack) Lucchetti wrote: I agree. But several policies have to be decided in the implementation of this. Here's what's in current git on the "newcomplex" branch. 1) As with other "genr" things, the current sample range is respected in creating or modifying series: we will not write outside of that range. 2) We have to able to match rows of the matrix to observations in the dataset. We do this by using the t1 and t2 tags attached to the matrix, if present (in which case it's an error if there's no overlap between the matrix t1 to t2 range and the current sample range). Otherwise we match if the number of rows equals the number of observations (a) in the dataset as a whole or (b) in the current sample range. Otherwise error. 3) We need valid series names. If the matrix has column names we use them. It's then an error if any of them are not valid identifiers, or if there are any duplicates among them. If the source matrix doesn't have column names we use the name of the matrix itself (if it's named), or failing that the name of the list to which the new series are being assigned. We append column numbers for uniqueness and it's an error if the matrix or list name is too long to accomodate the suffix. 4) If any of the names thus constructed are names of existing non-series objects, an error is flagged and no list is produced. If any of them are names of pre-existing series, the original series are over-written over the current sample range. Allin

On Tue, 27 Aug 2019, Sven Schreiber wrote: Good question. I need to do a little investigation on the panel case. Allin

On Tue, 27 Aug 2019, Sven Schreiber wrote: Yes, they do exist for panel data -- when estimation is performed for a specification that involves multiple sets of residuals or fitted values represented in matrix form, such as "system" -- but they refer to starting and ending points that must line up with "individuals", not to the time-series dimension as such. It's good you raised this question: my testing on panel data revealed a bug in the new code that I think would equally apply to time-series data, namely an incorrect notion of what exactly the matrix t1- and t2-values imply for alignment with dataset observations. That's now fixed in git and snapshots. Test script follows (please ignore the highly questionable system specification!): <hansl> open nc_crime.gdt -q smpl 5:1 50:7 # use a subset of counties system method=OLS equation crmrte 0 prbarr equation prbarr 0 polpc end system U = $uhat print U list L = U smpl full # check alignment of system residuals print L -o </hansl> Allin

On Wed, 28 Aug 2019, Riccardo (Jack) Lucchetti wrote: Yes, the above obviously ought to work. The bug that stopped it from working is now fixed in git. Allin

Am 23.08.2019 um 12:32 schrieb Riccardo (Jack) Lucchetti: Good idea. But doesn't the following look like a off-by-one bug: <hansl> open denmark.gdt --quiet list X = LRM LRY IBO IDE var 4 X --silent eval $system.t1 # 4 eval $system.t2 # 54 U = $uhat print U # says t1=5, t2=55 </hansl> thanks sven