It's not a pointer Please, run the following to see some strange behavior 1) run <hansl> open keane.gdt -q series lp_mfx_print = normal() include lp-mfx.gfn smpl (year==87) --restrict logit status 0 educ exper expersq black --multinomial -q bundle b = mlogit_mfx(status, $xlist, $coeff, $vcv, $sample) <hansl> Then press b icon at session icon view 2) run <hansl> open keane.gdt -q series lp_mfx_print = normal() include lp-mfx.gfn smpl (year==87) --restrict logit status 0 educ exper expersq black --multinomial -q bundle b = mlogit_mfx(status, $xlist, $coeff, $vcv, $sample) # here press b icon catch  lp_mfx_print(&b) delete lp_mfx_print # here press b icon again lp_mfx_print(&b) <hansl> 3) <hansl> open keane.gdt -q series lp_mfx_print = normal() include lp-mfx.gfn smpl (year==87) --restrict logit status 0 educ exper expersq black --multinomial -q bundle b = mlogit_mfx(status, $xlist, $coeff, $vcv, $sample) catch eval lp_mfx_print(&b) # here press b icon again <hansl> Currently, I have no Idea, how to comment but in the process of executing several strange phenomenons are seen Oleh 24 жовтня 2018, 16:24:46, від oleg_komashko(a)ukr.net: Dear all, In "shadowing" thread, Allin (correctly) noticed that there is a situation where it is difficult to distinguish between series(int_lag) and function series (int_argument) 1) my suggested answer is incorrect, since we can have function series name (int i) and function list name (int i) In this case it is impossible to distinguish between name(int_lag) and name(int_arg) The worse (note that I have obtained the same on Windows10, 2018c and Ubuntu18.04, today's Git <hansl> include lp-mfx.gfn open keane.gdt -q # the following line simulate the situation when a data file already has 'mlogit_mfx' series series mlogit_mfx = normal() smpl (year==87) --restrict logit status 0 educ exper expersq black --multinomial -q bundle b = mlogit_mfx(status, $xlist, $coeff, $vcv, $sample) lp_mfx_print(&b) catch list z = mlogit_mfx(-1 to -2) ser = mlogit_mfx eval mean(ser(-1)) ########### output ? open keane.gdt -q Read datafile /usr/local/share/gretl/data/misc/keane.gdt ? series mlogit_mfx = normal() Generated series mlogit_mfx (ID 19) ? smpl (year==87) --restrict Full data set: 12723 observations Current sample: 1738 observations ? logit status 0 educ exper expersq black --multinomial -q ? bundle b = mlogit_mfx(status, $xlist, $coeff, $vcv, $sample) ? lp_mfx_print(&b) Multinomial logit marginal effects (evaluated at means of regressors) note: dp/dx based on discrete change for black Outcome 1: (status = 1, Pr = 0.0304)               dp/dx        s.e.           z        pval        xbar   educ     0.010826   0.0018373      5.8924  3.8069e-09      12.549  exper    -0.020829   0.0054490     -3.8225  0.00013211      3.4403 expersq    0.0019936  0.00073506      2.7122   0.0066841      17.199  black    -0.011001   0.0076838     -1.4318     0.15221     0.37973 Outcome 2: (status = 2, Pr = 0.1434)               dp/dx        s.e.           z        pval        xbar   educ    -0.045462   0.0039535     -11.499  1.3298e-30      12.549  exper     -0.11360    0.012550     -9.0517  1.4080e-19      3.4403 expersq    0.0076209   0.0016081      4.7392  2.1456e-06      17.199  black     0.065872    0.019682      3.3468  0.00081740     0.37973 Outcome 3: (status = 3, Pr = 0.8263)               dp/dx        s.e.           z        pval        xbar   educ     0.034636   0.0042808      8.0911  5.9137e-16      12.549  exper      0.13443    0.013542      9.9268  3.1829e-23      3.4403 expersq   -0.0096146   0.0017275     -5.5654  2.6150e-08      17.199  black    -0.054870    0.020909     -2.6243   0.0086834     0.37973 ? catch list z = mlogit_mfx(-1 to -2) The symbol 'to' is undefined ? ser = mlogit_mfx Generated series ser (ID 20) ? eval mean(ser(-1)) -0.017113513 We see that both running package functions and 'ser = mlogit_mfx' worked ok But in 'list z = mlogit_mfx(-1 to -2)' 'mlogit_mfx' is interpreted as function In my opinion this phenomenon can easily be avoided since no function can have -1 to -2 as argument Much worse is mlogit_mfx(-1) A possible solution is deprecating mlogit_mfx(-1) and substitution for mlogit_mfx(-1 to -1) To the contrast, <hansl> open keane.gdt -q series lp_mfx_print = normal() include lp-mfx.gfn smpl (year==87) --restrict logit status 0 educ exper expersq black --multinomial -q bundle b = mlogit_mfx(status, $xlist, $coeff, $vcv, $sample) lp_mfx_print(&b) <hansl> Note the difference between the two scripts: 1-st a series have the same name with mlogit_mfx() 2-nd a series have the same name with lp_mfx_print() The rest is the same Also note that confusing named series are not inserted anywhere Here I have ? open keane.gdt -q Read datafile /usr/local/share/gretl/data/misc/keane.gdt ? series lp_mfx_print = normal() Generated series lp_mfx_print (ID 19) ? include lp-mfx.gfn /home/oleh/.gretl/functions/lp-mfx.gfn lp-mfx 0.4, 2016-11-10 (Allin Cottrell) ? smpl (year==87) --restrict Full data set: 12723 observations Current sample: 1738 observations ? logit status 0 educ exper expersq black --multinomial -q ? bundle b = mlogit_mfx(status, $xlist, $coeff, $vcv, $sample) ? lp_mfx_print(&b) Incomplete expression Syntax error Error executing script: halting May be, a pointer argument? So we need at least two corrections 1) some functions stop working 2) something should be done with series(int_lag) Oleh _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

