Adatbányászat Blog

Az Adatbányász Blogon a dmlab szakértőinek írásait olvashatod a big data és data science területéről.

dmlab.hu - Big data és data science tanácsadás
"Ha örülsz, hogy fejedre nőttek az adatok."

Keress minket bátran:
- Nagy-Rácz István +36704595669
- Gáspár Csaba +36208234154
- info@dmlab.hu

Hírlevél

Iratkozz fel hírlevelünkre, hogy mindig naprakészen tudjunk tájékoztatni.
Feliratkozás
Leiratkozás

Címkék

2007 (1) 2010 (23) 2011 (27) 2012 (13) 2013 (23) 2014 (5) 2015 (6) 2016 (10) 2017 (2) adaptív (1) adat- és médiainformatika (1) adatárusítás (1) adatbányászat (10) adatbányászati algoritmusok (1) adatbányászati alkalmazások (2) adatbányászati meetup (1) adatbányászati oktatás (1) adatbányászati technológiák (4) adatelemzés (1) adatelemzési platformok (1) adattárház (5) adattárház fórum (6) adattárolás (1) adattisztítás (1) adatvédelem (2) advise (2) aegon (1) aglitás (1) agy (2) ajánló (11) ajánlórendszerek (1) aktivitás felismerés (1) algoritmus (1) alkalmazás (3) állásajánlat (1) amazon ec2 (1) ambiens (1) ami (1) analitika (1) analytics (1) andego (3) apache (1) api (2) Arató Bence (3) bank (1) barabási (2) Barabási (2) beharangazó (1) beharangozó (18) bejelentés (2) belami (1) best practice (9) beszámoló (14) BI (3) bi (13) Bi (1) bi-trek (1) biconsulting (7) bigdata (21) Big Data (2) big data (5) biopen (1) biztosító (1) BI Akadémia (1) bi consulting (1) bi start (1) blog (5) BME (14) bme (1) bootcamp (1) brainstorming (1) bsp (1) budapest (1) business analytics (1) business analytics szakirány (1) churn (2) ci (1) címkefelhő (2) CIO (1) clementine (1) Clementine Consulting (1) cloud computing (2) cognos (1) credit scoring (1) crisp-dm (1) crm (2) csalásdetektálás (1) DataExpert (1) dataexplorer (1) datapest (1) data mining (1) data science (5) diplomamunka (1) dmlab (11) döntési fák (1) drill (1) e-commerce (1) előadás (21) előrejelzés (1) élő közvetítés (1) Enbrite.ly (1) energetika (1) esemény (2) esettanulmány (3) etikus (1) etl (2) évforduló (2) fejlesztés (2) felmérés (5) felsőoktatás (1) felület (1) felvásárlás (3) film (1) fizetés (1) forecasting (1) forgalomelőrejelzés (2) foursquare (1) fraud detection (1) freebase (1) gartner (2) gazdasagi informatikus (2) gépi tanulás (4) google (8) google analytics (1) graphlab (1) gravity (3) greenplum (1) gyakorlat (1) hadoop (10) hallgatók (2) hálózatelemzés (3) hálózatkutatás (2) hálózatok (3) hazai (2) hiba (4) hírlevél (2) hive (1) honlap (1) HR (1) HVG (1) i5 (1) ibm (6) ibm modeler (1) ibm spss (3) icdm (1) idc (2) idősor (1) idősorok (1) ieee (1) iir (1) infobright (1) információbróker (1) innováció (5) innovatívBI (1) innovativ bi (4) inspiráció (1) intelligencia (2) Internet Hungary (1) iqsymposium (19) iqsys (16) iroda (4) jelentkezés (1) jmp (2) kaggle (2) kampánymenedzsment (1) kapcsolati hálók (1) karrier (1) kdd (3) kdnuggets (2) képzés (4) kérdés (1) kérdőív (1) kerekasztal (1) keresés (1) kereső (1) keresztvalidáció (4) klaszterezés (2) knime (1) kockázati tőke (1) kollaboratív munka (1) kompetencia (1) konferencia (70) könyv (6) környezet (1) közlekedés (1) közösség (2) közösségi hálózatok (4) közvetítés (6) kritika (1) küldetés (1) kürt akadémia (1) kutatás (2) lemorzsolódás (1) licensz (1) live (1) logisztika (1) magyar telekom (2) mahout (1) mapreduce (1) marketplace (1) média (2) meetup (11) mellékspecializáció (1) mém (3) memóriacentrikus (1) menedzsment (3) metaadat (1) metodika (1) microsoft (1) mobil (5) mobil bi (4) modeler (2) modell (3) morgan stanley (1) motion chart (1) munkaerő (1) mysql (1) mytraffic (4) nemzetközi (5) nemzetközi összehasonlítás (1) netflix prize (1) networking (1) next big thing (1) nips (1) nosql (1) nyílt forráskód (4) nyomkövetés (1) offline áruházak (1) okostelefon (1) oktatás (22) olvasók (1) online áruházak (1) online kutatás (1) open source (19) open source bi (3) operatorfa (1) osbi (12) összehasonlítás (1) ötletek (2) pandas (2) paradoxon (1) pascal (1) pentaho (1) personal data mining (1) phd (2) philips (1) piac (3) pikk (1) pilot (1) PISA-felmérés (1) pmml (1) politika (2) powerpivot (1) prága (1) praktiker (1) prediktív analitika (2) prediktív analitka (1) prediktiv modellezés (5) prediktív modellezés (1) prezi (15) privacy (1) privacy preserving data mining (1) projekt (1) projektmenedzsment (4) publikáció (1) python (9) radoop (12) random forest (1) rapid-i (2) rapidanalytics (7) RapidMiner (2) rapidminer (40) rcomm (7) refine (1) Rexer Analytics (1) rsctc (1) R nyelv (7) saas (1) sap (1) SAS (20) sas enterprise miner (2) sas enterpris guide (1) sas entprise miner (1) sas fórum (1) sas forum (3) siker (3) simptech (1) sixtep (2) smarthabits (1) spike sorting (1) sportanalitika (1) SPSS (3) spss (13) spss clementine (3) spss hungary (5) spss modeler (6) ssd (1) starschema (2) startup (9) statisztika (1) survey (1) svm (1) szabad szoftver (1) szakmai (1) szavazó eljárások (2) szélenergia (1) szélerőmű (1) szervezetfejlesztés (1) szociális hálók (1) szoftver (5) szöveg (1) szövegbányászat (2) sztaki (2) tableau (1) talend (2) támogatás (1) tanulmány (1) tanulság (1) távolság (1) technológia (1) tedx (1) telekommunikáció (2) teradata (2) teszt (1) text mining (1) tmit (5) toborzás (1) tőzsdei előrejelzés (1) tracking (1) trendek (8) tudományos (1) tunedit (1) twitter (17) ügyfél (1) üzleti intelligencia (3) üzleti modell (3) üzleti reggeli (3) validáció (4) válogatás (1) válság (1) változás (1) vélemény (1) véleméy (1) verseny (20) vezetői képzés (1) videó (3) vizualizáció (5) web (4) web2 (2) webanalitika (3) webshop (1) weka (2) wikipedia (2) workshop (1) yahoo (2) Címkefelhő

