On Wed, 15 Jun 2016, Sven Schreiber wrote:
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"
> 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:
ret->v.xval = gretl_corr(t1, t2, x, y, NULL);
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.
(BTW, why the "real" in real_kendall_tau's name?)
It's a fairly common trope in library code to have a public function
"whatever" that (say) accepts and checks user input, then another
"static" (private) function "real_whatever" that actually does the
calculation. That's what's going on in this case.
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.
A merger would be nice, I agree.
Good to see someone else taking an interest in gretl's internals!