8:48 p.m.
Two new things in CVS that I think should be
uncontroversial, but please let me know if any
breakage results:
* Up till now it has been impossible to give a scalar
parameter to a user-defined function a default value of
NA. This is partly because NA was used as the internal
representation for "no value set". However, it seemed
to me that in some cases it may be useful to set a
default of NA for a trailing parameter, meaning that
if the user omits a value for that parameter, it
should then be ignored (not used) within the function.
This is now possible, but note, only for parameters
of type "scalar", not "bool" or "int".
* Evaluation of boolean "&&" and "||": up till now
we have evaluated both sides of these booleans
before creating the result. But evaluation of the
right-hand branch is redundant if (a) the operator
is && and the left is FALSE, or (b) the operator
is || and the left is TRUE. Now we skip evaluation
on the right when it's redundant. Besides being
more efficient this fixes a problem with NAs.
Let the scalars x = 2, y = NA. Before the change
if x > 1 || y > 10
would produce an error, since "y > 10" can't be
evaluated. Now it works OK.
Allin
7:44 a.m.
Am 21.07.2011 22:48, schrieb Allin Cottrell:
Two new things in CVS that I think should be
uncontroversial, but please let me know if any
breakage results:
* Up till now it has been impossible to give a scalar
parameter to a user-defined function a default value of
NA. This is partly because NA was used as the internal
representation for "no value set". However, it seemed
to me that in some cases it may be useful to set a
default of NA for a trailing parameter, meaning that
if the user omits a value for that parameter, it
should then be ignored (not used) within the function.
This is now possible, but note, only for parameters
of type "scalar", not "bool" or "int".
It's nice to be able to omit parameters in function calls when they are
redundant. However, this would seem to apply to all types of arguments.
I somehow would prefer a coherent solution to this instead of a
case-by-case approach (which is hard to remember).
just imho of course,
sven
5:02 p.m.
On Fri, 22 Jul 2011, Sven Schreiber wrote:
Am 21.07.2011 22:48, schrieb Allin Cottrell:
> Two new things in CVS that I think should be
> uncontroversial, but please let me know if any
> breakage results:
>
> * Up till now it has been impossible to give a scalar
> parameter to a user-defined function a default value of
> NA. This is partly because NA was used as the internal
> representation for "no value set". However, it seemed
> to me that in some cases it may be useful to set a
> default of NA for a trailing parameter, meaning that
> if the user omits a value for that parameter, it
> should then be ignored (not used) within the function.
>
> This is now possible, but note, only for parameters
> of type "scalar", not "bool" or "int".
It's nice to be able to omit parameters in function calls when they are
redundant. However, this would seem to apply to all types of arguments.
I somehow would prefer a coherent solution to this instead of a
case-by-case approach (which is hard to remember).
I'm not sure what you have in mind. The way I see it, the
suitable form of a "don't care" default for a given trailing
parameter depends on its type. "null" is fine for pointer
types but otherwise does not make sense (at least for people
who tend to think in C). For booleans, the only sane default
would be 1 or 0; and so on.
In the end, it's up to the function writer to handle the
arguments received, and the writer has the discretion to set a
default that will be interpreted inside the function as "don't
bother with this", where applicable. For example, with an
optional parameter whose valid values are non-negative ints, a
default of -1 could be used.
I was just trying to fill a gap, in that without the ability
to set NA as the default for a scalar parameter whose valid
values (in principle) span the real line, there was no clean
way to do what I wanted, namely set a default that could be
read as "Not applicable" inside my function.
I should perhaps state briefly for the record how the optional
argument business goes. When call to a user function is set
up, we check the arguments supplied against the parameter
list, for type and number. If the number of arguments is short
of the number of parameters, we see if all the trailing
parameters have default values recorded. If so, the arguments
are set to their defaults, otherwise an error is flagged.
Allin
8:44 p.m.
Am 30.07.2011 19:02, schrieb Allin Cottrell:
On Fri, 22 Jul 2011, Sven Schreiber wrote:
> Am 21.07.2011 22:48, schrieb Allin Cottrell:
>> Two new things in CVS that I think should be
>> uncontroversial, but please let me know if any
>> breakage results:
>>
>> * Up till now it has been impossible to give a scalar
>> parameter to a user-defined function a default value of
>> NA. This is partly because NA was used as the internal
>> representation for "no value set". However, it seemed
>> to me that in some cases it may be useful to set a
>> default of NA for a trailing parameter, meaning that
>> if the user omits a value for that parameter, it
>> should then be ignored (not used) within the function.
>>
>> This is now possible, but note, only for parameters
>> of type "scalar", not "bool" or "int".
>
> It's nice to be able to omit parameters in function calls when they are
> redundant. However, this would seem to apply to all types of arguments.
> I somehow would prefer a coherent solution to this instead of a
> case-by-case approach (which is hard to remember).
I'm not sure what you have in mind. The way I see it, the suitable form
of a "don't care" default for a given trailing parameter depends on its
type. "null" is fine for pointer types but otherwise does not make sense
(at least for people who tend to think in C). For booleans, the only
sane default would be 1 or 0; and so on.
That's something *I* don't understand. NA is not a real-valued number
either, I don't see why this is any different from allowing ints or
booleans to take that special value. As you say, a default of NA for
generic scalars just means "don't care". Why can't NA also mean
"don't
care" for a boolean (or int) argument?
I suspect that internally you map NA to NaN which is handled in the
underlying floating-point logic. And that would perhaps not be so easy
to achieve with internal integers. If that is so, it's a valid technical
reason, but not one that concerns the user side and the way it
necessarily should be done if it were easy, IMHO.
In the end, it's up to the function writer to handle the arguments
received, and the writer has the discretion to set a default that will
be interpreted inside the function as "don't bother with this", where
applicable. For example, with an optional parameter whose valid values
are non-negative ints, a default of -1 could be used.
Sure; also one could work around it by employing a gretl scalar to be
able to set it to NA, even if actually valid values are only
non-negative ints (which would then have to be checked by the function
writer). Actually I guess this is what will happen which would be
slightly counterproductive.
I was just trying to fill a gap, in that without the ability to set NA
as the default for a scalar parameter whose valid values (in principle)
span the real line, there was no clean way to do what I wanted, namely
set a default that could be read as "Not applicable" inside my function.
Your work on filling that gap is much appreciated! But I still argue
that the same things apply to ints and booleans; your argument above
rests on the special case where negative ints are not meaningful per se,
but that is an ad hoc assumption. In general any integer value could be
meaningful, and thus in general you cannot designate any particular
value as conveying the "don't care" signal. And the same goes (even more
forcefully) for the two possible values of booleans.
I should perhaps state briefly for the record how the optional argument
business goes. When call to a user function is set up, we check the
arguments supplied against the parameter list, for type and number. If
the number of arguments is short of the number of parameters, we see if
all the trailing parameters have default values recorded. If so, the
arguments are set to their defaults, otherwise an error is flagged.
Right (in the British sense :-)
cheers,
sven
8:59 a.m.
On Sat, 30 Jul 2011, Allin Cottrell wrote:
On Fri, 22 Jul 2011, Sven Schreiber wrote:
>
> It's nice to be able to omit parameters in function calls when they are
> redundant. However, this would seem to apply to all types of arguments.
> I somehow would prefer a coherent solution to this instead of a
> case-by-case approach (which is hard to remember).
I'm not sure what you have in mind. The way I see it, the
suitable form of a "don't care" default for a given trailing
parameter depends on its type. "null" is fine for pointer
types but otherwise does not make sense (at least for people
who tend to think in C). For booleans, the only sane default
would be 1 or 0; and so on.
In the end, it's up to the function writer to handle the
arguments received, and the writer has the discretion to set a
default that will be interpreted inside the function as "don't
bother with this", where applicable. For example, with an
optional parameter whose valid values are non-negative ints, a
default of -1 could be used.
It happened to me several times in the past to long for a mechanism for
dealing with optional parameters like the one R has. For those unfamiliar
with R: when you call a function, you can specify in the function call a
non-default value only for the arguments you need, as in "foo(b=3)" or
"foo(a=2, b=3)". I think this is very smooth and elegant. When you write
functions that have to take lots of arguments, the C-like convention we
have (which is actually more lenient than C, in which you don't have
defaults at all) may be awkward. However, IMO this small difficulty can be
circumented very easily if you use bundles: instead of defining a function
with 12 parameters, just define it as a function of a bundle which
contains them, and then handle the unpacking (which is very economical,
CPU-wise) inside the function itself. In my experience, this also leads
you to writing much cleaner code.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
4892
days inactive
4902
days old
4 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber