I think you're underestimating the difficulty of employing sentinel values. For example, what would be the sentinel values for basic types like Sets and Dicts?
No one disagrees with your assertion that, given sentinel values, you can easily define isna in terms of a containment check. This is the easy part of defining sentinel values. The hard part is deciding which values you’re going to use to define the vector MySentinelValues for every type. — John On Jul 31, 2014, at 8:40 PM, Diego Javier Zea <[email protected]> wrote: > I like the Sentinel value approach (but maybe because I don't know nothing > about the Cons) > > Pros > Type-stable > Imposes no indirection > Directly use machine ops > No additional memory requirements > NaN already implements NA-like semantics > Existing functions like + behave correctly > > Cons > Requires a sentinel value for every new type > In Julia is very easy to define by defining: > isna(x::MyType, MySentinelValues::Vector{MyType} ) = x in MySentinelValues > isna(x::MyType, MySentinelValue::MyType ) = x == MySentinelValue > isna(x::MyType) = isna( x , MySentinelValue ) > Potential binary incompatibility with other systems > I don't know about it. Are there problems in R because of this? What is the > PANDAS approach to NA's? Is there some kind of general agreement? > Vulnerable to compiler optimizations > I dont't know about it... Can we workin on that? > NaN + NA != NA + NaN in some R builds > Is there any way to prevent it? > Discards a potentially useful value > Is this a big problem? Is NaN doing the same, isn't it ? > > Best,
