Sorry to populate this thread all by myself [and moving to devel]; the rank correlation seems to reside in lib/src/nonparam.c, ok. There are two Kendall-related C functions there, one does the actual calculation and the other one more or less prints the results. Don't know which of these would need to be hooked up to the hansl corr() function, but I would be interested to learn how gretl would do this internally.

In general, built-in functions don't print anything, so it would be the code that calculates tau and its associated z-value that would have to be hooked up; printing would be skipped. There are two ways we could give access to Kendall's tau and Spearman's rho: we could add a third, optional argument to the corr() function to select a variant other than Pearson, or we could add a --quiet option to the "corr" command and make it store $test and $pvalue, so you could use it in function-like mode.

Am 14.06.2016 um 16:05 schrieb Riccardo (Jack) Lucchetti: > On Tue, 14 Jun 2016, Allin Cottrell wrote: > > >> In general, built-in functions don't print anything, so it would be >> the code that calculates tau and its associated z-value that would >> have to be hooked up; printing would be skipped. >> >> There are two ways we could give access to Kendall's tau and >> Spearman's rho: we could add a third, optional argument to the corr() >> function to select a variant other than Pearson, or we could add a >> --quiet option to the "corr" command and make it store $test and >> $pvalue, so you could use it in function-like mode. > > I'd fabvour the former (third optional argument). I guess I agree. Out of curiosity: What's the list of necessary ingredients in an existing analogous case? For example take the cum() function (just a random pick, maybe there are better examples). What's the underlying function doing the actual calculation, and what's the "glue code" that does the handshake to hansl (checking for matrices or series, handing back the results to the gretl user etc.

On Tue, 14 Jun 2016, Allin Cottrell wrote: > > 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). > > For commands the analogous entry point is again a big switch > statement, but in the function gretl_cmd_exec() in interact.c. In this > case the command identifiers are mostly just upper-case versions of > the command names: OLS, ADF, etc.

Anyway, there is a "Rosetta stone" if you need one: it's lib/src/genlex.c.

available to commands is easy to find by looking at lib/src/options.c.

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.

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 " ...

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.