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