How fractals helped my students to master package development in R

Last semester I taught an R programming at MIMUW. My lectures are project oriented, the second project was related to package development. The idea was straightforward: each team of students shall create a package that produces IFS fractals (based on iterated function systems). Each package shall have two generic functions: create() and plot(), documentation and vignette. Fractals shall be implemented with the use of S3 or S4 classes.

I have students with different backgrounds. Mostly statistics, but some are from physics, psychology or biology. I was a bit unsure how they will deal with concepts like iterated contractions.
After all results exceeded my expectations.

Guess what is happening with students engagement when their packages start producing nice plots. Their need/hunger for more leads to beautiful things.

This team got interested in nonlinear transformations. They manage to create Apollonian Gasket generator and much more. See their vignette and package here.

Screen Shot 2018-03-09 at 7.31.24 PM

This team got interested in probabilistic mixtures of two fractals. They developed a Shiny app that mixes two sets of contractions with given mixture proportions. Here is a mixture of Sierpinski gasket and a tree. Find out their vignette here.

Screen Shot 2018-03-09 at 7.29.58 PM

This team got interested in random fractals. They developed fractal generator that draws parameters of each contraction. In result they get beautiful random shapes like these. Here is their vignette.

Screen Shot 2018-03-09 at 7.37.42 PMScreen Shot 2018-03-09 at 7.37.31 PMScreen Shot 2018-03-09 at 7.37.26 PM

And these two teams got interested in different ways of fractal colouring. Vignettes of Team 1 and Team 2

Screen Shot 2018-03-09 at 7.40.15 PMScreen Shot 2018-03-09 at 7.36.01 PMScreen Shot 2018-03-09 at 7.31.05 PM

After all it turns out that fractals are very addictive!
Use it with care 😉

DALEX: how would you explain this prediction?

Last week I wrote about single variable explainers implemented in the DALEX package. They are useful to plot relation between a model output and a single variable.

But sometimes we are more focused on a single model prediction. If our model predicts possible drug response for a patient, we really need to know which factors drive the model prediction for a particular patient. For linear models it is relatively easy as the structure of the model is additive. In 2017 we have developed breakDown package for lm/glm models.

But how to explain/decompose/approximate predictions for any black box model?
There are several approaches. The (probably) most known is LIME with great examples for image and text data. There is an R port lime developed by Thomas Pedersen. In collaboration with Mateusz Staniak we developed live package, similar approach, easy to use with models created by mlr package.
The other technique that can be used here are Shapley values which use attribution theory/game theory to attribute effects of different variables for a single prediction.

Recently we have developed a yet another approach (paper under preparation, implemented in the breakDown version 0.4) that works in a model agnostic way (here you can check how to use it for caret models). You can play with it via the single_prediction() function in the DALEX package.
Such decomposition is useful for many reasons mentioned in papers listed above (deeper understanding, validation, trust, etc).
And, what is really extra about the DALEX package, you can compare contributions of different models on the same scale.

Let’s train three models (glm / gradient boosting model and random forest model) to predict quality of wine. These models are very different in structure. In the figure below, for a single wine, we compare predictions calculated by these models. For this single wine, for all models the most influential variable is the alcohol concentration as the wine has much higher concentration than average. Then pH and sulphates take second and third positions in all three models. Looks like models have some agreement even if they structure is very different.


If you want to learn more about DALEX package and decompositions for model predictions please consult following cheatsheet or the DALEX website.

If you want to learn more about explainers in general, join our DALEX Invasion!
Find our DALEX workshops at SER (Warsaw, April 2018), ERUM (Budapest, May 2018), WhyR (Wroclaw, June 2018) or UseR (Brisbane, July 2018).


DALEX: understand a black box model – conditional responses for a single variable

Black-box models, like random forest model or gradient boosting model, are commonly used in predictive modelling due to their elasticity and high accuracy. The problem is, that it is hard to understand how a single variable affects model predictions.

As a remedy one can use excellent tools like pdp package (Brandon Greenwell, pdp: An R Package for Constructing Partial Dependence Plots, The R Journal 9(2017)) or ALEPlot package (Apley, Dan. Visualizing the Effects of Predictor Variables in Black Box Supervised Learning Models (2016)).
Now one can use the DALEX package to not only plot a conditional model response but also superimpose responses from different models to better understand differences between models.

Screen Shot 2018-02-19 at 12.27.58 AM

Consult the following vignette to learn more about the DALEX package and explainers for a single variable.


if you want to learn more about explainers, join our DALEX Invasion!
Find our DALEX workshops at SER (Warsaw, April 2018), ERUM (Budapest, May 2018), WhyR (Wroclaw, June 2018) or UseR (Brisbane, July 2018).

