Az első napon délelőtt és délután is négy-négy tutorial közül válogathattak a
résztvevők. Én (a többi magyar résztvevővel együtt) Csárdi Gábor Igraph-bemutatójára ültem be: a legfrissebb (1.0) verzóban már valósággal lubickolni lehet a különböző gráfmanipulálási módszerekben, szintaxisokban: a régiek (egyelőre) megmaradnak, viszont az egész bővült egy make_* függvénycsaláddal, ráadásul a make_ önmagában is megáll függvényként. Amióta utoljára elmélyültem a csomagban, jelentősen fejlődött az ábrázolás, lehet közösségeket is plottolni követlenül, nem kell a csúcsok attribútumait beállítani. Viszont lehet használni meglepően nagy mértékben: a csúcsok (vagy élek) attribútumaként is meg lehet adni a paramétereket (szín, alak, méret, bármi ami létezik). Hozzá lehet nyulni a gráf elemeihez már a “[” es “[[” operátorokkal is. Ami szintén egy nagy újítás számomra, hogy össze lehet hasonlítani a közösségeket a csomagban implementált függvényekkel, és nem kell külső csomagokból importálni a mérőeszközöket.

Délután az assertive és a testthat csomagokba kaptam egy kis bevezetőt: a két részre osztott gyakorlat első fele az előbbi, második az utóbbi csomagról szólt, hasonló felépítésben: a több mint egy órás szakaszok eleján egy bevezetőt mondott Richard J. Cotton, majd egy nagy adag házifeladaton kellett átrágni magunkat. Nem volt szó a testthat csomagnak a frissen elmentett függvényre való futtatásáról, amit Otti Levente mutatott az április BURN meetupon.

Este hétkor a helyi MüPában tartott a polgármester egy rövid beszédet, majd egy állófogadással ért véget a hivatalos program.

Via:: useR! 1. nap

eredmény függvények=c("függvény_1", "függvény_2", "függvény_n"),
közös_argumentum=változó_1,
függvény_1_argumentuma=változó_2,
függvény_v_argumentuma=változó_4)

Először is érdemes udni, hogyan hívok meg egy függvényt, amit egy változóban kapok meg, egy olyan argumentummal, amit egy másikban. Példaként vegyűk az R beépített iris adatbázisát:

# Előkészítem a függvényt és a változót:
f1 <- "mean"
v1
# a változókban tárolt feladatot elvégeztetem:
do.call(f1, list(x=v1))
# 5.843333

A do.call függvény egy karakterként kéri a függvény nevét, és egy elnevezett listában kéri az argumentumokat. Ezek alapján, ha egyszerre több függvényt szeretnénk meghívni, használhatjuk a megszokott *apply függvénycsaládot:

# több függvényt hívok egyszerre majd meg:
f2
v1
# sapply-jal minden függvényre megcsinálom a do.call-t
sapply(f2, do.call, args=list(x=v1))
# mean sum
# 5.843333 876.500000

Megoldható az is, hogyha az iris adatok mindegyikén (legalábbis a számokon) szeretném elvégezni a feladatot, ugyanakkor az sapply erre már nem jó:

# változók:
f2
# az iris oszlopnevei, az 5-ik kivételével. paste(), hogy eléjük tegyem a data.frame nevét:
v2
# sapply
sapply(v2, function(v){sapply(f2, do.call, args=list(x=v))})

A probléma, hogy ebben az esetben az “isir$Sepal.Length” sztringre próbálja elvégezni az átlagszámítást, ami természetesen nem megy. (Egyébként próbálkoztam névvé alakítani, abban az esetben nem találja meg, és még nem tudom hogy miért). Érdemes tehát kicsit belevetni magunkat abba, hogyan íratunk meg az R-rel olyan kódokat, amiket később végre tud hajtani.

Ehhez azt kell tudnom, hogy fog kinézni a kifejezés (expression):

sapply([függvények], do.call, args=list(x=[változó]))

A [függvények] helyére a függvények neveit tartalmazó karakter vektor neve (esetemben f2), a [változó] helyére pedig az egyes oszlopok nevei kell kerüljenek. Először érdemes összerakni ezt a kifejezést:

paste0("sapply(f2, do.call, args=list(x=", [változó neve], "))")

Ebben a kódban már csak a változó nevét kell cserélgetni, amire viszont teljesen jó az sapply:

ch1 <- sapply(v2, function(v){paste0("sapply(f2, do.call, args=list(x=", v, "))")})
str(ch1)

A ch1 a kód végrehajtása után egy karakter vektor lesz, minden egyes elemének van neve, és tartalma a kód, ami egy érvényes kifejezés (lesz, most még csak egy betűhalom), és az R végre fogja tudni hajtani mindet, ha tudja, hogy értelmeznie kell őket. Az értelmezést a parse függvény, a végrehajtást pedig az eval függvény végzi. Előbbinél figyelni kell, hogy egy sztring megadása a text paraméterbe kell kerüljön, különben egy fájl tartalmát fogja keresni. Tehát a

eval(parse(text=ch1[1]))

parancs során az R megajándékoz két, névvel ellátott számmal, azt sem kell kitalálni, melyiket melyik függvény eredményeként kaptam (ez a képesség engem nagyon kellemes meglepetésként ért). Tehát nem maradt más hátra, mint előre, és az eval(parse()) kombinációt a ch1 minden tajára elvégezni:

eredmeny
str(eredmeny)

Teljes siker: kaptunk egy függvény és egy változólistát (f2 és v2), és azt megcsináltuk azok konkrét mivoltának ismerete nélkül. Ráadásként pedig egy szépen strukturált eredményt kaptunk: egy mátrixot, annak oszlopaiban a változónevekkel, soraiban pedig a függényekkel. Ez az sapply egyik argumentumának és alapbeállításának köszönhető (simplify=TRUE), ami, ha azonos típusúak az egyes függvények eredményei, összecsomagolja őket egy vektorba/mátrixba/tömbbe, ha pedig egyikbe sem tudja, akkor listaként adja vissza az eredményt. Ennek természetesen vannak veszélyei, de ilyen egyszerű feladatnál ezt még biztos tudja kezelni az R (érdemes kipróbálni, mi történik, ha a szórás kiszámítása helyett karakterré alakítjuk a számokat – ez nem csak típusban, hanem hosszban is eltérő eredményeket fog ugyanis adni. Egyúttal itt a kérdés is, amire még nem tudom a magyarázatot: hogyan sikerül az eredményt mátrixszá összegyúrnia az sapply-nak?)

Az iris adatok tartalmazzák az egyes példányok fajtáját is, a következő(nek szánt) bejegyzésben azt részletezem majd, hogyan lehet minden fajtára elvégezni a kívánt műveleteket (lehetőleg gyorsan), illetve hogyan lehet bonyolultabb függvényeket, amik több argumentummal is rendelkeznek, ellátni a szükséges információkkal.

Via: Programozó programot programozni

A probléma az, hogy habár egy R markdown dokumentumot, amíg csak szöveg van benne, szépen át tudok tenni Word-be a Knitr segítségével, mindez a képeknél nem működik. Ha grafikont rajzolok, a feliratok rosszul jelennek meg, például “é” helyett azt látom, hogy “ˇA©”. Márpedig így nem lesz olvasható az ábra, és csinálhatom meg mégis inkább Excellel. A markdown fájl jó, az R jó, mert ha csak az ablakra rakom ki, működik. Az ábrát a Knitr csinálja, tehát valószínűleg nála lesz a probléma.

A cirill karakterekre panaszkodtak sokan, így hosszú kutató munka, az R kódolásának, a forrás kódolásának, a locale átállításának kipróbálása után megtaláltam Yihui vonatkozó posztját, és a bug-reportokat is. Ezek egyrészt a

pdf.options(encoding)

Máshol a karakterkészletet hibáztatják, ugyanakkor nem gondolom, hogy itt is az lenne a probléma. Lehet, hogy azt a köztes utat választom majd, hogy elmentem az ábrákat én magam a

png()

Ki is derült: nem tudom miért nem működött tegnap, de ma sikeresen vette az ékezeteket: egyrészt a

knit2html()

encoding="UTF-8"

Via: Szenvedés az ékezetekkel – személyes feljegyzés

A knitr nem figyel fel a

data.table::set()

:=

DT[, a:=sum(b)] helyett DT <- DT[, a:=sum(b)]

Ilyen módon a memóriafogyasztás illetve a sebesség sem csorbul jelentősen, viszont nem kell százoldalas táblázatokat nézegetnünk.

További olvasmányok a témárór a Stack Owerflow-n angolul: felületesebben és részletesebben.

Via: data.table vs. knitr

Én először csak véletlenül akadtam Tal Galili blogján a leírásra, és bevallom, nem is teljesen értem a mögöttes rendszerek működését. Hogy mit és pontossan hogy csinál a pandoc? Hogy miket jelentenek a knitr csomag beállításai? Fogalmam sincs. Viszont a magam dolgának megkönnyítése végett az ott leírt folyamat köré írtam egy függvényt, ezt most leírom, hogy működik (ami nem nagy dolog, nagyjából megegyezik azzal, amit a hivatkozott bejegyzésben Tal is leírt).

1.: R-ben telepítsd a pander csomagot, ami minden más szükséges csomagot telepíttetni fog.

install.packages("pander")

2.: Telepítds a pandoc nevű programot. Ennek kétféle módja van:

2a.: R-ből az installr csomag segítségével

# intallr csomag telepítése, ha kell:
if(!require(installr)) { install.packages("installr")}
# installr betöltése:
require(installr)
# pandoc telepítése
install.pandoc()

Ennek a módszernek az a hátránya, hogy nekem nem működött sehogysem az install.pandoc(). Ezért megpróbáltam natúr, magamtól telepíteni.

2b.: Telepítés önmagában:

A pandoc elérhető a Github-on, letöltöd, majd futtatod az msi fájlt, telepítés után pedig

3. Indítsd újra a gépet!

Ez fontos, e nélkül a pandoc nem fog rendesen működni (valószínűleg. De lehet, hogy igen).
Ezzel tulajdonképp megvannak az alapok.

4. Írd meg, amit szerkeszteni szeretnél utána

A markdown alapszabályai szerint, illetve R markdownban. Nem bonyolultak az alapok, érdemes utánanézni. Miután pedig kész, elmented, és megjegyzed hogy hol és milyen néven van a fájl.

5.: rmd2docx(source)

Innentől jön az általam egy parancsba gyógyított eljárás, ami a következőképp néz ki:
(A source helyére természetesen nem mást, mint a korábban elmentett markdown fájl helyét és nevét (teljes fájlnév, elérési út) kell beírni két idézőjel közé, entert nyomni, és már hasít is a gép)

5a.: Először beállítja a megadott fájl mappáját munkakönyvtárnak (ez később lehet, hogy problémát fog okozni, egyelőre kézenfekvőnek tűnik), aztán megkeresi a fájlnevet, majd külön a kiterjesztést, hogy megnézi, rmd fájl-e a bemenet. Mivel a kiterjesztés nem jelent semmit, ezért csak üzenet a usernek, lehet hogy lefelejtette:

setwd(dirname(source))
FILE <- basename(source)
NAME <- strsplit(FILE, ".", fixed=TRUE)[[1]][1]
ext <- strsplit(FILE, ".", fixed=TRUE)[[1]][2]
if(!(tolower(ext)=="rmd")){
message("Are you sure you use an R markdown file?")
}

5b.: Beolvassa a megadott fájlt, az elejéhez hozzáfűzi a megadott beállításokat, majd egy ideiglenes fájlba elmenti.

opts.for.docx <- '```{r set_knitr_chunk_options}
opts_chunk$set(echo=FALSE,message=FALSE,results = "asis") # important for making sure the output will be well formatted.
```
```{r load_pander_methods}
require(pander)
replace.print.methods <- function(PKG_name = "pander") {
PKG_methods <- as.character(methods(PKG_name))
print_methods <- gsub(PKG_name, "print", PKG_methods)
for(i in seq_along(PKG_methods)) {
f <- eval(parse(text=paste(PKG_name,":::", PKG_methods[i], sep = ""))) # the new function to use for print
assign(print_methods[i], f, ".GlobalEnv")
}
}
replace.print.methods()
## The following might work with some tweaks:
## print <- function (x, ...) UseMethod("pander")
```'
# append them to the file:
tempfile <- readLines(FILE)
tempfile <- c(opts.for.docx, tempfile)
writeLines(tempfile, "tempfile.rmd")

5c.: Betölti a knitr csomagot, majd előbb hagyományos markdown fájlt készít belőle (feldolgozza az R kódokat), aztán összerak belőlük egy html fájlt:

require("knitr", quietly=TRUE)
knit2html("tempfile.rmd")

Eddig ezt csak ábrák nélküli dokumentummal próbáltam. Érdemes lenne létrehozatni az R-rel egy mappát, hogy abba mentse, amit aztán egy az egyben lehetne törölni, mint szemetet, miután kész. Ez a jövő zenéje még.

5d.: Miután megvan a markdown fájl, a pandoc-kal készíttetünk belőle a word által olvasható fájlt:

system(paste0("pandoc -o ", NAME, ".docx ", "tempfile", ".md"))

A második argumentuma a paste0() függvénynek nem más, mint az eredeti rmd fájl neve, így név alapján könnyen megtaláljuk majd az új fájlt, illetve külöböző fájlok nem fogják egymást felülírni.

5e.: Ezután pedig töröljük a korábban létrehozott markdown és html fájlokat:

unlink(c("tempfile.html", "tempfile.md"))

És fel is takarítottunk magunk után, az eredeti fájl mellett ott virít büszkén a Worddel szerkeszthető doksi, benne az alap formázásnak megfelelő kínézetű, stílusokkal rendelkező szöveg, táblázatok, képek, sikeresen megoldottuk a feladatot. o/

A kód egészében természetesen elérhető GitHub-on!

Via: Így készíts docx fájlt R-rel!

[crayon-61ed3859d5a0b888231396 inline="true" ]getAddressCoord <- function(address){
address <- as.character(address)
address <- paste(unlist(strsplit(address, split=" ")), collapse="+")
base <- "http://maps.googleapis.com/maps/api/geocode/json?address="
ending <- "&sensor=false"
download.file(url=paste(base, address, ending, sep=""),
destfile="temp_address_info.json")
address.info <- fromJSON(file="temp_address_info.json")
unlink("temp_address_info.json")
if(address.info[["status"]] == "OK"){
long.lat <- unlist(address.info$results[[1]]$geometry$location)
return(long.lat)
} else {
return("Result is not appropriate!")
}
}

Via: Postacím koordinátáinak megtalálása R-rel.

Kiindulás: írtam egy modellt, amiben használok UNIX időbélyegeket az időpontok megjelölésére. Ebben nincs semmi ördöngősség, egy szám, ami az 1970 január 1. óta eltelt másodpercek segítségével jelzi az időt. A helyzet azonban az, hogy ezek nagy számok, annyira nagyok, hogy egy átlagos számítógép nem nagyon tud vele mit kezdeni, nem fér el a szokásos 32 biten, mert azon csak 2^32-1 számot tudnak megmutatni. Erre készítettek egy csomagot, ami úgy ábrázolja a 64 bites számokat, hogy az első 32-t és a második 32-t külön veszi, és egy listaként tartja számon. Bravúros megoldás, és rettentően jól működött, míg csak tárolni kellett. A használata már nehezebb volt.

Amikor egyenletes mintát szerettem volna venni a rendelkezésre álló időintervallumból, elsőre azt kértem, válasszon ki véletlenül n darab számot 1és N közül, ahol N>2^31-1. Erre hibát adott, de én furfangos vagyok, és kértem n darab véletlen számot 0 és 1 közül, majd beszoroztam N-nel – de ezek eredménye mind 0, mert véletlenszám 64 bitesre konvertálása során a törtszámok egészig csonkolódnak. Ennek oka, hogy a csomag először a másik, nem 64bites számot is átkonvertálja ugyan olyanra, mint az eredeti – ami viszont egészekre van kitalálva, tehát az átkonvertált számnak is egésznek kell majd lennie. Erre van ám egyszerű megoldás, vegyünk 1 és 2^31-1 közt egyenletesen mintát. Ekkor a lehetséges számok intervallumának felét fedtük le. Ha ezt felszoroznánk kettővel, akkor vennénk a teljes intervallumról… de nem, mert az csak 2^32-1ig menne. De az ötlet nem rossz, vegyünk nagy egész számokat, amíg a szükséges minta nem nagyobb a meglévő számoknál, és osszuk el azokat a számokat egyenletesen 1 és N közt!
-No, hát melyik legyen ez a szám?
-2^31-1!
-Nem jó! Az R nem tud ilyen hosszú vektort lefoglalni. Pech, jöhet az alternatíva-keresés az időbélyegek helyett…

No, sebaj, az R 3.0.0 már ismeri a 2^31-1 elemnél hosszabb vektorokat, de csak 64 bites rendszeren. Hmmmm… öcsém alszik, és a vasa megfelel a kritériumnak. Essünk neki.
Nem, nem működött (természetesen). A számokkal sem boldogult el, ráadásul a használt csomagok (az hagyján hogy int64, de a plyr és a doParallel) még híján vannak a friss verzióhoz tartozó változatnak, így azzal kváti semmit nem tudtam kezdeni laikusként. Pedig de szép is lett volna!

A megoldás
A bit64 csomag, és annak a megoldásai. Zseniálisan egyszerű lett tőle a dolgom

Via: 64 bites számok R-ben

Via: Elkezdtem a Pythont