TWitter a csapat tagjaitól

2015.07.29. 10:00 Ragány Csaba

Python - A pandas szépségei (3. rész)


Ez a bejegyzés az egy héttel ezelőtti Python - A pandas szépségei (2. rész) poszt folytatása illetve egyben a sorozat lezárása. Túl sok felvezető szöveget itt sem szeretnék, úgyhogy íme a befejező epizód:


A dataframe oszlopai és indexei

A már többször is említett .reset_index() függvénnyel kapcsolatban megjegyzendő, hogy egyrészt ha nem az aktuális index normál attribútummá konvertálása a cél, hanem új indexek (sorszámozás) generálása, akkor használhatjuk a függvény belsejében a drop=True opciót, így automatikusan törlődik az aktuális index, vagyis nem kerül be a dataframe oszlopai közé. Másrészt pedig célszerűen (kötelezően-kényszerűen) a .reset_index() függvényt mindig követi egy .rename() függvény, ahol a létrejövő ‘index’ elnevezésű oszlopot átnevezzük valami értelmesebbre. (Kényelmesebb lenne, ha a .reset_index() függvény paramétereként megadható lenne a létrejövő oszlop neve, de egyelőre ez nem lehetséges.) Ha ezt nem tesszük meg, akkor egyrészt a következő .reset_index() hívás által létrejövő oszlop neve ‘level_0’ (illetve ‘level_1’ stb.) lesz, ami zavaró lehet, másrészt viszont az ‘index’ szó az egy foglalt név, így később bonyodalmakat okozhat. Ugyanez a helyzet pl. a ‘from’ kifejezéssel is, ezért is használtuk a bemeneti CSV beolvasásakor az első oszlop nevénél a ‘from_node_id’ elnevezést a sima ‘from’ helyett. És mikor okozhatnak ezek gondot? Fentebb már említettem, hogy egy dataframe esetében új oszlop létrehozása megoldható egy df['new_attr']=<valami> típusú kódsorral, aminek egy ekvivalens alakja a df.new_attr=<valami> kódsor. Magyarán a dataframe oszlopai, mint ahogy állandóan hivatkozunk is rájuk, elérhetők az objektum attribútumaiként, már amennyiben normális, szóköz és egyéb sallang karakterek nélküli oszlopneveink vannak. No és mi a helyzet, ha van egy ‘index’ nevű oszlopunk, mit fog adni a print df.index sor? Hát természetesen nem az ‘index’ oszlop tartalmát, hanem a dataframe (sor) indexének a tartalmát. Hierarchikus indexeknél a szintek egymást követve adják a kívánt oszlopot, vagyis a df.level_0_attr_1.level_1_attr_1 kóddal érhető el egy attribútum, de sajnos itt nem működik az új oszlopok ilyen formában való létrehozása (ez azért elég “fura”). Tehát többszintű oszlopindexek esetén marad a hagyományos mód új attribútum generálására: df[('level_0_new_attr_1','level_1_new_attr_1')]=<valami>.

