典型的なPythonのデータフレーム内のインデックス位置

Question

によって、スパースデータフレームの行を選択し、それがインデックスに基づいて、所望の行を選択するのは簡単です：

df.ix[list_of_inds] or df.loc[list_of_inds] 

しかし、大、疎データフレームのかなりの部分集合を取るためにこの方法を使用して（73,000行、具体的には8000列）が非常に集中しているように見える - 私の記憶が撃たれ、コンピュータがクラッシュする。

私はこのような範囲を使用して、そのインデックスに気付かなかった...このようなインデックスのリストを使用している間

df.ix[1:N] 

は、正常に動作します...

df.ix[np.arange(1,N)] 

は、メモリーの過負荷を作るものです。

疎なデータフレームから計算的に簡単な行を選択する別の方法はありますか？それとも、私は

sparse_df = scipy.sparse.csc(df) 

と私はそれからしたいインデックスのみを選択...実際のスパース行列にこのデータフレームに変換することができますか？

Answer 1

あなたが直面している問題は、ビューとコピーのセマンティクスに関連する可能性があります。

df.ix[1:N]    # uses slicing => operates on a view 
df.ix[np.arange(1,N)] # uses fancy indexing => "probably" creates a copy first 

私は形状73000x8000の私のマシン上のデータフレームを作成し、私の記憶は私がクラッシュしても驚かないだろう4.4ギガバイトにスパイクしました。つまり、インデックスリストを使って新しい配列を作成する必要がある場合、あなたは不運です。しかし、元のデータフレームを修正するために、あなたは例えば、速さを犠牲にして時に一度にデータフレーム1行を変更したり、いくつかのスライス行することができるはずです。

for i in arbitrary_list_of_indices: 
    df.ix[i] = new_values 

ところで、あなたが働いて試みることができます私が感じた直接的な数の少ない配列は、どの操作がコピーとビューの結果になるかをより明確に示しています。元の配列への参照を作成するだけなので、メモリオーバーヘッドはほとんどなく、配列からDataFrameを作成できます。

また、numpyでのインデックス作成は、スライスしなくてもはるかに高速です。簡単なテストケースは次のとおりです。

In [66]: df 
Out[66]: 
    0 1 2 3 
0 3 14 5 1 
1 9 19 14 4 
2 5 4 5 5 
3 13 14 4 7 
4 8 12 3 16 
5 15 3 17 12 
6 11 0 12 0 

In [68]: df.ix[[1,3,5]]  # fancy index version 
Out[68]: 
    0 1 2 3 
1 9 19 14 4 
3 13 14 4 7 
5 15 3 17 12 

In [69]: df.ix[1:5:2] # sliced version of the same 
Out[69]: 
    0 1 2 3 
1 9 19 14 4 
3 13 14 4 7 
5 15 3 17 12 

In [71]: %timeit df.ix[[1,3,5]] = -1 # use fancy index version 
1000 loops, best of 3: 251 µs per loop 

In [72]: %timeit df.ix[1:5:2] = -2  # faster sliced version 
10000 loops, best of 3: 157 µs per loop 

In [73]: arr = df.values 
In [74]: arr 
Out[74]: 
array([[ 3, 14, 5, 1], 
     [-2, -2, -2, -2], 
     [ 5, 4, 5, 5], 
     [-2, -2, -2, -2], 
     [ 8, 12, 3, 16], 
     [-2, -2, -2, -2], 
     [11, 0, 12, 0]]) 

In [75]: %timeit arr[[1,3,5]] = -1 # much faster than DataFrame 
The slowest run took 23.49 times longer than the fastest. This could mean that an intermediate result is being cached. 
100000 loops, best of 3: 4.56 µs per loop 

In [77]: %timeit arr[1:5:2] = -3 # really fast but restricted to slicing 
The slowest run took 19.46 times longer than the fastest. This could mean that an intermediate result is being cached. 
1000000 loops, best of 3: 821 ns per loop 

幸運！