On Mon, 10 Nov 2014, Sven Schreiber wrote: OK, this is quite "interesting". Perhaps the first point to note is that the "print" command is not designed to evaluate its argument(s) unless the argument evaluates to a list (one basic use of "print" being to print the values of a list of series). To print the value of an arbitrary expression one uses "eval" (which right now is a sort of print-only alias for "genr", but needs to be made into a command in its own right so it can be properly documented.) So if you substitute "eval" for "print" in the above script it will work as expected. But then why is "print" not throwing an error rather than printing something unexpected/wrong? Take the first example: sqrt(a) evaluates to 1.87 which yields 1 when truncated to an integer. So it's being read as defining a singleton list with member 1. So what gets printed is the values of the series at position 1 in the dataset. In the second example gretl is baulking at interpreting the square root of a matrix as defining a list member, so it's passing "sqrt(ma)" to the routine for printing named variables of whatever type (other than series). And the parser for getting variable names out of this string was certainly too sloppy. It recognized "ma" and printed that, while simply ignoring "sqrt(" and ")". In CVS I've tightened up the aforementioned sloppy parsing: so "print sqrt(ma)", for 'ma' a matrix, will now generate an error. The first case is trickier, but it seems too sloppy in a different way. In defining a list, something like 1.87 should probably _not_ be read as "1". I'm working on revising that (hopefully with reasonable generality) so that if an argument is supposed to an integer we won't accept any old floating-point value. The tricky bit is that gretl doesn't have a true integer type among its user-definable variables, so we'll probably have to tolerate tiny divergences from exact integer-hood. But a divergence of 0.87 (or even the complementary 0.13) should be out of bounds! Allin