Am 15.06.2016 um 00:47 schrieb Allin Cottrell:
For functions, the entry-point to the labyrinth is the function eval()
in geneval.c. There's a big "switch" statement there that type-checks
then sends arguments to all the built-in functions. Depending on the
complexity of the function it may be handled directly in geneval.c or
(more likely) handed off to a more specialized source module.
The function identifiers in the "switch" are upper-case "enum"
values
prefixed with "F_", as in F_LOG, F_CUM, etc. Usually it should be fairly
clear what userland function names these correspond to, but in case of
doubt the mapping can be found in genlex.c (str_table_funcs).
Ok, so it looks like after hansl's corr() accepts this additional
optional argument (for example 0 := parametric correlation/default, 1 :=
Spearman, 2:= Kendall), then gretl's series_2_func() in geneval.c
needs to decide whether to invoke gretl_corr() living in describe.c, or
spearman_rho(), or real_kendall_tau() both living in nonparam.c.
In particular these lines I guess:
<from_geneval.c>
case F_COR:
ret->v.xval = gretl_corr(t1, t2, x, y, NULL);
break;
</from_geneval.c>
Although I don't yet understand how the new option to the hansl function
corr() would be transmitted to gretl's series_2_func().
(BTW, why the "real" in real_kendall_tau's name?)
I guess hansl's mcorr() also would have to be extended then. Intuitively
I would be in favor of a merge of corr() and mcorr() I guess. The scalar
return value of corr() would be like a special 1x1 case of the return
matrix of mcorr(). But I digress.
Thanks,
sven