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