Egyébként, ha szükségünk lenne egy dataframe indexének vagy oszlopneveinek az értékeire, az alábbi kódokkal megkaphatjuk azokat egy-egy listában: df.index.values ill. df.columns.values. Ha magára az index objektumokra van szükségünk, akkor a korábban már említett df.index és df.columns kódsorokat használjuk. A megfogalmazás nem véletlen, egy dataframe objektum ugyanis egy-egy sor- illetve oszlopindex objektummal rendelkezik, melyek típusa alapesetben, vagyis egyszintű indexek esetén ‘Index’ (illetve ennek módozatai numerikus vagy dátum típusú indexek esetén: ‘Int64Index’ ill. ‘DatateimIndex’). Többszintű indexek vagy oszlopnevek jelenlétekor a df.index.values vagy df.columns.values kódsorokkal visszakapott lista tuple-ket tartalmaz, ahol egy-egy n-es elemszáma az adott index hierarchia szintje szerint alakul, magának az index objektumoknak a típusa pedig már ‘MultiIndex’. Ha esetleg egyszintű fejlécek helyett kétszintűeket szeretnénk egy dataframe-ben, akkor az alábbi kóddal alakíthatjuk át pl. az oszlopindexeket: df.columns=pd.MultiIndex.from_tuples(multi_index), ahol a ‘multi_index’ változó egy pontosan annyi elemet tartalmazó lista, mint ahány oszlopa a dataframe-nek van, és minden listaelem egy tuple, pl. ('level_0_attr_1','level_1_attr_1'). Vegyük észre, hogy itt nem a dataframe objektumot, hanem annak oszlopindex objektumát módosítottuk. Ugyanez az átalakítás a .rename() függvénnyel is működik, a dataframe objektumra (!): df.rename(columns={‘attr_1’:('level_0_attr_1','level_1_attr_1')}, inplace=True).

