[Gretl-devel] scalar function args and NAs

Allin Cottrell cottrell at wfu.edu
Sun Jul 5 18:50:12 EDT 2015


On Sun, 5 Jul 2015, Riccardo (Jack) Lucchetti wrote:

> On Sun, 5 Jul 2015, Allin Cottrell wrote:
>
>> 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?
>
> My very personal position is not to check automatically. It shifts the burden 
> on "do the right thing" on the function writer, who should bear 
> responsibility for what she does.
>
> Besides, NA could very well be an idiomatic way of saying "make some 
> automatic choice", which can be very useful at times (think for example lags 
> in a unit-root test).

OK, that's what I was looking for: a plausible case where NA might 
be OK for an int or bool argument. So let's go with the old status 
quo where NAs are never ruled out by gretl itself. If the function 
writer doesn't handle NA, hopefully the resulting error message will 
trace back to a bad argument in a reasonably comprehensible manner.

Allin


More information about the Gretl-devel mailing list