Am 05.07.2015 um 17:08 schrieb Allin Cottrell: > > But maybe this is something we want to think about. Are there real > use-cases where a function writer would want to accept NA for a bool or > int argument? Or would it be more convenient for the writer not to have > to bother with checking for NAs, in the knowledge that they would be > ruled out by gretl? > Well, NaN rather than NA, but since they're not differentiated in gretl: In principle I could imagine that a function has the log-value of something as its input. Then the caller could write: thefunc(log(thisvalue)) which could end up as thefunc(NA) for thisvalue <= 0. The question then is really who should bear the burden of sanity checking, the function or the caller.

On Jul 5, 2015, at 1:32 PM, Sven Schreiber <svetosch(a)gmx.net&gt; wrote: > Am 05.07.2015 um 19:24 schrieb Allin Cottrell: >> On Sun, 5 Jul 2015, Sven Schreiber wrote: >> >>> Am 05.07.2015 um 17:08 schrieb Allin Cottrell: >>> >>> >>> But maybe this is something we want to think about. Are there real >>> use-cases where a function writer would want to accept NA for a bool or >>> int argument? Or would it be more convenient for the writer not to have >>> to bother with checking for NAs, in the knowledge that they would be >>> ruled out by gretl? >> >> Well, NaN rather than NA, but since they're not differentiated in gretl: >> In principle I could imagine that a function has the log-value of >> something as its input. Then the caller could write: >> >> thefunc(log(thisvalue)) >> >> which could end up as thefunc(NA) for thisvalue <= 0. The question >> then is really who should bear the burden of sanity checking, the >> function or the caller. > > Thanks, Sven. The log example would seem to pertain to parameters marked > as plain "scalar" rather than int or bool. My point was that for int and > bool parameters there's potentially a third option: gretl itself could > bear the burden of sanity checking -- unless, that is, there's a real > case for user-functions that are OK with getting NAs for ints or bools. > (Presumably such functions would check for NA and treat it as meaning > "not applicable".) Ah, right. Anyway, if a difference is to be made between the treatment of bool, int, scalar, I would draw the line between bool and the rest, not between scalar and the rest. A bool is really a very special thing and not really a number in some sense. And you have the null value that you can use for "not applicable". But an int is not that different from a scalar, if taken to the extreme, since computers don't have continuous number sets anyway. Why introduce a difference here, just because today we're lacking the phantasy how the int can become NA? thanks, sven _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

A question has come up as I've thought about user-function arguments (see also http://lists.wfu.edu/pipermail/gretl-devel/2015-July/005850.html ) Given a scalar parameter, what do we want to do if the caller supplies NA as an argument? What difference, if any, should it make if the parameter is marked as "bool" or "int" rather than plain "scalar"? The situation prior to my changes of the last couple of days was that NA was always accepted. But along with fixing the bounds checking for scalar arguments, I banned NA for bool and int parameters. I've now had second thoughts (maybe this would break some existing scripts?) and have reverted to the status quo ante. But maybe this is something we want to think about. Are there real use-cases where a function writer would want to accept NA for a bool or int argument? Or would it be more convenient for the writer not to have to bother with checking for NAs, in the knowledge that they would be ruled out by gretl?