1)  ok! 2) # a native function nulldata 20 setobs 1 1960 --time-series set seed 13 series sin = normal() series y = sin(1) eval getinfo(y) /* bundle anonymous:  has_string_table = 0  lag = -1  parent = sin  name = y  coded = 0  discrete = 0  transform = lags  description = sin(1)  */ # y is described as lag of 'sin'   # but /* 1960    0.8414710 1961    0.8414710 1962    0.8414710 1963    0.8414710 1964    0.8414710 ... */ # i.e. y is a constant series, its values are equal to sin(1) series x = sin eval getinfo(x) eval y - x(1) eval y[1]-sin(1) list z = round(sin(1)) eval varname(z) eval z[1] # user-specified function activated before # reading/creating series nulldata 20 setobs 1 1960 --time-series function scalar x (scalar z)    return exp(1)*z end function set seed 13 series x = normal() series y = x(1) eval getinfo(y) catch ols x x(-1 to -2) -s eval errmsg($error) catch ols x x(-1) -s eval errmsg($error) # we see that currently # functions override lags creation # It seems, a case with unquoted (-1 to -2) # can be easily saved, since # functions do not take unquoted # -1 to -2 argument (have I missed some function?) # But what to do with x(-1) ? Oleh 24 жовтня 2018, 23:59:59, від "Allin Cottrell" <cottrell(a)wfu.edu&gt;: On Wed, 24 Oct 2018, oleg_komashko(a)ukr.net wrote: A mess, to be sure. Fortunately it was easy to fix; the fix is now in git. When the bundle-print function of a package is invoked via the GUI, we know perfectly well it's a function call and nothing to do with lags of a series that a trickster may have created. We just weren't conveying that knowledge to "genr"; now we do. Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Dear Sven, The examples below imitate the following situation: 1) user imports, say .xlsx file with confusing names 2) the function is a package one Or, even so Normally, sin is not a name of variable But I() is the native function Nobody can prevent one to call inflation I in some .xlsx file. So, additional prohibitions would be inconvenient I constructed examples being easily reproduced More realistic version open gdpI.csv #attached ols dgdp const I(-1) oops! What will be, if series I prohibited? OK, I is green, so there is a stimulus to rename it But what if a series name coincides with a name of a package function? Oleh 25 жовтня 2018, 10:29:47, від "Sven Schreiber" <svetosch(a)gmx.net&gt;: Am 25.10.2018 um 08:38 schrieb oleg_komashko(a)ukr.net: series sin = normal() Maybe gretl should be stricter in not allowing built-in function names as identifiers. (Again, I think that was discussed before with the conclucsion that it's not a problem per se.) series y = sin(1) # y is described as lag of 'sin'  Good catch, this is the bug. # but # i.e. y is a constant series, its values are equal to sin(1) This is expected I'd say. BTW, here's something else: series y = normal() series y = y[-1] ...gives NAs (note the square brackets, on purpose). I think it should give an error. cheers, sven _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Dear all, since the current behavior for all functions is override series(int_lag) behavior. A possible solution would be 1) for series(int1 to int2) to protect it from functions, since int1 to int2 can be distinguished from functions arguments 2) for series(int) in each call (for coinciding names only) type warning: series(int) has been interpreted as function call rename series if you want obtain its lags This way the current behavior will be retained for series(int) the only thing to do is give more info Once more, the syntax series(int1 to int2) is separable from function calls Oleh

