Voorspelling Verkiezingen

Verkiezingen Hackathon groot succes

Verschillende media meldden afgelopen week dat 75 procent van alle stemgerechtigden nog twijfelt tussen twee of meerdere partijen voor de Tweede Kamerverkiezingen van aanstaande woensdag. In die wetenschap togen de ruim 60 deelnemers aan de Verkiezingen Hackathon, georganiseerd door The Analytics Lab en Cmotions, afgelopen vrijdag naar Utrecht om deel te nemen aan de tweede editie van dit evenement. Elf teams, uit onder meer de financiële sector, energie-, automotive- en verzekeringsbranche, trachtten – ondanks de nog grote twijfels onder het electoraat – de zetelverdeling van de aanstaande verkiezingen zo goed mogelijk te voorspellen.

Hackathon_nogstarten

 

Om 14:00 uur werd het startschot gegeven door de organisatie, die zichzelf voor de gelegenheid hadden omgedoopt tot voorzitters van onder meer de Partij van de Analyses (PvdA), Volume and Value of Data (VVD), Correcte en Degelijke Analyses (CDA) en de Statistisch Georganiseerde Partij (SGP). De Partij Voor de Vrijheidsgraden (PVV) liet verrassend genoeg verstek gaan tijdens het debat. Nadat de stemlokalen waren geopend analyseerden en modelleerden de fanatieke deelnemers er lustig op los. Hierbij werd gebruik gemaakt van gerenommeerde technieken, waaronder Random forest modellen en neurale netwerken, maar ook de creatieve geesten konden hun energie ruimschoots kwijt. Zo baseerde een van de teams haar voorspellingen op Kamergotchi-data en viel het team van RDC terug op hun kennis van de Nederlandse automarkt door middel van de ‘Krol-correctie’: het verschijnsel dat ouderen steeds hippere auto’s kopen en zich daarmee distantiëren van het 50-plus-label dat hen door de lijsttrekker van de ouderenpartij wordt toebedeeld. Ook de samenhang tussen het aantal verkopen van rode auto’s en de zetels voor de SP in de zogenaamde ‘SP-coëfficient’, kwam uit de koker van het RDC.

Hackathon_aanhetwerk

 

Vanaf 17:30 druppelden de uitslagen uit de verschillende delen van het land bij de organisatie binnen en werden de stemmen geteld. Nadat ook de MARUG (Marketing Associatie Rijksuniversiteit Groningen) – zoals het echte studenten betaamt – keurig één minuut voor de deadline hun voorspellingen instuurde, maakten de teamcaptains zich op voor het grote lijsttrekkersdebat. Hierin werd de deelnemers gevraagd naar hun gebruikte tactieken en modelleringstechnieken. Ondanks de grote variëteit in gebruikte bronnen en analysemethoden, waren de deelnemers redelijk eensgezind in de zetelverdeling, met een maximale spreiding van zeven zetels voor de verschillende politieke partijen. Grootste uitschieter was het aantal voorspelde zetels voor de PvdA door team van de MARUG. Ondanks dat deze partij tegen het herstel van de basisbeurs voor studenten is, werd de PvdA door de studenten liefst 29 stoelen in de Tweede Kamer toebedeeld.

Hackathon_lijsttrekkersdebat

 

Als aanstaande woensdag de verkiezingsuitslag bekend is, wordt aan de hand van ‘Root Mean Square Error’ methode bepaalt welk team zich de winnaar van de tweede editie van The Analytics Lab Hackathon mag noemen en de felbegeerde voorzittershamer in ontvangst mag noemen.

Voorspelling Verkiezingen

traffic-1782527_960_720

10 artikelen over data en verkiezingen

Nu de deelnemers van onze hackathon in de startblokken staan om morgen de meest fantastische voorspellingen van de verkiezingen te maken, willen wij ze nog even inspireren met een paar mooie artikelen/websites over data en verkiezingen.

Succes morgen allemaal!

  1. Nieuwe peiling methode in Nederland
  1. Aantal peilingen samengebracht
  1. Waarom er bijna geen verandering is in de peilingen
  1. Waarom zagen de peilingen de overwinning van Trump niet aankomen
  1. Hoe Trump data analyse inzette om de verkiezingen te winnen
  1. Hoe Nederlandse politieke partijen data analyse inzetten om stemmen te winnen
  1. Google populariteit van partijen en lijsttrekkers
  1. Goede voorspeller van verkiezingen in Science
  1. Belang social media in verkiezingen
  1. Rol facebook in verkiezingen NL
Blog_header

Doe mee met The Analytics Lab Verkiezingen Hackathon!

Twee weken voor de Tweede Kamerverkiezingen in 2012 stond de SP in de peilingen op 35 zetels, de partij behaalde uiteindelijk met 15 zetels nog niet de helft van het door peil.nl voorspelde aantal stoeltjes op het Binnenhof. De PvdA daarentegen, klom in de laatste weken uit het dal: waar 18 zetels verwacht werden, belandde Diederik Samsom met een 38-koppen tellende fractie in de Tweede Kamer en werd daarmee, achter de VVD, de tweede partij van Nederland.

(Dat de Brexit er daadwerkelijk zou komen, werd door niemand voorspeld. Donald Trump had aan de vooravond van de Amerikaanse verkiezingen volgens de experts 15% kans om te winnen, de rest is geschiedenis…)

Wat zijn de drijvende krachten achter en voorspellende waarden van de opiniepeilers? Mogen we wel over peilers spreken, of bepalen de peilingen de publieke opinie dusdanig dat we kunnen spreken van opiniemakers?

In een maatschappij waarin nog maar 30% van de kiezers trouw is aan één partij en het populistische gedachtegoed aan zowel de linker- als rechterkant van het politieke spectrum hoogtij viert, wordt het steeds moeilijker om de denkwijze van het electoraat in het stemhokje te voorspellen.

Desondanks gaan wij de uitdaging aan. In deze hackathon, georganiseerd door The Analytics Lab en Cmotions, staan de Tweede Kamerverkiezingen centraal. Wie wordt de opvolger van Emesa, die de eerste editie van dit fantastische evenement op haar naam wist te schrijven!?

Wegens het grote aantal aanmeldingen is het helaas niet meer mogelijk om je nog aan te melden voor de hackathon. Maar houd onze website en nieuwsbrief in de gaten, want er komt zeker nog een volgende waar we je graag zouden verwelkomen!

 

Voor meer informatie mail naar info@theanalyticslab.nl

Blog_header

Leer R met de Experience R. Schrijf je nu in!

Als (data) analist ben je altijd bezig met hoe jij jouw organisatie kan helpen met betere inzichten en modellen. Jouw innovativiteit wordt beperkt door de mogelijkheden die je hebt in de tool waarmee je werkt. Wij willen je graag helpen en je introduceren in R, een flexibel open-source programma waarbij de community ervoor zorgt dat state-of-the-art technieken al ingezet kunnen worden voordat jij het maar hebt kunnen bedenken.

Wil jij je graag verder ontwikkelen en innovatief bezig zijn in het Data Science vakgebied; schrijf je dan nu in voor onze Experience R!

De Experience R bestaat uit een zestal modules van vier uur. De eerste module geeft een introductie in R en Rstudio, vervolgens leer je hoe je data moet importeren vanuit verschillende bronnen, hoe je data kan manipuleren en transformeren, moet prepareren voor modelbouw en uiteindelijk het modelleren zelf. De visie van de laatste dag is ‘Putting it all together’, waarbij je het ‘R Template’ krijgt. Dit is een standaard script in R met als doel om met minimale aanpassingen een classificatie model te bouwen.

Praktische informatie:

  • Wanneer: wekelijks van woensdag 15 maart  t/m woensdag 19 april 2017
  • Tijd: van 13:00 tot 17:00 uur
  • Waar: The Analytics Lab, Atoomweg 50, 3542 AB Utrecht
  • Inschrijven vóór: woensdag 1 maart 2017
  • Kosten: 1.950 euro per persoon (voor zes modules)
  • Minder modules nodig: neem contact met ons op

 

Module_overzicht_grijze_achtergrond

 

Happy New Year

Fireworks (in R)

New Year – a new chapter, new verse, or just the same old story ? Ultimately we write it. The choice is ours. ― Alex Morritt

The Analytics Lab and Cmotions wish everybody a happy year. A year full of challenges, new experiences and new knowledge.

Happy New Year

Read more

ChristmasTree

Christmas Tree with ggplot

ChristmasTree

rm(list = ls())
library(ggplot2)

# create data
x <- c(8,7,6,7,6,5,6,5,4,5,4,3,4,3,2,3,2,1,0.5,0.1)

dat1 <- data.frame(x1 = 1:length(x), x2 = x)
dat2 <- data.frame(x1 = 1:length(x), x2 = -x)
dat1$xvar <- dat2$xvar <- NA
dat1$yvar <- dat2$yvar <- NA
dat1$siz <- dat2$siz <- NA
dat1$col <- dat2$col <- NA

# set threshold for christmas balls
dec_threshold = -0.5

# create random places, sizes and colors for christmas balls
set.seed(2512)
for (row in 1:nrow(dat1)){

if (rnorm(1) > dec_threshold){

dat1$xvar[row] <- row
dat1$yvar[row] <- sample(1:dat1$x2[row]-1,1)
dat1$siz[row] <- runif(1,0.5,1.5)
dat1$col[row] <- sample(1:5, 1)
}

if (rnorm(1) > dec_threshold){

dat2$xvar[row] <- row
dat2$yvar[row] <- sample(1:dat2$x2[row],1)
dat2$siz[row] <- runif(1,0.5,1.5)
dat2$col[row] <- sample(1:5, 1)
}
}

# plot the christmas tree
ggplot() +
geom_bar(data = dat1, aes(x=x1, y=x2),stat = "identity", fill = '#31a354') +
geom_bar(data = dat2, aes(x=x1, y=x2),stat = "identity", fill = '#31a354') +
geom_point(data = dat1,aes(x = xvar, y = yvar, size = siz, colour = as.factor(col)) ) +
geom_point(data = dat2,aes(x = xvar, y = yvar, size = siz, colour = as.factor(col)) ) +
coord_flip() + theme_minimal()+ theme(legend.position="none",
axis.title.x=element_blank(),
axis.text.x=element_blank(),
axis.ticks.x=element_blank(),
axis.title.y=element_blank(),
axis.text.y=element_blank(),
axis.ticks.y=element_blank()) +
ggtitle('The Analytics Lab wishes you a Merry Christmas')


FcXpQ

R

How to remove all user installed packages in R

A little while ago I ran into an issue with R and RStudio. In order to solve this issue I saw myself forced to remove all user installed packages. For a lot of practical reasons it was not an option for me to simply uninstall R and start with a clean slate and a new installation of R.

Therefore I had to find another solution which could help me with removing all user installed packages. I found a few useful tips and tricks, but nothing that immediately did the job for me. That’s why I’ve decided to share my solution, I hope this can help you in the hour of need.

Here is the script I’ve created in order to remove all user installed packages, without removing any base packages for R or MRO.

# create a list of all installed packages
 ip <- as.data.frame(installed.packages())
 head(ip)
# if you use MRO, make sure that no packages in this library will be removed
 ip <- subset(ip, !grepl("MRO", ip$LibPath))
# we don't want to remove base or recommended packages either\
 ip <- ip[!(ip[,"Priority"] %in% c("base", "recommended")),]
# determine the library where the packages are installed
 path.lib <- unique(ip$LibPath)
# create a vector with all the names of the packages you want to remove
 pkgs.to.remove <- ip[,1]
 head(pkgs.to.remove)
# remove the packages
 sapply(pkgs.to.remove, remove.packages, lib = path.lib)
20161027_TALblog_Amsterdam_heatmap

How to combine Google Maps with a Choropleth shapefile of Holland in R: Amsterdam neighbourhoods (postal codes) by number of customers

Sometimes the best way to visualize your information is by plotting it on an map. But what if the information you want to show isn’t a point on a map but a shape, like a neighbourhood? Well, that’s when you use a choropleth, which you can create using a shapefile (look for ESRI shapefiles on Google). Usually the map is still recognizable when you simply use the shapefile. For example, the shapefile of Holland looks like this:
20161027_TALblog_Nederland

But when you zoom in on this map and, like I did, only want to visualize the postal code areas of Amsterdam. The map becomes unrecognizable and you have absolutely no clue of what you’re looking at:
20161027_TALblog_Amsterdam_shapefile

For this reason I wanted to combine this choropleth with a Google Map plot of the same area. In this way you can still recognize the city of Amsterdam and it’s neighbourhoods.
What I wanted to end up with was a heatmap, which showed the “intensity” for each neighbourhood of Amsterdam. In this case, the “intensity” showed was the conversion percentage of a campaign that was done in Amsterdam.

For this purpose we’ll need the following packages: ggmap, RgoogleMaps, maptools, rgdal, ggplot2, rgeos. So we’ll start by loading these packages.

 # install and load packages 
library(ggmap) 
library(RgoogleMaps) 
library(maptools) 
library(rgdal) 
library(ggplot2) 
library(rgeos)

Now that we have loaded all the necessary packages, we’ll move on by gathering the Google Maps view we need to plot the choropleth on. There are two ways to use the geocode function (ggmap package) to get the coordinates we want to use as the center of the map, either you use the name of the location or you just enter the coordinates yourself:

# get the coordinates of the center of the map you want to show
 CenterOfMap <- geocode("Amsterdam")
 CenterOfMap <- geocode("52.374,4.618")

You can use these coordinates to tell the get_map function (ggmap package), which part of the world you’re looking for. With the zoom variable you can define the area you want to see.

# get the map from google
Amsterdam <- get_map(c(lon = CenterOfMap$lon, lat = CenterOfMap$lat),zoom = 12, maptype = "terrain", source = "google")

Make sure you’ve downloaded the correct area of the world with the right zoom level.

# create and plot the map
AmsterdamMap <- ggmap(Amsterdam)
AmsterdamMap

Now we’ve got the map we can start with loading the data we want to show on the map.

# load the data you want to show in the choropleth
geo_data <- read.csv("Data.csv", header = T, sep = ";", dec = ",")

This dataset contains two columns:

  1. id, which contains the four digits of the Dutch postal codes;
  2. value, which contains the value I want to show on the map, in this case this is the conversion rate for each area.

 

Finally, we need to load the shapefile of Holland with the four digit postal areas. In order for Google to recognize the latitude and longitude of the shapefile we need to transform it.

# load the shapefile
shapedata <- readOGR('.', "ESRI-PC4-2015R1")
 # transform the shapefile to something Google Maps can recognize
shapedata_trans <- spTransform(shapedata, CRS("+proj=longlat +datum=WGS84"))

After having done this, we’re ready to combine all our files to create one stunning plot! We start by merging the shapefile with the data we want to plot.

# add an id to each row
shapedata_trans@data$id <- rownames(shapedata_trans@data)
# merge the data and the shapefile
shape_and_data <- merge(x = shapedata_trans, y = geo_data, by.x = "PC4", by.y = "id")

In merging these files it can happen that self-intersections arise, we want to make sure to remove them, since they’ll cause errors.

# repair self-intersections
shape_and_data_wsi <- gBuffer(shape_and_data, width = 0, byid = TRUE)

Lastly, we fortify the combination of the data and the shapefile and combine the resulting data with the original shapefile.

# fortify the shapefile to make it usable to plot on Google Maps
fort <- fortify(shape_and_data_wsi)
# merge the fortified shapefile with the original shapefile data
PC4 <- merge(fort,shape_and_data_wsi@data, by = "id")

We end up with a file we can combine with our Google Map plot we’ve created earlier.

# create the final map with the overlaying choropleth
AmsterdamMap_final <- AmsterdamMap + 
  geom_polygon(aes(x = long, y = lat, group = group, fill = value), size = .2, color = 'black', data = PC4, alpha = 0.8) +
  coord_map() +
  scale_fill_gradient(low = "red", high = "green") + 
  theme(legend.title = element_blank(), legend.position = "bottom")
AmsterdamMap_final

Which in the end leads us to this plot:
20161027_TALblog_Amsterdam_heatmap

I hope this blog can help and inspire you! If you have a better way to achieve the same, or maybe even a better, combination of a choropleth and Google Maps, please let me know! I’m always looking for better ways to visualize my data on a map.

Road

Building a Self Driving car

A few weeks back Elon Musk revealed the second part of his masterplan for Tesla, including self-driving cars and self-driving busses. Cars that can park itself outside the city centre or act like taxi’s, while you’re at work. Probably, the technical innovation isn’t the main bottleneck in the development of self-driving cars, it’s society’s attitude towards it. People are wired by nature to resist change and  are reluctant to adapt when they’ve got no control over it, even though it might improve their lives. A few weeks back, a Tesla car drove into a truck, thereby killing the passenger. Adversaries use this accident as an argument not to change. Tesla’s reaction was that it took 130 million auto-pilot miles before a lethal accident, while the US average is 94 million miles, making it actually immoral not to “drive” a self-driving car.

In my quest of the argument that technical innovation isn’t the bottleneck, I wanted to build my own self driving car. My equivalent of Elon’s Masterplan. Our Lab is the perfect place to figure out whether it’s possible, as it is for projects which have their foundation in curiosity and intrinsic motivation. In this article I’ll describe how I managed to build my own self driving car.

Hacking a car

First thing I needed was a car, I don’t think my boss would appreciate it if I were to hack my company car for this project, so I first decided to try it on a smaller scale. My younger brother got an RC car for his birthday about fifteen years ago, he was kind of to let me break it apart. Second thing I needed was a computer which I could connect to the car, I chose a Raspberry PI 2 as it’s cheap and small enough to fit on top of the car. With some trial and error I managed to reverse engineer the electrical circuits of the remote control and wired the Raspberry PI onto it. Had to dig deep into my memory for this, the last time I soldered was my first year in high school.

Attached to the Raspberry is also a camera, which is mounted at the front of the car, looking at the road ahead. The camera is the “eye” of the car, the idea is that the camera takes a picture of the road and that an algorithm figures out which direction the car needs to go.

SideviewFrontview

Learning the car to drive

In my living room I set out a “road” using a bunch A4 papers being the sides of the road. At this point, I need to apologize to my roommate, who was forced to live in a house for a while with road running through the living room.

On the RoadWhen the car drives on the road, it needs to decide whether to go left, right, forward or whether it needs to stop. The car constantly needs to make this decision. Before each decision the car takes a photo of the road. Our camera was set to take black and white photos of 50 by 50 pixels. A photo is actually just a bunch of data, every pixel has a certain value indicating the “whiteness” of the pixel, and with data we can do a bunch of stuff.

As, I wanted to learn the algorithm on the Raspberry Pi (and not on a more powerful computer), the first thing I wanted to do is reduce the number of pixels at which the car needs to look at. There’s a certain technique, called Feature Selection, which looks at which values are important in order to predict something. The following picture displays at which pixels the car is going to look in order to determine the next action the car has to take, on the left you see the pictures the car takes and on the right to which pixels the car looks. These are 370 instead of 2 500. You can see that most pixels are in the upper right or upper left corner. This makes quite some sense; if the side of the road appears in the upper right corner for example, the car needs to go left.

The final step is to build an algorithm that translates these data into patterns. The algorithm distinguishes, for each of the four actions, combinations of pixels that are white versus black. These patterns can be seen as the key between the photo and the action to take. Personally, this part was probably the most easy part to do, as we use this technique for all kinds of different projects.

Letting the car drive itself

Now we’ve taught the car how to drive, it’s time to set it free. After just five or six times driving car by hand, it was able to find its own way. In the small movie you see it drives a bit jerky, after each action it stops for a small moment. This is due to two reasons, first it needs to take a photo of the road ahead. If the car is in movement, the photo won’t be sharp; it’s like when you move your phone too much when you’re taking your selfie. If the photo is blurred, the algorithm will be less accurate. The second reason is that the algorithm needs some time; take a photo, process the data, predict the next decision and tell the car what to do. We’re asking quite a lot from a small computer.

It’s not perfect, but it’s at the stage where it can drive itself and keep learning if I correct it when it goes to the wrong direction. In other words, while driving, it learns to drive. Letting computers learn from experience, is called Machine Learning. Machine Learning is used more and more these days, for a wide range of different purposes. Here at Cmotions and The Analytics Lab we use Machine Learning techniques mainly to predict customer behaviour. We try to tackle questions like when is this particular customer going to end his subscription, who is likely to buy a certain product or which product suits the individual’s need the best? In this way, we facilitate companies to move from one-to-many approaches to one-to-one.

So, now what? Well step up the game and ask my boss if I can hack my company car, so that it can drive me from and to work while I check my email in the passenger seat or drive me home when I’ve had one too many. Maybe that’s a bit too ambitious for now, but I might program it in such a way that it gets a few beers from the fridge on Friday afternoons.

If you’ve got any questions, don’t hesitate to contact me. And if you have a 3d printer, definitely contact me. The car is still a cabrio and is looking for a roof, who can print me one?

Jeroen Kromme

j.kromme [at] Cmotions.nl
LinkedIn

Voetbal Hackathon (107)

Video & verslag: Emesa winnaar The Analytics Lab Voetbal Hackathon

De eerste editie van de voetbal hackathon is gewonnen door Emesa. Het e-commerce bedrijf, bekend van VakantieVeilingen.nl, bleek het beste in staat de uitslagen van een speelronde in de Engelse Premier League te voorspellen en ging er met de felbegeerde wisselbeker vandoor. Tijdens de voetbal hackathon, een initiatief van The Analytics Lab en Cmotions, werd op 15 april jl. door zeven teams fanatiek gemodelleerd om het fictieve budget van €1.000,- zo goed mogelijk te laten renderen.
Naarmate het speelweekeinde vorderde, begon zich een duidelijke kopgroep af te tekenen. Voorafgaand aan de laatste wedstrijd op maandagavond, was het een nek-aan-nek race tussen de Belastingdienst en Emesa, waarbij de uitslag van Stoke City – Tottenham Hotspur beslissend zou zijn. Titelkandidaat ‘Spurs’ maakte geen fout, won met 0-4 en bewees niet alleen zichzelf daarmee een goede dienst, maar ook het team van Emesa, dat zich hiermee kroonde tot winnaar van de hackathon.
Voetbal Hackathon (40)
Tijdens de prijsuitreiking gaf Thomas Stalman (links op de foto), de trotse aanvoerder van Emesa, toelichting over de winnende tactiek. Met Cruijffiaanse overtuiging legde hij uit met welke tactiek Emesa de strijd was aangegaan en in welke ‘opstelling’ hij zijn team had laten spelen. “We waren met drie personen, dus was het belangrijk een goede taakverdeling te maken. Een persoon heeft zich daarom gefocust op de datapreparatie, terwijl de andere twee vooral met het modelleren en inzetten bezig zijn geweest”, aldus Stalman. “De preparatie van de data hebben we gedaan met zowel R als SQL, voor het modelleren hebben we gebruik gemaakt van randomForest modellen in R om te voorspellen of een wedstrijd in een overwinning voor de thuis- of uitspelende ploeg, of een gelijkspel zou eindigen.” Stalman wees twee cruciale beslissingen aan als sleutel voor het succes: “Ten eerste hebben we er, gezien de relatief korte tijdsperiode, voor gekozen om alleen home, draw of away te voorspellen en de handicaps (waarbij een van de clubs met een fictieve 1-0 voorsprong begint, red.) links te laten liggen. Hierdoor konden we ons volledig focussen op het voorspellen van de uitslag van elke wedstrijd. Daarnaast hebben we alle data van bookmakers van de afgelopen 10 jaar gebruikt als voorspellende variabelen om ons model beter te laten presteren. Dit gaf ons de inzichten om fact-based bets te plaatsen.”
Voetbal Hackathon (107)
De honger naar prijzen is met het winnen van de eerste voetbal hackathon nog niet gestild, stelt Thomas Stalman. “Play-to-win is een van de core values van Emesa. Waar kunnen we dat beter laten zien dan tijdens een hackathon? Wij waren benieuwd hoe onze aanpak en technieken het zouden doen in vergelijking met de concurentie en zijn trots dat we als winnaar uit de bus zijn gekomen. Uiteraard doen we een volgende keer weer mee, ik wil alle teams van harte uitdagen om ons tijdens de volgende editie te verslaan.”
Door het enthousiasme en fanatisme van zowel de organisatie als alle deelnemers, mag de eerste editie van de Voetbal Hackathon van The Analytics Lab en Cmotions een groot succes genoemd worden. De voorbereiding voor een volgende editie zijn, mede dankzij de uitstekende input van de deelnemers, reeds in gang gezet. Mocht je suggesties hebben voor een thema of andere ideeën hebben, neem dan contact met The Analytics Lab op. Houd voor informatie over een volgende hackathon onze website en social media kanalen in de gaten!