Re: [Gretl-devel] scalar function args and NAs
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):
<hansl>
function bundle do_stuff_with_t_dist(matrix mean_vec, matrix cov_mat, int df)
{do stuff using df degrees of freedom}
end function
</hansl>
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...
PS
Sent from my iPad
On Jul 5, 2015, at 1:32 PM, Sven Schreiber <svetosch(a)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(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel