Uczę, bo lubię?

screen-shot-2016-09-26-at-21-57-43

,,Uczę, bo lubię?’’ to tytuł wykładu inaugurującego nowy rok akademicki Uniwersytetu Otwartego Uniwersytetu Warszawskiego. Zazwyczaj unikam wykładów inaugurujących, ponieważ sam wykład trwa krócej niż poprzedzające go ceremonie uroczystego powitania połowy sali (tutaj doszła jeszcze ceremonia rozdania nagród). Ale znak zapytania w tytule skusił mnie na kampus główny UW i cieszę się, że na ten wykład trafiłem.

Punktem centralnym wykładu było pytanie, dlaczego robimy to co robimy, czyli dlaczego nauczyciele akademiccy uczą.

Jedni uczą, bo muszą (nie mają stanowisk naukowych, a na naukowo-dydaktycznych trzeba wyrobić pensum), inni uczą, bo chcą. Ale chcieć mogą z różnych powodów, jedni lubią robić show (a tutaj rzesza widzów), inni lubią poczucie władzy (wystawianie ocen), innym może podobać się stabilność zatrudnienia (choć z tą jest różnie).
Są też tacy, którzy uczą z rzemieślniczą starannością robienia porządnie tego co robią. Oraz tacy, którzy po prostu lubią mówić o tym co ich interesuje. Są wreszcie tacy, którzy lubią pracować z młodymi ludźmi, którzy lubią potyczki intelektualne ze studentami. Powodów jest pewnie bez liku, tyle co nauczycieli, niektóre bardziej inne mniej wzniosłe.

Gdy przyjrzeć się w jakiej roli nauczyciele występują w filmach, książkach czy serialach to wizerunek nauczyciela jest różny, od Siłaczki Żeromskiego, przez Alcybiadesa Niziurskiego po postawy z zachodnich filmów takich jak John Keating w Stowarzyszeniu Umarłych Poetów.

Te generyczne wizerunki zazwyczaj mało pasują do nauczycieli akademickich matematyki, którzy wydają się być osobnym plemieniem wśród nauczycieli. Jakim? Bardzo ciekawy wizerunek dydaktyka i naukowca przedstawiony jest w filmie Przestrzenie Banacha (o Stefanie Banachu), który polecił mi znajomy po ww wykładzie.
Warto zobaczyć przed nadchodzącym rokiem akademickim.

screen-shot-2016-09-26-at-23-07-40

Który telefon się wcześniej zepsuje?

Uczestniczyłem ostatnio w ciekawym (od strony metodologicznej) projekcie (patrz też komentarz na dole). A ponieważ przy okazji używałem kilku ciekawych narzędzi, więc poniżej krótko o nich opowiem.

Problem:

Przypuśćmy, że mamy taki problem. Mamy telefony dwóch marek, np A i B. Załóżmy też, że w tych telefonach może zepsuć się bateria lub ekran, innych uszkodzeń nie rozważamy. Jeżeli się cokolwiek zepsuje, telefon jest wymieniany na nowy, nie ma sensu go naprawiać.
Chcemy teraz sprawdzić czy tempo psucia się ekranu w telefonach marki A jest inne niż w telefonach marki B. Podobnie chcemy porównać działanie baterii.
Przypuśćmy, że w badaniu obserwujemy dużo (tysiące) telefonów każdej z marek. Badanie prowadzimy przez 3 lata, ale niektóre telefony uczestniczą w badaniu od roku, inne od 2 lub 3 lat.
Pytanie, jaką metoda porównać te marki?

Podejście brutalne 1:

Najbardziej brutalne podejście to policzenie jaki procent ekranów zepsuł się w marce A a jaki w marce B i porównanie tych procentów np. dokładnym testem Fishera (w R funkcja fisher.test {stats}, więcej o teście tutaj) lub regresją logistyczną.
Ale…
To nie jest dobre podejście, ponieważ telefony nie były obserwowane przez tak samo długi czas. Mogło się zdarzyć, że w jednej grupie pozyskano więcej telefonów na początku, 3 lata temu, więc ich czas obserwacji był dłuższy. A może w innej grupie pozyskano telefony niedawno, np. rok temu, czas obserwacji jest krótszy i dlatego mniej ich się zepsuło.

Podejście brutalne 2:

Skoro czas obserwacji jest różny, to porównajmy liczbę dni do czasu zepsucia się ekranu lub baterii. Możemy to zrobić np. testem Wilcoxona (w R funkcja wilcox.test {stats} więcej o teście np. tutaj).
Ale…
To nie jest dobre podejście, ponieważ nie wszystkie telefony się zepsuły, nie dla wszystkich znam czas do zepsucia. Być może w jednej grupie średni czas do uszkodzenia jest niższy, ale też mniej telefonów się zepsuło. Nie chcemy też odrzucać informacji o tych wszystkich telefonach, które się nie zepsuły.

Mniej brutalne podejście 3:

Skoro mamy różne czasy obserwacji i nie dla wszystkich obserwacji wiemy jaki był czas uszkodzenia ekranu lub baterii, to zastosujmy metody analizy przeżycia. Przedstawmy czas działania ekranu/baterii za pomocą krzywych przeżycia (np. Kaplan-Meier) i sprawdźmy czy marki różnią się używając np. testu log rank (w R funkcja survdiff {survival}, więcej o teście).
Ale…
Obserwujemy dwa zdarzenia, uszkodzenie ekranu lub uszkodzenie baterii. Jeżeli wystąpi jedno uszkodzenie to nie widzimy drugiego (telefon oddajemy i nie wiemy kiedy nastąpiłaby druga awaria). Ale analizując uszkodzenia baterii, nie możemy traktować uszkodzeń ekranu jako obserwacje cenzorowane ponieważ nie musi być to cenzorowanie nieinformatywne (brak spełnionych założeń). Być może uszkodzony ekran wpływa na sposób pracy baterii, a być może wadliwe ekrany i baterie produkowane są w jednej fabryce, itp.

Podejście najmniej brutalne 4:

Skoro różne telefony obserwujemy przez różny czas, nie dla wszystkich znamy całkowity czas działania, czyli mamy cenzorowanie, ale obserwujemy dwa (lub więcej) elementów, które mogą ulec uszkodzeniu, to możemy modelować je łącznie używając modelu konkurujących ryzyk.

W R można to zrobić używając pakietu mstate (artykuł z JSS) czy też od jakiegoś czasu można to zrobić pakietem survival (teraz funkcja Surv{survival} może przyjąć argument type=mstate).
Do porównania krzywych można wykorzystać test Gray’s log-rank test. A w pakiecie ggplotit jest nawet przeciążona funkcja ggplotit() rysujące skumulowane funkcje zdarzeń dla obiektów klasy survfitms lub Cuminc.

btw:
Projekt na którym pracowałem dotyczył biologii molekularnej i analizy przeżycia pacjentów, ale dla przykładu i wnioskowania to akurat bez znaczenia. Podobna metodologię można zastosować do analizy usterek w samochodach czy kliknięć internautów na stronach www.

Dzień Popularyzacji Matematyki – w czwartek 15 IX 2016 – MiNI PW

screen-shot-2016-09-10-at-08-18-10

Już w czwartek (15 IX) na MiNI PW w godzinach 11-17 odbędzie się druga edycja Dnia Popularyzacji Matematyki.

Miejsca na warsztatach pozostały już nieliczne, ale na wielu wykładach jeszcze miejsca są.

Screen Shot 2016-06-08 at 18.42.39

Przejrzeć listę wykładów i warsztatów oraz zapisać można się przez stronę http://dpm.mini.pw.edu.pl/?q=og/1.
Jest wiele ciekawych propozycji.

A na 14:50-15:50 planowana jest MiNI gra terenowa ,,Łamacze Wykresów” w rozszyfrowywanie wykresowych łamigłówek.

Warsaw R Ladies – Warsztaty z R tylko dla kobiet

cut
Kolejne warsztaty w ramach Spotkań Entuzjastów R zaplanowane są na 20 października. To spotkanie będzie wyjątkowe, na ten dzień zaplanowane są dwa warsztaty tylko dla kobiet.
Spotkania R Ladies działają w Londynie, San Francisco i innych miastach. Na celu mają zwiększenie liczby entuzjastek R.

Poinformujcie znajome, które mogłyby być takimi warsztatami zainteresowane.

Planowane są dwa warsztaty (R dla początkujących / ggplot2 w wizualizacji danych), każdy po 20 osób. Miejsca mogą się skończyć szybko, więc warto je szybko zarezerwować.

Więcej informacji o wydarzeniu oraz formularz zgłoszeniowy znajduje się tutaj.

MinechaRts #1 (Minecraft + R + Edgar Anderson’s Iris Data)

How to use R to draw 3D scatterplots in Minecraft? Let’s see.

Minecraft is a game about placing blocks and going on adventures (source). Blocks are usually placed by players but there are add-ons that allow to add/modify/remove blocks through external API.
And this feature is being used in educational materials that show how to use Minecraft to learn Python (or how to use Python to modify Minecraft worlds, see this book for example). You need to master loops to build a pyramid or a cube. And you need to touch some math to build an igloo or a fractal. Find a lot of cool examples by googling ‘minecraft python programming’.

So, Python+Minecraft are great, but how to do similar things in R?
You need to do just three things:

  1. Install the Spigot Minecraft Server along with all required dependencies. The detailed instruction how to do this is here.
  2. Create a socket connection to the Minecraft Server port 4711. In R it’s just a single line

  3. Send building instructions through this connection. For example

    will create a cube 11x11x11 made of TNT blocks (id=46 is for TNT, see the full list here) placed between coordinates (0,70,0) (10,80,10). You can add and remove blocks, move players, spawn entities and so on. See a short overview of the server API.

The R code below creates a connection to the minecraft server, builds a flat grassland around the spawning point and plots 3d scatterplot with 150 blocks (surprise surprise, blocks coordinates correspond to Sepal.Length, Sepal.Width, Petal.Length variables from the iris dataset).

If you do not like scatterplots try barcharts ;-)

Mecze Matematyczne

Podczas wakacji dowiedziałem się o bardzo ciekawej inicjatywie, tj. o Dolnośląskich Meczach Matematycznych. Temat w sam raz na 1. września.

Dolnośląskie Mecze od kilkunastu lat organizuje Małgorzata Mikołajczyk z UWr. Od kilku lat rozgrywane są też mecze w ligach na Pomorzu i Wielkopolsce. W rozgrywkach udział biorą 10 osobowe zespoły, które wystawiają zainteresowane szkoły. Rozgrywki są prowadzone w ligach dla podstawówek, gimnazjów i liceów. W poprzednim roku można było się zgłaszać do końca października. Zespoły spotykają się parami aby rozegrać mecz. Zwycięzcy przechodzą dalej i tak aż do finałów.

Dokładny regulamin meczu znajduje się tutaj. Poniżej opiszę kilka cech, które najbardziej przypadły mi do gustu.

1) Zespoły mają po 10 osób. Zespoły mają godzinę na opracowanie rozwiązań, ale rozwiązania prezentowane są indywidualnie. Jedna osoba może przedstawić tylko jedno rozwiązanie. Wprowadza to do rozgrywki ciekawy element optymalizacji, gdzie zespół musi ustalić kto będzie prezentował które rozwiązanie.

2) W ocenie rozwiązania liczy się nie tylko końcowy wynik, ale (a nawet przede wszystkim) ścieżka wnioskowania i uzasadnienie wyniku. Jeżeli zaprezentowane wnioskowanie ma słabe strony (lub znacznie prostsze rozwiązanie), to drużyna przeciwna może je wytknąć przejmując część punktów. Konieczność argumentacji rozwiązania oraz analiza tej argumentacji ma niesamowitą wartość edukacyjną.

3) W tej rozgrywce matematycznej planowanie i praca zespołowa jest bardzo istotna aby wygrać mecz. To jest najbardziej niesamowity element całej rozgrywki. W zawodach ,,zespołowych” w których brałem kiedyś udział, wkład drużyny nie był taki ważny. Zespół mógł mieć jednego silnego zawodnika by mieć dobre wyniki. W DMM każde zadanie przedstawia inna osoba, więc nawet jeżeli część drużyny jest silniejsza to musi wyjaśnić reszcie cześć rozwiązań.

Przyznacie, ciekawa inicjatywa. Czy znacie coś podobnego w Warszawie?

Nagrania z ICML 2016

Przeglądając zaległe wiadomości z wakacji trafiłem na link do nagrań referatów i warsztatów z konferencji International Conference on Machine Learning (ICML). Są one dostępne na stronie http://techtalks.tv/icml/2016/.

Dlaczego warto się im przyjrzeć? Susan Athey określiła ICML jako Hottest conference in the hottest area (oczywiście różne obszary są gorętsze dla różnych osób). Referatów jest wiele, póki co obejrzałem tylko sesje plenarne (te zazwyczaj są bardzo dobre lub wyśmienite).

