11:12 a.m.
Hi,
I discovered what's IMHO a relative severe bug (severe because it can go
unnoticed and would lead to rubbish afterwards):
Missing values are not propagated when multiplying dummy variables. Example:
open greene14_1
series check1 = (Q>100)
series check2 = zeromiss(LF <0.5)
series checkmult = check1*check2
and 'checkmult' should have missings where check2 has them but it doesn't.
I discovered it in a panel context but I haven't tested whether it's
more general than that.
thanks,
sven
1:34 p.m.
On Tue, 13 Apr 2010, Sven Schreiber wrote:
I discovered what's IMHO a relative severe bug (severe because it
can go
unnoticed and would lead to rubbish afterwards):
Missing values are not propagated when multiplying dummy variables. Example:
open greene14_1
series check1 = (Q>100)
series check2 = zeromiss(LF <0.5)
series checkmult = check1*check2
and 'checkmult' should have missings where check2 has them but it doesn't.
That behavior is by design and IMO it's not a bug, since zero
times any value is zero. (This is the one exception we make to the
rule that NAs always propagate to the result, and it's explained
in section 5.7 of the User's Guide, "Handling missing values".)
To get the behavior you were expecting:
checkmult = !ok(check2) ? NA : check1*check2
Allin
2:15 p.m.
On Tue, 13 Apr 2010, Allin Cottrell wrote:
That behavior is by design and IMO it's not a bug, since zero
times any value is zero. (This is the one exception we make to the
rule that NAs always propagate to the result, and it's explained
in section 5.7 of the User's Guide, "Handling missing values".)
FWIW, let me back Allin on this one. The idea that NA*0 should return 0
troubled me in the past, until I realised that setting something to NA is
often a shortcut we use when we really mean 'I don't want this observation
in my sample'. In fact, NA simply stands for 'I don't know what this cell
contains', and when you think about it this way, then NA*0==0 makes
perfect sense.
Example: suppose you have wage data for individuals who may be unemployed.
For those cases, you'd obviously have NA. Now suppose you want to
"interact" wage with a gender dummy (suppose 1==male, 0==female). Clearly,
if you multiply wage by gender (w_male = wage * gender) you'd get
w_male==NA for unemployed men and w_male==0 for unemployed women, which is
counter-intuitive only if you expect things to work if you screen
unemployed people by checking for ok(w_g). The "proper" way to go in this
case would be to define w_male as
w_male = ok(wage) ? wage * gender : NA
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
3:06 p.m.
Riccardo (Jack) Lucchetti schrieb:
On Tue, 13 Apr 2010, Allin Cottrell wrote:
> That behavior is by design and IMO it's not a bug, since zero
> times any value is zero. (This is the one exception we make to the
> rule that NAs always propagate to the result, and it's explained
> in section 5.7 of the User's Guide, "Handling missing values".)
FWIW, let me back Allin on this one. The idea that NA*0 should return 0
troubled me in the past, until I realised that setting something to NA
is often a shortcut we use when we really mean 'I don't want this
observation in my sample'. In fact, NA simply stands for 'I don't know
what this cell contains', and when you think about it this way, then
NA*0==0 makes perfect sense.
Thanks for the explanation. I have two reactions to this:
1) Is this a gretl idiosyncracy? (In the sense of: "do all other
softwares treat missings differently, e.g. similar to floating-point
'NaN' according to things like IEEE standards which AFAIK always
propagate?") Then I think I would be fairly strongly against gretl's
behavior. At least I was quite surprised and according to my intuition
it was clearly a bug. (that's why I didn't check in the manual)
2) I think that Jack's reasoning is partly correct, but not in full
generality: it's *not* always true that na stands for "don't know the
exact number", sometimes it stands for "not applicable", "not a
meaningful (numeric) value", etc. And consider the literal meaning of
"NaN": Not a Number! The expression 0*x == 0 is only true if x *is* a
number, which you simply don't know if you have a missing. (Often it
will indeed be an unknown number, but not always, that's my point.)
So I'm sorry, but I have to say I'm not convinced.
thanks,
sven
3:19 p.m.
On 13-04-2010, at 17:06, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
> On Tue, 13 Apr 2010, Allin Cottrell wrote:
>
>> That behavior is by design and IMO it's not a bug, since zero
>> times any value is zero. (This is the one exception we make to the
>> rule that NAs always propagate to the result, and it's explained
>> in section 5.7 of the User's Guide, "Handling missing values".)
>
> FWIW, let me back Allin on this one. The idea that NA*0 should return 0
> troubled me in the past, until I realised that setting something to NA
> is often a shortcut we use when we really mean 'I don't want this
> observation in my sample'. In fact, NA simply stands for 'I don't know
> what this cell contains', and when you think about it this way, then
> NA*0==0 makes perfect sense.
>
Thanks for the explanation. I have two reactions to this:
1) Is this a gretl idiosyncracy? (In the sense of: "do all other
softwares treat missings differently, e.g. similar to floating-point
'NaN' according to things like IEEE standards which AFAIK always
propagate?") Then I think I would be fairly strongly against gretl's
behavior. At least I was quite surprised and according to my intuition
it was clearly a bug. (that's why I didn't check in the manual)
2) I think that Jack's reasoning is partly correct, but not in full
generality: it's *not* always true that na stands for "don't know the
exact number", sometimes it stands for "not applicable", "not a
meaningful (numeric) value", etc. And consider the literal meaning of
"NaN": Not a Number! The expression 0*x == 0 is only true if x *is* a
number, which you simply don't know if you have a missing. (Often it
will indeed be an unknown number, but not always, that's my point.)
So I'm sorry, but I have to say I'm not convinced.
In R
xna <- NA # Not Available
xnan <- NaN
xpinf <- Inf
xminf <- -Inf
0*xna
[1] NA
0*xnan
[1] NaN
0*xpinf
[1] NaN
0*xminf
[1] NaN
I'm also not convinced.
Berend
3:51 p.m.
On Tue, 13 Apr 2010, Berend Hasselman wrote:
> 2) I think that Jack's reasoning is partly correct, but not
in full
> generality: it's *not* always true that na stands for "don't know the
> exact number", sometimes it stands for "not applicable", "not a
> meaningful (numeric) value", etc. And consider the literal meaning of
> "NaN": Not a Number! The expression 0*x == 0 is only true if x *is* a
> number, which you simply don't know if you have a missing. (Often it
> will indeed be an unknown number, but not always, that's my point.)
>
> So I'm sorry, but I have to say I'm not convinced.
In my view, NA and NaN are two very different things. As you say, NaN*0
== NaN, by the definition of NaN. If you restrict the interpretation of NA
to "unknown numbwer (but still a number)", then NA*0==0 makes sense. Let
me give another example: suppose you have individuals whose income Y may be
missing, and their tax rate R (with no missing). Of course Y*R gives you
the amount due. If Y is NA, but R==0, why should you doubt that the amount
due is 0?
So I think that NA and NaN are fundamentally different, and should be
treated as such; note that we don't do this at present: if you try
series foo = ln(normal())
you get NAs rather NaNs. I accept that behaviour such as this should be
fixed, although not a priority IMO.
In R
xna <- NA # Not Available
xnan <- NaN
xpinf <- Inf
xminf <- -Inf
> 0*xna
[1] NA
> 0*xnan
[1] NaN
> 0*xpinf
[1] NaN
> 0*xminf
[1] NaN
I'm also not convinced.
On the basis of my reasoning above, I consider the first example above
wrong, with due respect to R (and octave).
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
4:25 p.m.
Riccardo (Jack) Lucchetti schrieb:
In my view, NA and NaN are two very different things. As you say,
NaN*0
== NaN, by the definition of NaN. If you restrict the interpretation of
NA to "unknown numbwer (but still a number)", then NA*0==0 makes sense.
I agree!
So I think that NA and NaN are fundamentally different, and should
be
treated as such; note that we don't do this at present
exactly; instead gretl implicitly assumes always NA which is not
justified IMHO
you get NAs rather NaNs. I accept that behaviour such as this should be
fixed, although not a priority IMO.
I certainly won't argue about priorities...
On the basis of my reasoning above, I consider the first example above
wrong, with due respect to R (and octave).
Maybe; although I have to say this could mean to eventually dig further
why octave does it (does Matlab do it? why?). But it's not the main
issue here.
thanks,
sven
4:49 p.m.
On 13-04-2010, at 18:25, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
> In my view, NA and NaN are two very different things. As you say, NaN*0
> == NaN, by the definition of NaN. If you restrict the interpretation of
> NA to "unknown numbwer (but still a number)", then NA*0==0 makes sense.
>
I agree!
I don't.
NA == Not Available.
Assume that it is an unknown number. It could be +Inf or -Inf or even NaN.
Even in a numeric context 0*NA = 0 does not make sense.
I feel that The R and Octave result of NA for 0*NA is perfect reasonable (in a numeric
context).
I prefer it.
In a string context 0*Na, R will give an error message.
Berend
5:13 p.m.
On Tue, 13 Apr 2010, Berend Hasselman wrote:
On 13-04-2010, at 18:25, Sven Schreiber wrote:
> Riccardo (Jack) Lucchetti schrieb:
>
>> In my view, NA and NaN are two very different things. As you say, NaN*0
>> == NaN, by the definition of NaN. If you restrict the interpretation of
>> NA to "unknown numbwer (but still a number)", then NA*0==0 makes
sense.
>>
>
> I agree!
>
I don't.
NA == Not Available.
Assume that it is an unknown number. It could be +Inf or -Inf or even NaN.
Even in a numeric context 0*NA = 0 does not make sense.
No. +Inf, -Inf or NaN are _not_ numbers. As long as x _is_ a number,
0*x==0 is true whatever the value of x (known or otherwise).
I feel that The R and Octave result of NA for 0*NA is perfect
reasonable
(in a numeric context). I prefer it.
Matter of taste.
In a string context 0*Na, R will give an error message.
Irrelevant in the present discussion IMO. Besides, R is not the gospel.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
12:26 a.m.
On Tue, 13 Apr 2010, Riccardo (Jack) Lucchetti wrote:
On Tue, 13 Apr 2010, Berend Hasselman wrote:
> I feel that The R and Octave result of NA for 0*NA is perfect reasonable
> (in a numeric context). I prefer it.
Matter of taste.
Actually, I think it's a bit more than a matter of taste. If a
program evaluates 0*NA as NA I submit that shows that the program
does not implement the concept of "NA" as missing value.
The original source of "true" NAs in econometrics is observations
that were not made, were lost, or are otherwise unavailable. In
that context, as Jack said, "NA" is a place-holder for an unknown
value, but if it's the unknown value of a measurable quantity it
cannot be infinity or "Not a Number" (which is a place-holder for
a mathematical error), and multiplication by zero yields zero for
any such unknown but in principle valid value.
If a program has 0*NA = NA it is treating NAs as if they were
nans, which in general is not correct (though is is convenient for
the coder not to have to make the distinction).
Allin
5:42 a.m.
Sorry for joining late. I think gretl handles missing values rather
well. I am saying this because I have applied the so called Wilkinson
Tests to gretl, which assesses the handling of missing values among
other basic statistical functionality. (The test results are available
here: http://ideas.repec.org/h/ehu/ehucha/01-16.html )
Suppose we have a series called MISS consisting of missing values
series NEW =MISS+1
returns all missing values because we cannot know what happens if 1 is
added to a missing (unknown) number.
series NEW=MISS*0
on the other hand returns zeroes because we know (as Allin mentioned)
the result here.
Similarly
series NEW=MISS/0
returns missing values.
This behavior is, of course, valid when all values are numerical and
finite, which is IMO OK considering our standard methods such as using
dummies etc. Finally, I have to mention that Eviews retuns
MISS*0=MISS.
Cheers
Talha
On Wed, Apr 14, 2010 at 3:26 AM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Tue, 13 Apr 2010, Riccardo (Jack) Lucchetti wrote:
> On Tue, 13 Apr 2010, Berend Hasselman wrote:
> > I feel that The R and Octave result of NA for 0*NA is perfect reasonable
> > (in a numeric context). I prefer it.
>
> Matter of taste.
Actually, I think it's a bit more than a matter of taste. If a
program evaluates 0*NA as NA I submit that shows that the program
does not implement the concept of "NA" as missing value.
The original source of "true" NAs in econometrics is observations
that were not made, were lost, or are otherwise unavailable. In
that context, as Jack said, "NA" is a place-holder for an unknown
value, but if it's the unknown value of a measurable quantity it
cannot be infinity or "Not a Number" (which is a place-holder for
a mathematical error), and multiplication by zero yields zero for
any such unknown but in principle valid value.
If a program has 0*NA = NA it is treating NAs as if they were
nans, which in general is not correct (though is is convenient for
the coder not to have to make the distinction).
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--
12:31 a.m.
On Wed, 14 Apr 2010, Talha Yalta wrote:
Sorry for joining late. I think gretl handles missing values
rather well. I am saying this because I have applied the so
called Wilkinson Tests to gretl, which assesses the handling of
missing values among other basic statistical functionality. (The
test results are available here:
http://ideas.repec.org/h/ehu/ehucha/01-16.html )
Suppose we have a series called MISS consisting of missing
values series NEW =MISS+1 returns all missing values because we
cannot know what happens if 1 is added to a missing (unknown)
number. series NEW=MISS*0 on the other hand returns zeroes
because we know (as Allin mentioned) the result here.
Thanks, Talha. It's nice to get third-party confirmation (via
Wilkinson) that gretl is doing the right thing with 0*missing,
even if we're the only econometrics program to do so (though I
doubt that is the case).
Allin
6:19 p.m.
On Tue, 13 Apr 2010, Riccardo (Jack) Lucchetti wrote:
In my view, NA and NaN are two very different things. As you say,
NaN*0
== NaN, by the definition of NaN. If you restrict the interpretation of NA
to "unknown numbwer (but still a number)", then NA*0==0 makes sense. Let
me give another example: suppose you have individuals whose income Y may be
missing, and their tax rate R (with no missing). Of course Y*R gives you
the amount due. If Y is NA, but R==0, why should you doubt that the amount
due is 0?
So I think that NA and NaN are fundamentally different, and should be
treated as such; note that we don't do this at present: if you try
series foo = ln(normal())
you get NAs rather NaNs. I accept that behaviour such as this should be
fixed, although not a priority IMO.
Good point. I still believe that 0*NA = 0 is fine, so long as NA
(unknown value) and NaN (invalid value) are not conflated. So I
agree we should ensure that the "genr" mechanism does not convert
NaN results to NA.
Strictly, NAs should be confined to values marked as such in
incoming data, values propagated via "genr" on NA input (other
than multiplication by zero), and values marked explicitly by the
user, as in "x[3] = NA" or via "zeromiss()".
Allin
5124
days inactive
5126
days old
13 comments
5 participants
participants (5)
-
Allin Cottrell -
Berend Hasselman -
Riccardo (Jack) Lucchetti -
Sven Schreiber -
Talha Yalta