Top interactive visualizations of movie scripts

One of the highest pleasures for an academic teacher is to be surprised by an extraordinary student’s project or homework. Something that greatly exceeds expectations. I’ve reoriented my courses in a way to make such surprises frequent.
The second project in my Data Visualisation classes was related to interactive graphics. The task was to create an interactive graphics/app/tool that summarizes scripts from a selected movie or series.

Here are the top 6 visualizations created by my students. Mostly with R.

Harry Potter

Which duelling spells were cast most often in which book from the Harry Potter series?
Find out here.



Which emotions are the most common for your favorite Avenger?
Find out here.


Games of Thrones

Which Starks are mentioned frequently in Season 6?
Find out here.


The Lion King

What Simba felt during The Lion King?
Find out here.


Pulp Fiction

What is the f**k factor for different characters in the Pulp Fiction?
Find out here.


Léon The Professional

Which character is the most angry in the Léon The Professional?
Find out here.


chRistmas tRees

Year over year, in the last classes before Christmas I ask my students to create a Christmas tree in R.
Classes are about Techniques of data visualisation and usually, at this point, we are discussing interactive graphics and tools like rbokeh, ggiraph, vegalite, googleVis, D3, rCharts or plotly. I like this exercise because with most tools it is easy to create a barchart, but how good must be the tool and the craftsman to handle a christmas tree?

Here is what they did this year (having around 1 hour to finish the task). Knitr scripts.

Update: I am still getting new submissions, feel free to submit yours as well.

Screen Shot 2017-12-22 at 13.07.26Screen Shot 2017-12-22 at 13.04.49

Screen Shot 2017-12-21 at 23.10.40Screen Shot 2017-12-21 at 23.10.23

Screen Shot 2017-12-21 at 22.06.35Screen Shot 2017-12-21 at 22.00.11

Screen Shot 2017-12-21 at 23.11.45Screen Shot 2017-12-21 at 23.11.19

Screen Shot 2017-12-21 at 21.57.54Screen Shot 2017-12-22 at 13.07.54

Screen Shot 2017-12-22 at 23.09.48Screen Shot 2017-12-22 at 23.09.25

Screen Shot 2018-01-09 at 22.37.20Screen Shot 2018-01-09 at 22.20.51

Screen Shot 2018-01-09 at 22.13.01Screen Shot 2018-01-09 at 21.57.06

Screen Shot 2018-01-09 at 21.47.06Screen Shot 2018-01-09 at 21.43.25

Screen Shot 2018-01-09 at 21.39.49Screen Shot 2018-01-09 at 21.22.31

Screen Shot 2017-12-21 at 23.10.48

archivist: Boost the reproducibility of your research

A few days ago Journal of Statistical Software has published our article (in collaboration with Marcin Kosiński) archivist: An R Package for Managing, Recording and Restoring Data Analysis Results.

Why should you care? Let’s see.


Would you want to retrieve a ggplot2 object with the plot on the right?
Just call the following line in your R console.


Want to check versions of packages loaded when the plot was created?
Just call


Wishful Thinking?

When people talk about reproducibility, usually they focus on tools like packrat, MRAN, docker or RSuite. These are great tools, that help to manage the execution environment in which analyses are performed. The common belief is that if one is able to replicate the execution environment then the same R source code will produce same results.

And it’s true in most cases, maybe even more than 99% of cases. Except that there are things in the environment that are hard to control or easy to miss. Things like external system libraries or dedicated hardware or user input. No matter what you will copy, you will never know if it was enough to recreate exactly same results in the future. So you can hope that results will be replicated, but do not bet too high.
Even if some result will pop up eventually, how can you check if it’s the same result as previously?

Literate programming is not enough

There are other great tools like knitr, Sweave, Jupiter or others. The advantage of them is that results are rendered as tables or plots in your report. This gives you chance to verify if results obtained now and some time ago are identical.
But what about more complicated results like a random forest with 100k trees created with 100k variables or some deep neural network. It will be hard to verify by eye that results are identical.

So, what can I do?

The safest solution would be to store copies of every object, ever created during the data analysis. All forks, wrong paths, everything. Along with detailed information which functions with what parameters were used to generate each result. Something like the ultimate TimeMachine or GitHub for R objects.

With such detailed information, every analysis would be auditable and replicable.
Right now the full tracking of all created objects is not possible without deep changes in the R interpreter.
The archivist is the light-weight version of such solution.

What can you do with archivist?

