→ gmccntzx1: 簡單來說, `df.loc["Store 1"]["Cost"]` 會透過 2 次 12/04 21:26
→ gmccntzx1: __getitem__ 來取值,後面行為的開始執行時取決於前面 12/04 21:28
→ gmccntzx1: 行為的完成時機。 12/04 21:28
→ gmccntzx1: 若資料可以允許寫成 `df.loc[:, ('Store 1', 'cost')]` 12/04 21:30
→ gmccntzx1: 則 pandas 可以一次根據後面的參數取值,相對來說較快 12/04 21:31
感謝gmccntzxl前輩的分享,
我剛剛研究了一下,我的理解大致上是這樣:
chain indexing容易出現問題的狀況是在賦值時,
兩個中括號放在一起時,
第一個中括號的工作(取值)
但是取值後返回的不一定是view或是copy(依照內存狀況不一定)
所以當在處理第二的中括號(賦值)時,
若第一個返回的是copy就有可能會產生SettingWithCopy
這也是為什麼chain indexing這麼不穩定的原因
不知道我這樣的理解是否正確?
※ 編輯: sssh (1.163.71.122), 12/04/2018 23:49:08
推 gmccntzx1: 關於回傳值是 view 還是 copy ,基本上可以照著 12/05 00:48
→ gmccntzx1: stackoverflow 那篇回答的規則去判斷。 12/05 00:49
→ gmccntzx1: 要了解的更詳細的話,推薦你直接去追 source code: 12/05 00:51
→ gmccntzx1: 裡面有寫到好幾種狀況,比較值得注意的地方有 12/05 00:53
→ gmccntzx1: 修正一下:上面的 generic 應該是 generic.NDFrame 12/05 01:01
→ gmccntzx1: 所以說,用 chain indexing 問題在於一般情況下不容易 12/05 01:03
→ gmccntzx1: 判斷出取的值到底是 view 還是 copy (不了解如 12/05 01:04
→ gmccntzx1: stackoverflow 那篇回答所說的規則),而非資料在記憶 12/05 01:06
→ gmccntzx1: 體中的情況差異所影響。 12/05 01:07
→ gmccntzx1: 而因為會影響取值結果是 view/copy 的情況很多種,所以 12/05 01:11
→ gmccntzx1: 官方還是建議少用 chain indexing。 12/05 01:14
推 TitanEric: 推優文 12/05 10:12
→ sssh: 感謝gmccntzxl的分享 12/05 10:32
推 Angesi: df.loc["Store 1","Cost"] 指定位置讀 應該最簡單 12/06 17:05
→ Angesi: 用chain index 實在有點奇怪 12/06 17:05
→ Angesi: 或者 隱含索引 df.iloc[0, 0] 也行 12/06 17:19