Do gustu przypadły mi referaty o analizie dużych grafów Mining Large Graphs: Patterns, Anomalies, and Fraud Detection, analizie obrazu A Quest for Visual Intelligence in Computers i referat o analizie przyczynowo skutkowej Causal Inference for Policy Evaluation (trzy na pięć).

Wszystkich nagrań jest bardzo wiele, ale jeżeli znacie jakieś warte polecenia to śmiało sugerujcie w komentarzach.

Statystyk na wakacjach

Miejsce: Park rozrywki w Szklarskiej Porębie, kolejka do kina 6D.
Aktorzy: [S]taystyk na wakacjach i [B]ileterka.
Czas: 14:55, na 5 minut przed seansem w ww. kinie. Seanse odbywają się co 30 minut. Przed wejściem ustawia się kolejka. 10 minut przed seansem osoby z kolejki zaczynają wchodzić do kina. Wchodzi pierwsze 25 osób.

– Na ten seans już nie ma miejsc, proszę przyjść na kolejny o 15:30 – informuje Bileterka.
– A ile minut przed seansem powinienem przyjść by były jeszcze miejsca? – grzecznie pyta Statystyk.
– 5 minut przed seansem, tak jak jest napisane w regulaminie – Bileterka wskazuje palcem regulamin.
– Ale teraz jestem 5 minut przed seansem i już nie ma miejsc – zauważa Statytyk. – Więc ile minut wcześniej powinienem przyjść aby były jeszcze miejsca? – docieka.
– To zależy od tego ile osób przyjdzie. Musi być Pan najpóźniej 5 minut przed seansem. – powtarza Bileterka zniecierpliwionym głosem.
– A ile minut przed seansem się zazwyczaj kończą bilety? – dopytuje Statystyk.

Mniej więcej tutaj dla mojej interlokutorki staje się jasne, że trafił się jej wyjątkowo dociekliwy/upierdliwy (strony mogą różnie określać tę cechę) osobnik. Jej odpowiedź jest już bardziej stanowcza.

– Różnie się kończą. To zależy ile osób przyjdzie na kolejny seans. A tego nikt nie wie – rozmówczyni niesłusznie zakłada, że odstraszy mnie brak precyzyjnych szacunków.

W tym miejscu przerwę relacjonowanie naszej rozmowy. Na kolejny seans przyszedłem 10 minut przed czasem i wszedłem mniej więcej w połowie kolejki.

Ale historia dopiero tutaj się zaczyna.

Przez kolejne dwie godziny moje szkraby szalały na dmuchańcach obok kina. Miałem trochę czasu by poobserwować kolejkę do kina, zebrać trochę danych i zastanowić się, jak sam bym odpowiedział na pytanie, które zadałem Bileterce.

Zagadnienie:

Oszacować ile minut przed seansem należy przyjść aby mieć 90% pewności, że wystarczy dla nas miejsc w kinie.

Dane:

Dla 4 seansów (dwie godziny obserwacji) mamy informację ile osób (najczęściej przychodzą całe rodziny) i ile minut przed seansem dołączyło do kolejki.

Model 1:

Rozwiązanie brutalne, praktycznie bez modelowania.
Dla każdego seansu liczymy ile minut przed seansem przyszła ostatnia osoba, która zmieściła się na sali. Dla naszych seansów było to odpowiednio 8,9,7,8 minut.

Rozwiązanie proste o uroku cepa. Bez modelu parametrycznego z czterech liczb trudno wyznaczyć 90% kwantyl. (Ok, można jeżeli jest się ultrasem bootstrapowcem).

Szukamy więc czegoś parametrycznego.

Model 2:

Zakładamy, że liczba osób dochodzących do kolejki opisana jest jednorodnym procesem Poissona.
Oznacza to, że zakładamy, że w pewnym okresie czasu, np. -15 do -5 minut przed seansem, chętni przychodzą pojedynczo ze stałą intensywnością (=nie w stałych odstępach czasu ale ze stałem prawdopodobieństwem pojawienia się).
Więcej o procesie Poissona np. tutaj.

I co dalej? Szacujemy intensywność przychodzenia osób (w tym modelu to średnia) i liczymy czas oczekiwania na przekroczenie przez proces Poissona bariery 22 osób (jeszcze my się musimy zmieścić).

Piękny parametryczny model.
Drażniące są tylko te nierealne założenia.
Może da się je osłabić.

Model 3:

