Re: [Gretl-devel] [Gretl-users] Kendall's tau
On Sat, 18 Jun 2016, Sven Schreiber wrote:
Am 17.06.2016 um 16:56 schrieb Allin Cottrell:
> On Wed, 15 Jun 2016, Sven Schreiber wrote:
>>
>> Ok, so it looks like after hansl's corr() accepts this additional
>> optional argument (for example 0 := parametric correlation/default, 1
>> := Spearman, 2:= Kendall), ...
>>
>> Although I don't yet understand how the new option to the hansl
>> function corr() would be transmitted to gretl's series_2_func().
>
> It couldn't be, as things stand: series_2_func() just accepts two series
> arguments and nothing else. The procedure would probably be to scan
> geneval.c for an existing alternative "wrapper" function that could
> accept two series and a scalar: if so, transfer the handling of F_COR to
> that function; if not, write a more specialized wrapper for use with F_COR.
>
Well I guess you had this in mind:
"
/* evaluate a built-in function that has three arguments */
static NODE *eval_3args_func " ...
Not necessarily; see below.
It's a pretty big and generic function, though. I'm not sure
I understand why
some wrapper functions are pretty specialized with respect to the argument
types, and others like the one above seem to handle a lot of different stuff.
Well, there's a trade-off here. At one extreme, we could write a
specific callback function for each entry in the eval() "switch"; at
the other extreme we could write just a few, very bulky, callbacks
that each covered a big percentage of the entries. But neither of
these extremes is very attractive.
What we actually do is look for commonalities among the functions to
be handled, and try to group them according to those commonalities.
One relevant consideration is the number and type of the arguments to
be processed -- as in series_2_func() which handles a number of
functions that demand two series arguments -- but that's not the only
consideration. Note that eval_3args_func() is not used for _all_
functions that take three arguments; it's really a handler for
3-argument functions "not elsewhere classified".
So far as I can see there can be no definitive algorithm for
allocating function identifiers across callbacks. What we have at
present is the outcome of an imperfect attempt to judge which
functions reasonably "belong together" for the purpose of evaluation.
Allin