@@ -221,7 +221,7 @@ Label-based indexing with integer axis labels is a thorny topic. It has been
221221discussed heavily on mailing lists and among various members of the scientific
222222Python community. In pandas, our general viewpoint is that labels matter more
223223than integer locations. Therefore, with an integer axis index *only *
224- label-based indexing is possible with the standard tools like ``.ix ``. The
224+ label-based indexing is possible with the standard tools like ``.loc ``. The
225225following code will generate exceptions:
226226
227227.. code-block :: python
@@ -230,7 +230,7 @@ following code will generate exceptions:
230230 s[- 1 ]
231231 df = pd.DataFrame(np.random.randn(5 , 4 ))
232232 df
233- df.ix [- 2 :]
233+ df.loc [- 2 :]
234234
235235 This deliberate decision was made to prevent ambiguities and subtle bugs (many
236236users reported finding bugs when the API change was made to stop "falling back"
@@ -305,15 +305,15 @@ index can be somewhat complicated. For example, the following does not work:
305305
306306::
307307
308- s.ix ['c':'e'+1]
308+ s.loc ['c':'e'+1]
309309
310310A very common use case is to limit a time series to start and end at two
311311specific dates. To enable this, we made the design design to make label-based
312312slicing include both endpoints:
313313
314314.. ipython :: python
315315
316- s.ix [' c' :' e' ]
316+ s.loc [' c' :' e' ]
317317
318318 This is most definitely a "practicality beats purity" sort of thing, but it is
319319something to watch out for if you expect label-based slicing to behave exactly
@@ -322,58 +322,6 @@ in the way that standard Python integer slicing works.
322322Miscellaneous indexing gotchas
323323------------------------------
324324
325- Reindex versus ix gotchas
326- ~~~~~~~~~~~~~~~~~~~~~~~~~
327-
328- Many users will find themselves using the ``ix `` indexing capabilities as a
329- concise means of selecting data from a pandas object:
330-
331- .. ipython :: python
332-
333- df = pd.DataFrame(np.random.randn(6 , 4 ), columns = [' one' , ' two' , ' three' , ' four' ],
334- index = list (' abcdef' ))
335- df
336- df.ix[[' b' , ' c' , ' e' ]]
337-
338- This is, of course, completely equivalent *in this case * to using the
339- ``reindex `` method:
340-
341- .. ipython :: python
342-
343- df.reindex([' b' , ' c' , ' e' ])
344-
345- Some might conclude that ``ix `` and ``reindex `` are 100% equivalent based on
346- this. This is indeed true **except in the case of integer indexing **. For
347- example, the above operation could alternately have been expressed as:
348-
349- .. ipython :: python
350-
351- df.ix[[1 , 2 , 4 ]]
352-
353- If you pass ``[1, 2, 4] `` to ``reindex `` you will get another thing entirely:
354-
355- .. ipython :: python
356-
357- df.reindex([1 , 2 , 4 ])
358-
359- So it's important to remember that ``reindex `` is **strict label indexing
360- only **. This can lead to some potentially surprising results in pathological
361- cases where an index contains, say, both integers and strings:
362-
363- .. ipython :: python
364-
365- s = pd.Series([1 , 2 , 3 ], index = [' a' , 0 , 1 ])
366- s
367- s.ix[[0 , 1 ]]
368- s.reindex([0 , 1 ])
369-
370- Because the index in this case does not contain solely integers, ``ix `` falls
371- back on integer indexing. By contrast, ``reindex `` only looks for the values
372- passed in the index, thus finding the integers ``0 `` and ``1 ``. While it would
373- be possible to insert some logic to check whether a passed sequence is all
374- contained in the index, that logic would exact a very high cost in large data
375- sets.
376-
377325Reindex potentially changes underlying Series dtype
378326~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
379327
0 commit comments