Use the saveToRepo() function to store selected R objects in the archivist repository.
Use the addHooksToPrint() function to automatically keep copies of every plot or model or data created with knitr report.
Use the aread() function to share your results with others or with future you. It’s the easiest way to access objects created by a remote shiny application.
Use the asearch() function to browse objects that fit specified search criteria, like class, date of creation, used variables etc.
Use asession() to access session info with detailed information about versions of packages available during the object creation.
Use ahistory() to trace how given object was created.

Lots of function, do you have a cheatsheet?

Yes! It’s here.
If it’s not enough, find more details in the JSS article.

Explain! Explain! Explain!

Predictive modeling is fun. With random forest, xgboost, lightgbm and other elastic models…
Problems start when someone is asking how predictions are calculated.
Well, some black boxes are hard to explain.
And this is why we need good explainers.

In the June Aleksandra Paluszynska defended her master thesis Structure mining and knowledge extraction from random forest. Find the corresponding package randomForestExplainer and its vignette here.

In the September David Foster published a very interesting package xgboostExplainer. Try it to extract useful information from a xgboost model and create waterfall plots that explain variable contributions in predictions. Read more about this package here.

In the October Albert Cheng published lightgbmExplainer. Package with waterfall plots implemented for lightGBM models. Its usage is very similar to the xgboostExplainer package.

Waterfall plots that explain single predictions are great. They are useful also for linear models. So if you are working with lm() or glm() try the brand new breakDown package (hmm, maybe it should be named glmExplainer). It creates graphical explanations for predictions and has such a nice cheatsheet:


Install the package from

Thanks to RStudio for the cheatsheet’s template.

Z pamiętnika nauczyciela akademickiego – Irracjonalne wybory


Wybory studentów są czasem nieracjonalne, przynajmniej z mojego punktu widzenia. Ale czasem to znaczenie lepiej i bardzo mnie to cieszy.

Dłuższa wersja

Na przedmiocie Techniki Wizualizacji Danych mam w tym roku bardzo silną grupę matematyków ze specjalności SMAD (statystyka i analiza danych) i informatyków ze specjalności PAD (przetwarzanie i analiza danych). W semestrze mamy trzy projekty i spodziewałem się, że wyniki każdego będą tak ciekawe, że je tutaj opiszę.


W terminie oddanie pierwszego projektu zadałem też całkiem wciągającą pracę domową. Projekt dotyczył wizualizacji danych komunikacji miejskiej VaVeL, praca domowa dotyczyła przeprowadzenia badania sprawdzającego jak ludzie odczytują dane z wykresów. Z projektu można było dostać do 100 punktów, praca domowa jest punktowana 10 punktów, z możliwością dodatkowego bonusu 10 punktów jeżeli będzie bardzo dobra. Projekt był dosyć silnie skierowany na konkretny dobór danych, praca domowa pozostawiała bardzo szerokie pole do interpretacji.
Czasu oczywiście niewiele, warto zrobić jedno i drugie ale projekt to 100 punktów a praca domowa max 20.
Na co studenci poświęcili więcej czasu?
Racjonalnie (więcej o tym na samym końcu) byłoby się skupić głownie na projekcie. Ale patrząc na wyniki, więcej czasu i serca widać w pracach domowych. Badania, które wykonali na pracę domową były tak ciekawe, że to właśnie o nich napiszę poniżej.

Ale o co chodzi

Punktem wyjścia do pracy domowej był esej Percepcja obrazu oraz trudność w wyobrażenia sobie co odbiorca widzi na naszym wykresie, jeżeli nie jest obciążony naszą wiedzą, co na tym wykresie chcieliśmy pokazać. Na wykładzie omawialiśmy sobie jak nasz mózg widzi wykresy, jak rozumie dane i co potrafi z wykresu odczytać a czego nie.
Zadaniem było przeprowadzenie badania na kolegach/koleżankach, badania oceniającego które wykresy są lepiej (=precyzyjniej) odczytywane.

I co z tego wyszło

Jedna z grup (Alicja Gosiewska, Kinga Jamróz, Maja Kalinowska, Karolina Marcinkowska) przygotowała internetową ankietę weryfikującą co internauci widzą a czego nie widzą a następnie zebrała wyniki w raporcie.

Ankietę można znaleźć w internecie TUTAJ i bardzo polecam ją zrobić. Jest świetnie przygotowana, zaskakująca i to po prostu dobra zabawa.

Wyniki z zebranych badań w postaci raportu są dostępne TUTAJ.
Uwierzcie, że po zrobieniu ankiety, będziecie chcieli wiedzieć jak zrobili ją inni.