There is at list one possible problem with package functions in your context: Suppose a package requires time-series data (exactly the case for confusion) So we need to use open filename.ext before include pkg.gfn I do not see a possibility to check names provided the order above The number of packages is growing Packages updates can supply new functions The number of native functions is growing This means what had computed ok would cease Oleh 25 жовтня 2018, 15:26:21, від "Sven Schreiber" <svetosch(a)gmx.net&gt;: Am 25.10.2018 um 10:09 schrieb oleg_komashko(a)ukr.net: Nobody can prevent one to call inflation I in some .xlsx file. That is true; however, if gretl finds illegal names in imported series (e.g. blanks, foreign chars) it changes them already. So in principle it would be easy to also make it illegal to have series named like built-in functions. I'm not saying that this would be the optimal solution, but it's an option. cheers, sven _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Generally, I think some prohibiting based on the version-growing set should be avoided if there is another solution: such prohibition generates endless flow of new backward-incompatibility events I think, the simplest solution is to introduce some (by far not to return to 2018c state) shadowing warnings: 1) for native: if confusing names are detected while opening a file run un-suppressible message that name() lags creation is overrided for variables: varnames 2) for packages: do the same after include pkg.gfn The body of messages can get smaller in the future when Allin will find the time to code detecting thin differences in syntax: no 1 to 2 as function arguments fun(first_arg_is_not_matrix/scalar) etc Oleh P.S. A home-made round-about for names checking attached 25 жовтня 2018, 17:39:44, від "Sven Schreiber" <svetosch(a)gmx.net&gt;: Am 25.10.2018 um 16:04 schrieb oleg_komashko(a)ukr.net: I do not see a possibility to check names provided the order above Yes, I know. Right now I was only picking up the point of whether built-in function names should be "especially" protected. The possible clash between series names and user-written functions (from packages or ad hoc) when it comes to taking lags (or leads) via the round-bracket syntax is the other ongoing topic. cheers, sven _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

For immediate scripting, I think the order of priorities is not very important, since a user can change the both function and variable names But for packages I can not foresee what series names will be in a file opened by other user By the way, if it will be possible to use both fun() and pkg::fun() this can solve the problem for package functions Oleh 25 жовтня 2018, 21:45:29, від "Allin Cottrell" <cottrell(a)wfu.edu&gt;: On Thu, 25 Oct 2018, oleg_komashko(a)ukr.net wrote: In principle, "int1 to int2" can be ruled out as a valid function argument, true. But the parser works left-to-right with only minimal look-ahead (what's the next character?). It would not be easy to support fold-back, as in "Oh, we hit an error, maybe we can fix it by going back and reinterpreting something." (But maybe...) In the meantime, in git, I'm exploring some other heuristics. Inside functions I think the prior preference for the function(args) interpretation should be reversed -- so series(lags) preferred -- if the function in question is not built-in. This is because a function author ought to know what all the series in scope are called (since they're either arguments whose names he has chosen, or series he has defined), but he won't necessarily know the names of any functions that might be floating around in the caller's namespace. Yes, that sounds suitable for cases where we impose the function(args) interpretation under ambiguity. Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

On Thu, 25 Oct 2018, oleg_komashko(a)ukr.net wrote: Fortunately, as a package writer that need not concern you. You will "see" outer series only under names you have chosen for the parameters of your functions. Within your function, series can be confused with functions only if you have chosen names that collide with built-in functions. Allin

On Fri, 26 Oct 2018, Sven Schreiber wrote: But they cannot be referenced by their outer names within the function, you have to use the List.$i syntax. Here's an example: <hansl> function void argnames (list L) loop foreach i L series x$i = L.$i(-1) print x$i endloop end function open denmark rename LRY sin # try to cause trouble! list X = LRM sin argnames(X) </hansl> Inside argnames() we're able to take a lag of the series known as "sin" in main without a problem. Allin

On Fri, 26 Oct 2018, Sven Schreiber wrote: OK. But I'd say that what now happens with your example in git is correct. Within exlag(), the user-function LRM() is masked by the series-name LRM; the function is ignored and the first lag of LRM is created. If that's not what "you" (hypothetical function-writer) wanted, then don't use varnames() on series you got via a list; you can't be sure that these names won't collide with other stuff -- not only functions, but variables of type other than series that you have defined. That's the point of the "List.$i" syntax. I guess if we wanted to get very nanny-ish about this we could figure out a way to make varnames() fail on series whose names you're not supposed to have access to inside a function. Allin

The script below produces Warning: 'mfx' shadows a function of the same name I wanted Warning: 'mfx' shadows a lag creation for series of the same name rename it if you need to use name(lag), or name(lag1 to lag2) Renaming series is much simpler. Instead of unwanted behavior of lags for single variable we have broken package <hansl> nulldata 100 series mfx = normal() series y = normal() series x = normal() include a_eff.gfn ols y 0 x mod = $model mfx(&mod) series z = mfx delete mfx <hansl> Oleh 26 жовтня 2018, 21:36:16, від "Allin Cottrell" <cottrell(a)wfu.edu&gt;: On Fri, 26 Oct 2018, Sven Schreiber wrote: OK. But I'd say that what now happens with your example in git is correct. Within exlag(), the user-function LRM() is masked by the series-name LRM; the function is ignored and the first lag of LRM is created. If that's not what "you" (hypothetical function-writer) wanted, then don't use varnames() on series you got via a list; you can't be sure that these names won't collide with other stuff -- not only functions, but variables of type other than series that you have defined. That's the point of the "List.$i" syntax. I guess if we wanted to get very nanny-ish about this we could figure out a way to make varnames() fail on series whose names you're not supposed to have access to inside a function. Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Nevertheless, some problems are here, but, happily, they are minor ones I looked at dictionaries "cast a shadow over" so, the text is misleading: really function shadows lag creation, so it's desirable to change the text of warning Order-dependence: I created a data file with confusing names (mfx) Closed gretl Reopened Opened the file Ran include a_eff No message Oleh 27 жовтня 2018, 11:15:58, від oleg_komashko(a)ukr.net: The script below produces Warning: 'mfx' shadows a function of the same name I wanted Warning: 'mfx' shadows a lag creation for series of the same name rename it if you need to use name(lag), or name(lag1 to lag2) Renaming series is much simpler. Instead of unwanted behavior of lags for single variable we have broken package <hansl> nulldata 100 series mfx = normal() series y = normal() series x = normal() include a_eff.gfn ols y 0 x mod = $model mfx(&mod) series z = mfx delete mfx <hansl> Oleh 26 жовтня 2018, 21:36:16, від "Allin Cottrell" <cottrell(a)wfu.edu&gt;: On Fri, 26 Oct 2018, Sven Schreiber wrote: OK. But I'd say that what now happens with your example in git is correct. Within exlag(), the user-function LRM() is masked by the series-name LRM; the function is ignored and the first lag of LRM is created. If that's not what "you" (hypothetical function-writer) wanted, then don't use varnames() on series you got via a list; you can't be sure that these names won't collide with other stuff -- not only functions, but variables of type other than series that you have defined. That's the point of the "List.$i" syntax. I guess if we wanted to get very nanny-ish about this we could figure out a way to make varnames() fail on series whose names you're not supposed to have access to inside a function. Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel