# sum # # Output:  scalar or series # Argument:  x  (series, matrix or list) <hansl> clear scalar one = 1 catch scalar su = sum(one) clear matrix one = 1 scalar su = sum(one) nulldata 3 series one = 1 su0 = sum(one) su = sum(1) ### clear, the argument is treated as list ### with only element -- series number 1 scalar unit = 1 su2 = sum(unit) #also eval sum(1.0) catch eval sum(1.1) eval sum(0) # zero is interpreted as a list consisting only of the constant eval sum(const) # interestingly here 'const' is interpreted as series!!! series su3 = sum($pd) print su3 <hansl> My opinion: help lacks explanations of default interptetaions. SCALARS are not listed among arguments types AT ALL Hence, INTEGERS (including $pd) should be interpreted as one of the listed types (i.e. series, matrix or list) Examples above show that integers are interpreted as lists with 1 element: global series NUMBER inputted scalar Since, in sum(1) 1 is the number of series and this series builds a list with one element 1) In any case it is desirable to describe default integers behavior Also why interpretation of 0 and const is different in ols y 0 xlist and ols y const xlist 0 and const are the same 2) I do not know whether some changes are need but it is obvious that help to sum() should explain such things Oleh 13 лютого 2018, 12:30:44, від "Sven Schreiber" <svetosch(a)gmx.net&gt;: Hi, here's something that I find puzzling (snapshot Feb 7): <hansl> clear catch eval sum(1) # error: "no dataset active" catch scalar sc = sum(1) # ditto open djclose.gdt catch eval sum(djclose) # OK catch eval sum(1) # weird printout of all values, almost like 'print 1' catch scalar sc = sum(1) # error: "data types not matched" catch scalar sc = sum(djclose) # OK catch scalar sc = sum(1) # error: "sc is scalar, not acceptable" </hansl> I can understand the first two occurring "no dataset active" errors if gretl interprets the '1' as a series ID which it cannot find. But then: First the behavior yielding the weird printout looks like a bug. Secondly, the final two different error messages is something I don't get. Also bugs? thanks, sven _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Am 13.02.2018 um 18:33 schrieb Allin Cottrell: First a very minor comment: Isn't it strange that the same lines (1 & 3) result in two different error messages? Ah, OK. I understand. First I thought "why change something that's working?", but then I thought more about anonymous on-the-fly lists in this context, consider the following: <hansl> open denmark list mylist = 1 eval sum(mylist) # series itself (trivial cross-sum) eval sum(1) # ditto eval sum({1}) # gives 1 mylist = {1, 2} eval sum(mylist) # gives a sum series eval sum({1, 2}) # gives 3 mylist = 1 2 # works eval sum(1 2) # doesn't work (as expected) </hansl> If a function accepts an anonymous single-member list declared by ID such as '1', then it should also accept a more general ID definition. But AFAICS that's not possible in hansl, because of the clash with a standard matrix. (See the "gives 1" and "gives 3" lines above.) So yes, it now seems to me the cleanest solution is to ban such weird (at least to me) anonymous list constructs there! Then this would also be consistent with your rule above about series IDs in functions. Jack, take note, I'm in favor of a backwards-incompatible change... cheers, sven