Currently isfinite(missing)
, isinf(missing)
and isnan(missing)
return missing
, just like most math functions. This makes sense because a missing value could be either finite or infinite if it were observed, and it keeps the number of functions which implement a special behavior for missing values low (ismissing
, isequal
, ===
, plus 3VL logical operators).
OTOH, an argument could be made that these functions are special because they are not standard math operations, but rather technical operations to check for special floating-point values Inf
and NaN
. Viewed that way, it would make sense to have them be consistent with isequal
and not propagate missing values. This is indeed what R does. It could also be more useful in practice, since it's not obvious you'd want to propagate a missing value when checking whether it's finite/NaN: this kind of check would typically be used for control flow.
In doubt, we could remove the methods for missing
for now, which will allow implementing whatever behavior we choose in 1.x releases.
I would stick with a consistent rule and have them return missing
. I think there are various consistent rules (e.g. the Missing
rule is to always propagate missing values, the DataValue
rule is that predicates always return Bool
), and one can make an argument for either one. I think either of those is preferable over a situation where you have a rule with lots and lots of exceptions. Then folks just have to know how each individual function works, which seems cumbersome.
I agree with @davidanthoff that consistency is the best policy here. Once you learn the basic rule, you know how the code has to be written.
yar. Keep It Simply Specified.
OK, that's fine with me, I just wanted to make sure we made a conscious decision.
Most helpful comment
OK, that's fine with me, I just wanted to make sure we made a conscious decision.