使用包含的NA值索引Julia的DataArrays

Question

我想知道为什么不能使用NA值索引Julia的DataArrays.执行下面的剪切会导致错误(NAException("无法使用包含NA值的DataArray索引数组")):

dm = data([1 4 7; 2 5 8; 3 1 9])
dm[dm .== 5] = NA

dm[dm .< 3] = 1  #Error
dm[(!isna(dm)) & (dm .< 3)] = 1  #Working

有一个解决方案可以忽略数据框架中的NA isna(),就像这里回答的那样.乍一看它的工作方式应该如此,忽略DataFrames中的NA是与DataArrays相同的方法,因为DataFr的每一列都是DataArray,在此处说明.但在我看来,忽略!isna()每个条件下的缺失值并不是最好的解决方案.

对我来说,如果包含NA,DataTrame模块会抛出错误的原因尚不清楚.如果索引所需的布尔数组具有NA的值,则此值应转换为false类似MATLAB®或Pythons Pandas 的值.在indexing.jl中的DataArray模块源代码(如下所示)中,有一个显式函数抛出NAException:

# Indexing with NA throws an error
function Base.to_index(A::DataArray)
    any(A.na) && throw(NAException("cannot index an array with a DataArray containing NA values"))
    Base.to_index(A.data)
end

如果您通过将NA设置为false来更改代码段...

# Indexing with NA throws an error
function Base.to_index(A::DataArray)
    A[A.na] = false
    any(A.na) && throw(NAException("cannot index an array with a DataArray containing NA values"))
    Base.to_index(A.data)
end 

...的dm[dm .< 3] = 1工作方式应该如此(如在MATLAB®或Pandas中).

对我来说,如果在索引中包含NA,则自动抛出错误是没有意义的.最低层应该是创建DataArray的参数,让用户选择是否忽略NA.有两个显着的原因:一方面,当你有具有大量索引和NA值的公式(例如计算气象网格模型)时,它不是非常适合编写和阅读代码,另一方面有明显的损失性能,这个时间测试显示:

@timeit dm[(!isna(dm)) & (dm .< 3)] = 1  #14.55 µs per loop  
@timeit dm[dm .< 3] = 1  #754.79 ns per loop

开发人员使用此异常的原因是什么,还有另一种更简单的方法,就是!isna()忽略DataArrays中的NA？

Answer 1

假设你有三只兔子.你想把雌兔放在与雄性不同的笼子里.你看第一只兔子,看起来像男性,所以你把它放在原处.你看第二只兔子,它看起来像一只雌性,所以你将它移到单独的笼子里.你真的不能好好看看第三只兔子.你该怎么办？

这取决于.也许你可以把留下未知性别的兔子抛在身后.但如果你因为你不想让它们制作小兔子而将兔子分开,那么你可能希望你的分析软件告诉你它不知道第三只兔子的性别.

这种情况经常在分析数据时出现.在大多数病理情况下,数据是系统而不是随机丢失的.如果你要调查一群人关于蓬松的兔子是多少以及是否应该多吃,你可以比较mean(fluffiness[should_be_eaten_more])和mean(fluffiness[!should_be_eaten_more]).但是,如果那些真正喜欢兔子的人被激怒,你说的话就是在吃它们,那么他们可能会把第二个问题留空.如果你忽略这一点,你会低估那些不认为兔子应该被吃得更多的人的平均蓬松等级,这将是一个严重的错误.这就是为什么fluffiness[!should_be_eaten_more]如果缺少值会抛出错误:这表明无论您尝试对数据做什么都可能无法给出正确的结果.这种情况非常糟糕,以至于人们会写完整篇论文,例如这篇论文.

足够的兔子.在索引时,有可能(并且可能有一天)更简洁的方式来删除/保留所有缺失值,但由于上述原因,它总是显式的而不是隐式的.就性能而言,虽然isna(x) & (x < 3)vs 的速度有所下降x < 3,但重复索引到数组的开销也很高,而DataArrays会增加额外的开销.随着阵列变大,相对开销减少.如果这是您的代码中的瓶颈,最好的办法是以不同的方式编写代码.