És ezen a ponton visszatérnék a korábbi elvarratlan szállra, vagyis arra, hogy mi a helyzet akkor, amikor a .groupby() illetve .agg() metódusnál egy attribútumra több aggregációt is végrehajtunk: ekkor sajnos többszintű indexelést kap a kimeneti dataframe, és ennek paraméterben való módosítására illetve beállítására (jelenleg) nincs lehetőség (pl. a .join() esetén megadhatók eltérő oszlopnév-végződések az azonos oszlopnevekre, miáltal egyszintű fejlécekben is megférnek az összekapcsolt dataframe-ek oszlopai). A még nagyobb probléma, hogy a .rename() függvény sem képes elvégezni a visszafelé konverziót, vagyis míg ‘Index’ típusú oszlopindexről működik az átnevezés ‘MultiIndex’ típusúra, fordítva már nem. A  df.rename(columns={('level_0_attr_1','level_1_attr_1'):'attr_1'},inplace=True) kódsorra ugyan hibaüzenetet nem kapunk, ellenben nem is történik semmi változás a fejléceket illetően. A kívánt átnevezéshez tehát már nem elegendő a dataframe elérése illetve módosítása, hanem közvetlenül az oszlopindex objektumnak a megváltoztatása szükséges. Pl. a df.columns=df.columns.droplevel(1) kóddal az első szintű fejléc törölhető a dataframe-ből, miáltal kétszintű indexek esetén a fejléc típusa újra ‘Index’ típusú lesz (pl. három szintű indexeknél természetesen még nem), és így már alkalmazható a szokásos .rename() függvény. Persze vigyázni kell a hierarchia szint törlésével keletkező azonos nevű oszlopokkal, hiszen átnevezéskor az azonos nevű attribútumok mindegyike ugyanazon új értéket kapja. Ilyen esetben célszerű még a hierarchia szint törlése előtt egyedi névvel ellátni az oszlopokat, minden szinten.

Megjegyzendő még, hogy egy dataframe oszlopainak átnevezése az alábbi kóddal is megoldható: df.columns=[új oszlopnevek listája]. Itt fontos, hogy a lista elemszáma megegyezzen az oszlopok számával. Ha az oszlopok sorrendjét akarjuk megváltoztatni, akkor nem az oszlopindex objektumot, hanem a dataframe-et kell módosítanunk, szintén egy lista segítségével: df=df[új oszlopsorrend lista]. Ennek a listának az elemszáma már lehet kevesebb, mint a dataframe oszlopainak a száma, de több nem, illetve csak olyan értékeket tartalmazhat, mint ami az oszlopok neve. Így akár el is hagyhatók bizonyos attribútumok, melyek neve nem szerepel ebben a listában. Ugyanez, vagyis a fentiek egésze igaz az indexekre is, tehát átnevezhetők a sorindexek a df.index=[új sorindexek listája] kódsorral, de a df.rename(index={'0. sor régi névű':'0. sor új név',...}) utasítással is. Ha csak egy vagy néhány sort szeretnénk átnevezni, akkor a .rename(index={}) szótárában csak ezek az elemek szerepeljenek, vagy a df.index=[sorindexek listája] utasítás listájában az át nem nevezendő sorokra a régi értékeket adjuk meg. Ez utóbbi módszer azért nem túl kényelmes, mert a lista elemszáma itt is meg kell egyezzen a sorok számával, így az összes régi nevű indexet is bele kell venni, míg a .rename(index={}) függvénynél elég csak az átnevezendő sor(oka)t megjelöli. Persze a régi sorindexek listája egy kódsorral megkapható, és ezen lista megfelelő értéke(i) szintén egy kódsorral módosítható(k).

Ami még hátramaradt az átnevezéseket illetően az, hogy hogyan nevezzük el/át magát a sor- vagy oszlopindex objektumot. Íme: df.index.names='sorindex_neve' ill. df.columns.names='oszlopindex_neve'. Szerencsére nem gond, ha előtte még nem volt neve ezeknek az objektumoknak. Ha ezután vesszük magát a sor- vagy oszlopindex objektumot, akkor ez már rendelkezni fog a megadott névvel (pl. Index([<oszlopok nevei>], dtype='object', names=<oszlopindex neve>)).

