Już pisałem, że same obliczenia zwykle zajmują 10-15% czasu. Z pozostałych 85-90% większość trzeba przezanczyć na sprawdzenie i przekształcanie danych. Dziś przestawię jak efektywnie przeszktałcać dane w Python (będzie też trochę o R). Wyobrażmy sobie, że mamy tabelę (ramkę danych) z codziennymi wydatkami, np.:
| KATEGORIA | CENA | ILOSC | WART |
| Żywność | 1,5 | 2 | 3 |
| Rozrywka | 24 | 1 | 24 |
| Żywność | 4 | 5 | 20 |
| Ubrania | 99 | 1 | 99 |
| Ubrania | 25 | 2 | 50 |
| Żywność | 3 | 1 | 3 |
| Żywność | 0,5 | 40 | 20 |
| Rozrywka | 7,5 | 3 | 22,5 |
| Żywność | 14,99 | 3 | 44,97 |
| Rozrywka | 50 | 1 | 50 |
Naturalnym problemem analitycznym jest policzenie sumy wydaktów dla każdej kategorii. Wydawać się może, że osiągniemy to przy pomocy pętli, coś w rodzaju:
Następnie to samo to dla kategorii "Ubrania" i "Rozrywka". Takie rozwiązanie zadziała i otrzymany prawidłowy wyniki (90,97), ale można lepiej (bardziej zwięzły zapis i znacznie krótszy czas niezbędny do obliczenia). Takie operacje na danych to standardowa operacja agregująca ("GROUP BY" w SQL), standardowo zaimplementowana w bazach danych np. SQL, ale także w Python (Pandas) i R (data.table albo dplyr).
W takiej operacji podajemy zmienną grupującą (czyli zmienną, która rozróżnia podgrupy, tu: KATEGORIA) i operacje jakie chcemy wykonać w każdej z podgrup (tu: suma zmiennej WART). Oczywiście potencjalny wachlarz zastosować to nie tylko suma, równie często korzystamy ze średniej i liczby wystąpień ("COUNT" w SQL) albo liczby unikalnych wartości danej zmiennej ("COUNT DISTINCT").
W bazie danych z niewiadonych przyczyn "pojawiły się" braki obseracji. Skonstruowałem indykator (zmienną zerojedynkową) dla braku danych i okazało się, że udział braków danych sięga ok. 40%. Przyjrzyjmy się temu bliżej - policzyłem udział braków danych wg miejscowości, wyniki są takie:
| Zgierz | 0 |
| Łódź | 1 |
| Ostrołęka | 1 |
| Warszawa | 0 |
| Radomsko | 0 |
| Pabianice | 0 |
| Piotrków Tryb. | 1 |
| Tomaszów Maz. | 1 |
| Kalisz | 0 |
Widzicie to co ja? Braki obserwacji są tylko dla tych miejscowości, które mają "polskie litery". To pokazało, gdzie tkwi problem - różne kodowanie polskich znaków w różnych plikach (baza powstawała poprzez łączenie różnych zbiorów danych). Teraz rozwiązanie problemu zajęło mniej niż 5 minut.
Okazuje się, że implementacja przedstawionych wyżej operacji jest bardzo prosta i przyjemna, zarówno w Python jak i R. Przy okazji tych przykładów podaję odpowiedniki komend dla zapytań SQL -- przyda się tym, którzy znają choćby podstawy SQL albo gdy chcecie wyjaśnić sens jakieś operacji "czystemu" programiście.
Poniżej kody, przy założeniu że mamy w pamięci ramkę danych o nazwie DF, zawierającą zmienne Kategoria i Wartosc.