[Gretl-devel] scalar function args and NAs

Summers, Peter psummers at highpoint.edu
Sun Jul 5 13:53:50 EDT 2015

I think I have an example of how this problem could arise with int's. Suppose I have a script doing MCMC, where one of the steps is drawing numbers from a student-t distribution (or evaluating its likelihood, or whatever):

function bundle do_stuff_with_t_dist(matrix mean_vec, matrix cov_mat, int df)
{do stuff using df degrees of freedom}
end function

Then suppose df is the result of some calculation that generates an NA. This would likely be a symptom of some other problem in the main MCMC routine. In this example presumably an error would get generated somewhere in do_stuff_with_t_dist, but might there be other cases where treating NA as 'not applicable' would be more problematic? 

This is mostly just off the top of my head...


Sent from my iPad

> On Jul 5, 2015, at 1:32 PM, Sven Schreiber <svetosch at gmx.net> 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 at lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel

More information about the Gretl-devel mailing list