A dataframe illetve series objektumok indexelése is az alapvető elsajátítandó dolgok közé tartozik pandas-ban.

További teendők

És térjünk vissza újra a megoldásunk értelmezéséhez. A .join() függvénynél járunk, ami a .merge() egy kényelmesebben és egyben korlátoltabban használható változata. Itt túl sok varázslat nincs a kódban, így nem részletezném a működést. Annyit érdemes megjegyezni a .join()-ról, hogy az összeillesztés kulcsának a második dataframe esetén kötelezően indexnek kell lennie, ezért itt szerepel egy .set_index('node_id') hívás is. Az eredeti feladat egysoros megoldásánál a .join() belsejében olvassuk be újra a bemeneti CSV adathalmazt, és az így létrejövő új (másik) dataframe-ben ugyanúgy létrehozzuk a ‘timestamp_type’ attribútumot, mint az első beolvasáskor, elvégezzük a már kivesézett aggregációt (az élek végpontjaira csoportosítva), illetve átnevezzük a ‘to_node_id’-t ‘node_id’-ra, hogy megtörténhessen az összekapcsolás. A szemfülesek fel is kaphatják a fejüket (illetve már az első  .groupby() ill. .agg() utáni .rename() függvénynél is tehették ezt), hogy miért van erre az átnevezésre szükség, ugyanis ahogy korábban már említettem, a CSV beolvasásakor is megadható lett volna a kívánt ‘node_id’ oszlopnév (első beolvasáskor a ‘from_node_id’ helyett, a mostani beolvasáskor pedig a ‘to_node_id’ helyett). De így talán jobban rögzül…

Az adattáblák összekapcsolása után létrejövő dataframe tehát a ‘node_id’ oszlop soraiban tartalmazza a normál csomópontokon kívül a forrásokat és nyelőket is, (melyeknek nincs bemenő vagy kimenő élük), valamint egy-egy oszlopban a kiszámított aggregátumokat. Egy (plusz még egy) dolog maradt már csak hátra, mégpedig hogy meghatározzuk a végleges ‘timestamp_type’ értékeket a ‘timestamp_type_from’ és ‘timestamp_type_to’ értékek segítségével. Előbbi jelöli a csomópontból kimenő élek alapján a hétköznap-hétvége kategória számot, utóbbi pedig ugyanezt a bemenő élek szerint. A végleges érték 1-es, ha volt legalább egy darab hétvégén létrejövő él a be- illetve kimenő élek között, így a két oszlop és egy .assign() függvény használatával elvégezhető a feladat: egy lambda függvény ‘x’ dataframe-ének fenti két oszlopából létrehozunk egy ideiglenes dataframe-et, amire alkalmazható a .max(1) függvény, ami visszaad egy series objektumot, ami soronként a nagyobb (maximális) értékeket tartalmazza. A maximális értékek sorszintű kinyerését az ‘1’-es paraméterrel állítottuk be a .max() függvényben (a ‘0’ értékkel oszlopszintű végrehajtás történik). Természetesen itt is alkalmazhatnánk egy .apply() függvényt (mint ahogy előzőleg kétszer is a ‘timestamp_type’ előállításánál), amiben sorszinten meghívnánk a lambda y: max(y[0],y[1]) függvényt, de mint korábban már látható volt, az első megoldás jóval hatékonyabb. (A működési mechanizmust illetően itt tehát teljesen hasonló a helyzet, mint fentebb a dayofweek esetén.) Az y[<x>] kóddal hivatkozhatunk a lambda függvénynek átadott ‘y’ series nulladik, első stb. elemére, amennyiben sorszintű érvényességgel bír az .apply(), vagyis az axis=1 van beállítva (df.apply(lambda y: max(y[0],y[1]),axis=1)).

Dataframe attribútumainak adattípusai

