John, how might this interact with DataArrays? This design, unlike
DataArrays, requires that you use an entire byte to store the missingness,
so it's not likely to be as fast if you're manipulating a lot of them. Is
the intended use case here something sum(DataArray) yields Option{Float64}?On Thu, Jul 31, 2014 at 11:01 AM, Stefan Karpinski <[email protected]> wrote: > This looks quite promising. The `get` interface looks like a very nice way > to generically deal with missing values – provide a default or get an > error. Automatic conversion of the default to the type of the Option value > is particularly nice. This seems like it will be a pleasant and efficient > API. > > Minor question: how come the non-NA constructor for Option takes both the > `na` and `value` arguments? Doesn't supplying a value imply that it's not > NA while not supplying a value implies that it is NA? > > > On Thursday, July 31, 2014, John Myles White <[email protected]> > wrote: > >> At JuliaCon, I described the idea of using Option types instead of NAtype >> to make it easier to write type-stable code that interacts with NA’s. To >> help facilitate a debate about the utility of this approach, I just wrote >> up a minimal package that implements Option types: >> https://github.com/johnmyleswhite/OptionTypes.jl >> >> Essentially, an Option type is a scalar version of a DataArray: it >> contains a value and a Boolean mask indicating whether that value is NA or >> not. Because Option types are parametric, they allow us to express the >> variants of NA that R has, such as a Float64 specific NA and an Int64 >> specific NA. >> >> — John >> >>