Ciekawych prac domowych było oczywiście więcej.
Zespół (Mateusz Mazurkiewicz, Wojciech Rosiński, Dawid Stelmach) sprawdzał czy wykresy słupkowe sa faktycznie takie dobre jak je prowadzący rysuje.
Ta praca mierzy się z wykresami typu tree plot (Ahmed Abdelkarim, Aleksandra Hernik, Iwona Żochowska)
Z piktogramami (czy ISOTYPE) mierzyła się grupa (Paweł Pollak, Karol Prusinowski, Karol Szczawiński)
A zespół (Anton Lenartovich, Mateusz Mechelewski) rozstrzygał komu podobają się wykresy typu płatki śniegu.

A co do tytułowej irracjonalności.
Na jesienną pluchę polecam książkę Dana Ariely (dostępna też jako audiobook) Predictably Irrational: The Hidden Forces That Shape Our Decisions.
Oczywiście zachowania studentów wcale nie są irracjonalne. Zamiast wybrać zadanie z większą liczbą punktów wybrali zadanie ciekawsze w dłuższej perspektywie jest lepszym wyborem.
A to, jak pisałem na wstępie, bardzo mnie ucieszyło.

MI^2 Data Talks

MI2 DataLab logo
Z początkiem semestru ruszamy z nowym seminarium badawczym w DataLabie.

Seminarium skierowane jest do osób zainteresowanych pracą badawczą w obszarze tworzenia narzędzi (metodologii i softu) do modelowania statystycznego.

Na zmianę będziemy mieć referaty o:

* jak tworzyć dobre oprogramowanie statystyczne (GiHub, Travis, Continuous Integration, Czysty Kod),
* jak komunikować wyniki swoich badań (przygotowanie prezentacji, artykułu, plakatu na konferencje, cheatsheetu),
* Journal Club.

Lista tematów kolejnych spotkań dostępna jest na stronie

Spotykamy się we wtorki w godzinach 12-14 w DataLab (pokój 44, Koszykowa 75, Warszawa). Zapraszamy.

Co się działo na hakatonie Urban Sensors?


Hakaton Urban Sensors odbył się 26 września, dzień przed konferencją WhyR? Poniżej opiszę z jakimi danymi walczyliśmy i co ciekawego udało się zrobić.


Podczas tej jednodniowej imprezy pracowaliśmy z miejskimi danymi pochodzącymi z projektu VaVeL. Dokładniej z trzema źródłami danych:

  • Danymi online o położeniu autobusów i tramwajów w Warszawie. Poprzez interface REST pobieraliśmy szczegółową informację o tym gdzie znajdują się obecnie autobusy i tramwaje w Warszawie, ile są spóźnione, w którym kierunku jadą, kto je prowadzi, jaki jest najbliższy przystanek itp.
  • Danymi offline o położeniu autobusów i tramwajów. W plikach tekstowych mieliśmy zebrane informacje o położeniach autobusów i tramwajów przez cały lipiec i wrzesień. To całkiem spore dane. Logi dla jednego dnia zajmują średnio około 2.5GB.
  • Danymi offline z telefonii komórkowej. Dla poszczególnych stref Warszawy mieliśmy informacje ile było zdarzeń w sieci komórkowej w poszczególnych godzinach. Dane pokrywały lipiec i wrzesień. Te dane nie były tak duże jak informacje o ruchu pojazdów, ale były bardzo ciekawe.



Hakaton rozpoczął się od dwóch krótkich warsztatów. Pierwszy prowadzony przez Przemysława Biecek opisywał jak dostać się do danych. Drugi prowadzony przez Ewę Baranowską poświęcony był interaktywnej wizualizacji z użyciem biblioteki D3. Materiały wideo z obu warsztatów będą dostępne na stronie hakatonu w połowie października.


Po warsztatach, uczestników hakatonu przywitali przedstawiciele partnerów projektu VaVeL. W kolejności wystąpienia, byli to: dziekan wydziału MiNI PW prof. Wojciech Domitrz; dyrektor Biura Cyfryzacji Miasta um. st. Warszawy, p. Tadeusz Osowski i dr Jarosław Legierski z Orange Labs.


Uczestnicy z entuzjazmem zabrali się do pracy z danymi. Intensywna praca trwała do godziny 20 i zakończyła się wieloma ciekawymi rozwiązaniami.
Zadanie nie było proste, dane były gigantyczne i nie wszystkie zespoły zdecydowały się na zaprezentowanie rozwiązań. Ale te zaprezentowane były bardzo ciekawe.


