2016-12-19 6 views
7

zacznę z ramki danych jaksort_by zepsute w pandach> = 0.18.0?

print(df) 
        int   float _i 
1     2 2.000000e+00 1 
3     3 3.000000e+00 3 
2     3 4.000000e+00 2 
4 -9223372036854775808 -1.797693e+308 4 
0 -9223372036854775808 1.000000e+00 0 

Jeśli używam sort_values sortować według dwóch kolumn dostanę wyjście można zobaczyć poniżej. Tak więc wydaje się, że sort_values nic nie robi. Jeśli tylko jedna nazwa kolumny działa, a sposób, w jaki go używam działał w poprzednich wersjach pand. Czy są jakieś zmiany w pandach, o których nie wiem?

print(df.sort_values(["int", "float"])) 
        int   float _i 
1     2 2.000000e+00 1 
3     3 3.000000e+00 3 
2     3 4.000000e+00 2 
4 -9223372036854775808 -1.797693e+308 4 
0 -9223372036854775808 1.000000e+00 0 

W pand 0.17.0 uzyskać:

print(df.sort_values(["int", "float"])) 
        int   float _i 
4 -9223372036854775808 -1.797693e+308 4 
0 -9223372036854775808 1.000000e+00 0 
1     2 2.000000e+00 1 
3     3 3.000000e+00 3 
2     3 4.000000e+00 2 
+1

Oprócz tego, najwyraźniej jeśli zamienisz nazwy dwóch kolumn, otrzymasz dwa różne o/ps ('v0.19.1') –

+0

Widzę to również z 0.18.1. –

+1

OK, widzę problem, wygląda na to, że duża ujemna wartość int zrzuca mechanizm sortowania, sortowanie na kolumnie pływającej działa poprawnie i zgodnie z oczekiwaniami – EdChum

Odpowiedz

-1

jestem w stanie uzyskać sortowania chec do wypadku, wywołując rodzaj następująco:

print(df.sort_values(by=["int", "float"], na_position='first')) 

        int   float _i 
3 -9223372036854775808 -1.797693e+308 4 
4 -9223372036854775808 1.000000e+00 0 
0     2 2.000000e+00 1 
1     3 3.000000e+00 3 
2     3 4.000000e+00 2 

Jednak ja nie jestem pewien, dlaczego sortowanie zachowuje się inaczej w obu wersjach. Sprawdziłem kod źródłowy GitHub i nie widziałem żadnych zmian funkcji sort_values ​​między tymi dwiema wersjami. Możliwe, że zmieniło się coś głębszego w kodzie.

Kod, który ma Sortowanie:

2968    if len(by) > 1: 
2968    from pandas.core.groupby import _lexsort_indexer 
2969  
2970    def trans(v): 
2971     if com.needs_i8_conversion(v): 
2972      return v.view('i8') 
2973     return v 
2974    keys = [] 
2975    for x in by: 
2976     k = self[x].values 
2977     if k.ndim == 2: 
2978      raise ValueError('Cannot sort by duplicate column %s' % str(x)) 
2979     keys.append(trans(k)) 
2980    indexer = _lexsort_indexer(keys, orders=ascending, 
2981           na_position=na_position) 
2982    indexer = com._ensure_platform_int(indexer) 

3004  new_data = self._data.take(indexer, axis=self._get_block_manager_axis(axis), 
3005          convert=False, verify=False) 

Coś z _lexsort_indexer() lub self._data.take() mogły ulec zmianie.

+0

Zrobiłem już poprawkę na pandy. Z pewnych powodów wartość 9223372036854775808, która jest najmniejszą 64-bitową wartością int jest/była traktowana jako "wartość brakująca". Zakładam, że zostało to zrobione podczas implementowania datetimepe datetime64, gdzie ta określona wartość jest oficjalnie nazywana "NaT" (nie czas), podobnie jak "NaN" dla float. – rocksportrocker

+0

Oto poprawka: https://github.com/pandas-dev/pandas/commit/6bea8275e504a594ac4fee71b5c941fb520c8b1a – rocksportrocker

+0

Jesteś szybki! Dziękuję Ci! –

Powiązane problemy