Ezután következik egy “csinosítónak” tűnő, de valójában kényszerűen szükséges lépés: az összekapcsolás során létrejövő NULL értékeket a 0 értékkel helyettesítjük, amivel kapcsolatban megjegyzendő, hogy ha a kimenetben egész számokat szeretnénk, - és mi azokat szeretnénk, lévén csomópont azonosítókról és időbélyegekről beszélünk -, akkor alkalmazni kell egy .astype(long) függvényt, ami “nemigazán kezeli jól” a NULL értékeket. Egész konkrétan itt (is) bizony elhasal a Python (2.x), így ez elé minden esetben tennünk kell egy .fillna(0) függvényt. Elsőre picit furának tűnhet, hogy a ‘long’ karaktersorozatot kell alkalmaznunk annak ellenére, hogy a Python ‘int64’-ként jelöli az így létrejövő dataframe oszloptípusokat. Ez a Python-pandas “típuskonverzió” (megfeleltetés) miatt van. Az ‘int64’ (pandas) sztring tehát nem lesz jó az .astype() belsejében, de ami még kellemetlenebb, hogy Python 3-ban a ‘long’ sem :) Ez azért van, mert a 3-as Python-ban már csak long típusú 'int' létezik, viszont ez az ‘int’ kulcsszó alatt szerepel. Tehát az ‘int’ nyugodtan használható az .astype() függvényben Python 3 esetén. Ekkor a dataframe-ünk oszlopaira Python 3-ban az ‘int32’ pandas típust kapjuk vissza, ami valójában long Python típust jelent. Itt nem valami jó a Python-pandas típusmegfeleltetés, mármint ami a jelölést illeti, mert maga a konkrét típus az természetesen long az ‘int32’ jelölés ellenére. Ha mégis ragaszkodunk az ‘int64’ típusjelöléshez, akkor használhatjuk a numpy típusokat a konverziónál: df['attr_1'].astype(np.int64). Ekkor már Python 3-ban is ‘int64’ lesz a pandas-os típusjelölés. A méret mindkét esetben (core Python illetve numpy) természetesen ugyanaz: [-9223372036854775808;+9223372036854775807].

A CSV beolvasásának taglalásakor kimaradt ugyan, de a kitartó (visszatérő) olvasók most megtudhatják, hogy a pd.read_csv() függvénynél van lehetőség megadni a beolvasott adatok típusait is a dtype=<adattípus> paraméterrel. Ilyet mi nem adtunk meg, de ilyen esetben szerencsére a pandas helyesen fogja beolvasni az adatokat (az időbélyeg mindenképpen 'long' típusú lesz, de adott esetben a csomópont azonosítók is). A 'long' adattípusok pedig a csoportosítások során “alakultak át” 'float'-okká, amiket tehát most alakítottunk vissza 'long'-á. (A pandas elsőszámú, alapértelmezett numerikus típusa a 'float'.)

Egy dataframe oszlopainak adattípusait a print df.dtypes sorral írathatjuk ki, egy objektum (pl. dataframe) típusát pedig a print type(df) sorral. Ide kapcsolódik még, hogy ha inicializálunk egy üres dataframe-et (df=pd.DataFrame()), melyhez láthatóan nem definiáltunk oszlopokat, akkor a nem létező oszlopok típusai sem léteznek, így ha pl. egy for ciklusban előállított eredményeinket szeretnénk egy ilyen üres dataframe-be iteratívan összegyűjteni (df=df.append(temp_df)), akkor a kimenet attribútumai az iterációnkénti eredménytáblákban lévő oszlopok típusaival azonosak lesznek. Azonban, ha egy dataframe inicializálásakor definiálunk oszlopokat is (df=pd.DataFrame(columns=['attr_1','attr_2'])), akkor azok típusa alapértelmezetten 'object' lesz, de itt is megadható pl. a dtype=float paraméter. A ‘long’ illetve Python 3-ban az ‘int’ itt sajnos nem fog működni, helyettük 'object' típust kapnak az oszlopok (ez sem túl “kellemes”...). Ilyen esetekben az iterációnkénti eredménytáblák ezen inicializált dataframe-hez való hozzáfűzésékor típuskonverzió történhet a “fő” dataframe típusaira, vagyis adott esetben a ‘temp_df’ 'float' (vagy 'long') típusú oszlopai 'object' (vagy 'float') típusúvá változhatnak. Erre mindig figyeljünk oda, és ha szükséges, alakítsuk vissza az attribútumokat a kívánt adattípusra.