Prezentacje rozpoczął projekt Jana Bajerskiego, pokazujący jak wyglądają wizualizacje przejazdów autobusów i tramwajów na tle danych rozkładowych. Do wizualizacji wykorzystano diagramy Mareya. Z opracowanym narzędziem można się pobawić na stronie (wersja rozwojowa).
Diagramy Mareya okazują się fantastycznym narzędziem by śledzić czy pojazdy się spóźniają, gdzie są wąskie gardła, jak bardzo się spóźniają, jak wydłuża się czas podróży. Można też łatwo zauważyć, czy autobusy tej samej linii mają tendencje do tworzenia ,,stad” kilku pojazdów jadących blisko siebie.


Kolejne rozwiązanie przedstawiła Ewa Baranowska. Pozwala ono w czasie rzeczywistym śledzić gdzie znajdują się obecnie autobusy i tramwaje w naszej okolicy. Interaktywna wizualizacja znajduje się na tej stronie.


Następnie Adam Wróbel przedstawił przeprowadzoną statystyczną analizę opóźnień tramwajów. Modelowanie z użyciem modeli regresyjnych pozwala szukać linii narażonych na wysokie ryzyko opóźnienia. Ciekawym wynikiem była ujemna korelacja przyrostów opóźnienia z przesuniętymi wartościami. Oznacza to, że (zgodnie z intuicją) motorniczy jeżeli ma opóźnienie i może je nadrobić to je nadrabia, a jeżeli jedzie przed rozkładem to zwalnia by zlikwidować nadczas.


Silny zespół z firmy Pearson w składzie Krzysztof Jędrzejewski, Mikołaj Olszewski, Mikołaj Bogucki, Mateusz Otmianowski, Kacper Łodzikowski przedstawił aplikację shiny, którą udało się błyskawicznie zbudować w czasie hakatonu. Aplikacja o wdzięcznej nazwie CzyZdążę.pl pozwala na sprawdzenie, dla planowanej trasy przejazdu, gdzie obecnie jest najbliższy tramwaj/autobus na który trzeba się spieszyć i ile średnio potrwa przejazd. To było niesamowite oglądać ile udało się temu zespołowi wykonać w ciągu zaledwie kilku godzin.


Pearson nie był jedyną firmą licznie reprezentowaną na hakatonie. Ciekawe rozwiązanie zaprezentował również zespół analityków z GfK Polonia w składzie Natalia Okińczyc, Barbara Czarnota, Andrzej Surma, Agnieszka Fronczyk. Przygotowali analizę przystanków skazanych na największe opóźnienia wraz z animowanymi wykresami wykonanymi w pakiecie animation.


Aplikacji skiny było więcej. Ciekawą analizę z użyciem biblioteki leaflet i shiny wykonał zespół z firmy Neuca (Karolina Mazanowska, Kamil Sieklucki). Ich wyniki znaleźć można na GitHubie.


Obok zespołów analityków z jednej firmy, w hakatonie brały udział zespoły w barwach wydziałowych. Silny zespół 100 składający się głównie ze studentów, doktorantów i absolwentów MIM UW zaprezentował ciekawą analizę danych dotyczącą dużych wydarzeń w mieście i ich wpływu na ruch miejski.
Ich wstępna analiza znajduje się pod tym adresem.



Wiele z opracowanych rozwiązań, razem z prezentacjami z warsztatów, można znaleźć w repozytorium GitHub.
Na zakończenie zorganizowaliśmy konkurs na najbardziej innowacyjne rozwiązanie.

Zwyciężył zespół z firmy Pearson, wyprzedzając o zaledwie kilka głosów rozwiązanie zaprezentowane przez Jana Bajerskiego. Zwycięska drużyna otrzymała na pamiątkę Pałac Kultury z nadrukowanym wielkim R.


Realizacja hakatonu była możliwa dzięki wsparciu ze strony organizatorów: Aleksandry Dąbrowskiej, Alicji Gosiewskiej, Klaudii Korniluk, Marcina Kosińskiego i Konrada Więcko; licznych ekspertów merytorycznych wspierających nas ze strony Urzędu Miasta Warszawa; przedstawicieli MiNI w osobie Grzegorza Bagrowskiego i Jarosława Legierskiego, którzy wiedzieli wszystko o danych; Krzysztof Wittelsa który wspierał nas organizacyjne ze strony Urzędu Miasta oraz całego zespołu projektu VaVeL, który przygotował infrastrukturę z którą mogliśmy pracować.


Hakaton już się zakończył, ale nie jest to ostatnia inicjatywa związana z analizą tych szalenie ciekawych danych. Wkrótce informacja o kolejnych.