Re: [Gretl-devel] bug with missings, dummies (and panel?)

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.

0*xna

0*xnan

0*xpinf

0*xminf