Ahogy az itt is illetve az egész posztban (előző bejegyzésekben) látható, hogy mind Python-ban, mind pedig pandas-ban az objektumok illetve attribútumok típusainak megfelelő ismerete és kezelése szintén egy alapvető fontosságú dolog a szkriptek írása közben.

A még hátralévő teendők

A feladathoz ismételten visszatérve, az adattípusok beállítása után egy sima rendezés történik, majd pedig legyártjuk a csomópontokhoz az új azonosítószámokat. Ehhez semmilyen extra algoritmust nem használunk, csak simán az eredeti csomópont-azonosítón (‘node_id’) sorba rendezett adathalmazra küldünk két darab .reset_index() függvényt. Az elsővel eltávolítjuk a jelenlegi kesze-kusza, .groupby(), .join() illetve .sort() után létrejövő indexet, utóbbival pedig a már sorrendhelyes dataframe indexből generálunk egy ‘index’ nevű oszlopot, amit gyorsan át is nevezünk pl. ‘id_new’ névre, így meglesznek az eddig még hiányzó új azonosítószámaink a csomópontokhoz (miáltal új élek illetve csúcsok felvételénél nem ütközhetünk duplikált azonosítókba). Fontos, hogy egy .sort() után a legtöbb esetben mindig kell egy .reset_index() (értelem szerűen).

Végezetül pedig, mivel nem egy-két átalakítást hajtottunk végre ebben az egy darab kódsorban, így betesszük a kimeneti adathalmazban helyet foglaló attribútumok nevét egy listába (ahogy erről fentebb szó esett). Ezzel egyrészt egyértelműen láthatjuk, kvázi egyfajta interfészként, hogy mi a kimenet (mert ilyen kódokat inkább függvényként hívogatunk, mintsem csak úgy közvetlenül), másrészt pedig figyelmen kívül hagyjuk vele a nem kívánt oszlopokat (jelen esetben a ‘timestamp_type_from’ és ‘timestamp_type_to’ attribútumokat). Ebben az esetben tehát fizikailag nem töröljük a fenti két oszlopot, hanem csak nem “engedjük továbbhaladni”. Egyébiránt attribútumot törölni többféleképpen is lehet, az alábbi sorokkal: del df['attr_2'], df=df.drop('attr_2',1) vagy df.drop('attr_2',1,inplace=True) (az ‘1’-es itt is az oszlopokra utal). Utolsó lépésben pedig jöhet az adathalmaz kiírása egy CSV fájlba.

Zárszó

Hát ennyi lenne “egy sor” Python kód magyarázata “picit” részletesebben. Az első poszt bevezetőjében ígértem futási időket is, melyekből csak minimálisat illesztettem be, szóval a részletesebb infók a következő posztra maradnak, ott úgyis izgalmasabb lesz a multiprocessing miatt. A poszt egyébként is ultra-maratoni hosszúságú lett még így feldarabolva is (valahogy mindig mindegyik bejegyzés hosszabbra sikeredik az eggyel előzőtől), és hát akadt volna még a tarsolyban egy-két, a fentiekhez hasonló “nagyon fontos” dolog (pl. az adattábla pivotálás: df.pivot_table()) illetve érdekesség a pandas-t illetően. Ezekről talán majd legközelebb, addig is mindenkinek jó szórakozást illetve gyakorlást, és köszi a kitartást az olvasás során!

 

Szólj hozzá!

A bejegyzés trackback címe:

http://adatbanyaszat.blog.hu/api/trackback/id/tr297659478

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.

Nincsenek hozzászólások.