Zakładamy, że liczba osób dochodzących do kolejki opisana jest złożonym procesem Poissona.
Złożony proces Poissona to połączenie zwykłego procesu Poissona (opisuje momenty, w których do kolejki dochodzi rodzina) oraz skoków o różnej wielkości (wielkość skoku to liczba osób w rodzinie, które dołączyły do kolejki, z obserwacji od 1 do 5, najczęściej 2-3). Jest to rozszerzenie modelu 2, w którym uwzględniamy to, że do kolejki na raz dołączyć może kilka osób.
Więcej o złożonym procesie Poissona np. tutaj.

I co dalej? Osobno szacujemy intensywność pojawiania się rodzin (podobnie model z jednym parametrem szacowanym średnią), osobno szacujemy rozkład wielkości rodziny. Mając te składowe, wyznaczamy (np. symulacyjnie) rozkład czasu przekroczenia bariery 22 osób.

Model coraz piękniejszy, wymaga estymacji parametrów dwóch rozkładów (czasu przyjścia i wielkości rodziny). Drażni jedynie to założenie o stałej intensywności pojawiania się rodzin na odcinku -15 min do -5 min przed seansem.

Model 4:

Wykorzystajmy złożony niejednorodny proces Poissona. Czyli to co powyżej, ale tym razem intensywność pojawiania się rodzin jest nieujemną funkcją na odcinku -30 min do -5 min. Na początku raczej bliska zera (kto ustawia się w kolejce na 20 minut przed seansem gdy nikt inny w kolejce nie stoi?) a później szybko skacząca w czasie -15 min do -5 min przed seansem (nauczeni doświadczeniem wiedzą, że warto zjawić się wcześniej).
To już jest TEN model. W zmiennej intensywności możemy nawet uwzględnić porę dnia, liczbę osób przebywających w parku rozrywki i kilka innych parametrów. Samą intensywność można szacować np. estymatorem jądrowym.

Jedynym problemem okazało się to, że o 18 zamykali park i nie dało się zebrać więcej danych.

Więcej o niejednorodnym procesie Poissona można przeczytać tutaj.

Inne pomysły na modele?

[*] Ilustracja pochodzi z opowiadania ,,Jak długo żyją Muffinki”.

Liczba medali na olimpiadzie w Rio a wielkość kraju


Zastanawiałem się, czy liczba medali zdobytych na olimpiadzie w Rio koreluje z wielkością kraju.

Dane o populacji krajów można pobrać z wikipedii. O liczbie medali np. z serwisu wp.pl. Pobieramy dane pakietem XML i rysujemy pakietem rbokeh (interaktywna grafika, nadająca się na strony www).
Kod R dla obu tych operacji jest tutaj).

Otrzymujemy taki wykres (obie osie są w skali logarytmicznej). Korelacja Spearmana wynosi 0,44. Polska jest w okolicy 33 miejsca na obu osiach.

Wnioski? Korelacja jakaś jest. Co prawda są odstępstwa, częściej są to duże kraje o małej liczbie medali (Indie, Nigeria), rzadko odstępstwa dotyczą małego kraju o dużej liczbie medali.

BetaBit#3: nowa mini gra dla przyjaciół funkcji lm()

Wakacje w pełni. Dla tych, którzy chcieliby rozerwać się przy konsoli RStudio, mamy nową mini-grę z serii BetaBit. Gra nazywa się regression() i może być sporym wyzwaniem, o ile nie jest się bliskim przyjacielem funkcji lm().

Aby zagrać, należy zainstalować i włączyć wersję 1.3 pakietu BetaBit. Np. poleceniami

install.packages("BetaBit")
library("BetaBit")

Grę opracował Tomasz Żółtak. Podczas gry, w ramach wakacyjnego stażu, Beta i Bit pomagają profesorowi Pearsonowi w analizie pewnych danych edukacyjnych. Po rozwiązaniu wszystkich zadań prof. Pearson uraczy nas sentencją, która jest rozwiązaniem gry.

Przyjemnej rozrywki!

Osobom, które przyślą do końca sierpnia ww. sentencję wraz z rozwiązaniami zadań, prześlę kubek Bety (pierwsze 5 poprawnych zgłoszeń) lub opowiadania BetaBit (pozostałe rozwiązania).

Bez względu na to czy uda się czy nie rozwiązać wszystkie etapy, będę zobowiązany za wnioski, pomysły i komentarze dotyczące tej lub pozostałych gier z serii.

Rozwiązania i komentarze można wysyłać na przemyslaw.biecek na serwerze gmail.com.