[Gretl-devel] scalar function args and NAs
svetosch at gmx.net
Sun Jul 5 13:32:28 EDT 2015
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:
>> 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?
More information about the Gretl-devel