On Tue, 14 Jun 2016, Sven Schreiber wrote:
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.
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).
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.
Allin