我的理解是,这个功能是为了模仿 R 语言的行为,使得迁移 R 脚本更加容易,并且它开始使用
ix
,不过现在已经被弃用。以前有很多种方法来进行切片操作,但是现在我们只剩下以下几种:
- 获取单个元素,即获取一列数据。
- 获取多列数据,即获取一个子数据框。
- 通过布尔索引获取数据。
个人而言,我喜欢对所有的操作都使用
__getitem__
方法:
In [11]: df[['A', 'C']]
Out[11]:
A C
0 1 3
1 1 3
In [12]: df['A']
Out[12]:
0 1
1 1
Name: A, dtype: int64
虽然可选方案更少歧义(loc
(或iloc
)过于冗长:
In [13]: df.loc[:, ['A', 'B']]
Out[13]:
A B
0 1 2
1 1 2
In [14]: df.loc[:, 'A']
Out[14]:
0 1
1 1
Name: A, dtype: int64
值得注意的是,布尔掩码通常不会产生歧义,除非您有一个奇特的示例,其中布尔列和输入长度与数据帧相匹配。
In [21]: df1 = pd.DataFrame({True: [1, 2], False: [3, 4]})
In [22]: df1
Out[22]:
False True
0 3 1
1 4 2
In [23]: df1[[True, False]] # boolean slicing (not as column names)
Out[23]:
False True
0 3 1
历史上,ix
存在潜在的歧义问题(以及性能问题 - 有很多可能的路径可以选择)。因此,除了消除歧义之外,移动到 loc
和 iloc
还导致更快的代码(通常使用 iloc
如果可以的话它是最快的)。
df[...]
通常会尝试将你传递给__getitem__
的任何内容作为列索引器应用,除非你传递了一个布尔掩码。例如,尝试使用df[[0, 1]]
,你就会明白。 - cs95.loc
方法(或.iloc
方法),也是为了优化原因。[]
索引运算符基本上是一种“便利”方法:它旨在让您以最少的字符访问数据值,以满足一些最常见的用例。 - Xukraoiloc
中使用布尔掩码,这种情况下你必须使用另一种方法 :-) - cs95