Thx,

I would like to use it in cases where a completely different route is viable, if no input is given. With the background of gnuplotting, this is for example to use the autoscale function for one axis (*) if no input for the minimum or maximum (or both) is present.

My current workaround are two functions generating and testing for an unlikely number, which works as NaN code. This I can then use as a default value.

<hansl>

function scalar special_plot_MY_NULL()

    scalar MY_NULL = 987654321.1234

    return MY_NULL

end function

function scalar special_plot_exists(scalar input)

    if !exists(input) #just in case..

        return 0

    endif

    if input == special_plot_MY_NULL()

        return 0

    else

        return 1

    endif

end function

<\hansl>

The other thing: I also (hope) I have a useful workaround now… I just wanted to ask ;).

Best

Frederik

Von: gretl-devel-bounces@lists.wfu.edu [mailto:gretl-devel-bounces@lists.wfu.edu] Im Auftrag von Sven Schreiber
Gesendet: Montag, 8. Januar 2018 17:15
An: gretl-devel@lists.wfu.edu
Betreff: Re: [Gretl-devel] functions optional arguments - numerical (NA equiv. to null), python like syntax (wish)

Am 08.01.2018 um 10:21 schrieb Schaff, Frederik:

Hi there, I pose this question & suggestion here instead the users list, I hope that is fine in this context.

Yes, perfect.

It is currently not possible to use „null“ as a default argument for scalar variables in function headers. It is, however, possible to use „NA“. My question: Is there a save procedure to use “!isnan(variable)” similar to “exists(matrix)” for function headers? Currently, this seems not possible (or I am making a mistake). E.g.:

You're making a mistake :-)
NaN is not the same as NA. You can dig up a bunch of discussions about gretl's creation of NAs in the lists in the past.
But the point for you is that you probably want to use missing() or ok().

Apart from that, I would usually recommend against a NA default value for a scalar. Instead use a "sensible" default that really is something that would be chosen often. Or use some code value; for example if a strictly positive number is expected, the default value 0 can be taken as an equivalent signal to NA. Or of only non-negative numbers make sense, use -1 to signal some special meaning. And so on.

And then one other thing. In Python one can conveniently pass optional arguments via “argument_label=argument_value”, without having to care about the sorting/completeness of the argument list. If such a thing was possible in hansl, that would be very convenient!

Yes it would be, and in many other senses Python is much more flexible than hansl, too. That's why the Python + Numpy + Scipy (+ statsmodels + pandas and so forth) ecosystem is so successful. But having named arguments (as opposed to only positional arguments) is of course not a Python-specific thing. (R also has it, for example.)
Anyway, it would be nice to have, but I'm afraid that it would represent a major internal reorganization effort. (Allin will probably comment on that when he's back online.) Personally I'm happy that the gretl core has stabilized recently, so I have mixed feelings about such a change. But it's a very valid point.

cheers,
sven