Cons: not composable, makes basic arithmetic slow.
> On Jul 31, 2014, at 11: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,
