salonanarchist | leunstoelactivist

Cursus statistiek

Bij de eerste zin van het mailbericht dacht ik dat het om spam ging:

Hi DIRKMJK,
I am writing you to ask a personal favor. I am trying to break the student record for the largest online class ever taught with my new class “Intro to Statistics”, which will begin June 25th. Sign up, forward this e-mail to your friends and family and let’s set a new record! […]
Thanks,
Sebastian Thrun, Professor

Geen spam dus, maar een gratis online statistiekcursus van Udacity. Daar heb ik al eens een les over Python bekeken (vandaar dat ze m’n mailadres hebben) en die was ok. Statistiek beter snappen is altijd nuttig, dus ik heb me ingeschreven.

Tags: 

Waarom de iPhone denkt dat ik 16km/u loop

Net als bijna iedereen heb ik de mp3-hardloopcursus van Evy – ‘Komaan, dat kun jij best!’ – Gruyaert gevolgd. De lessen bestaan uit een mix van lopen en wandelen. Het is de bedoeling dat je steeds meer loopt en steeds minder wandelt, waardoor de gemiddelde snelheid oploopt, tot je aan het eind van de cursus in een half uur ongeveer 5 km loopt. Volgens de Runmeter app op de iPhone ging ik bij les 28 en 29 al een stuk sneller. Ik begon al een beetje te wennen aan het idee dat ik misschien wel een speciaal talent heb voor hardlopen, maar tegelijk groeide de twijfel of de meting wel klopt. Zeker toen de gemiddelde snelheid bij les 30 weer dramatisch omlaag ging.

M’n eerste ingeving was dat het aan de gps zou kunnen liggen. Als je hieronder routes 29 en 30 vergelijkt dan zie je dat de gps de ene keer inderdaad beter werkt dan de andere keer. Het zou goed kunnen dat de app bij les 29 een te lange afstand heeft gemeten, wat weer zou kunnen verklaren waarom hij op zo’n hoge gemiddelde snelheid uitkomt. Uit nieuwsgierigheid heb ik in plaats van rondjes in het park een paar keer een min of meer rechte route gelopen. De gps lijkt daar beter mee uit de voeten te kunnen en komt dan niet meer op zulke extreem hoge snelheden uit.

Toch was ik niet overtuigd dat het alleen aan de gps lag. Volgens de Runmeter zou ik bij les 28 maar 24 minuten hebben gelopen, terwijl de bijbehorende mp3 ruim 29 minuten duurt. Ik besloot de snelheden opnieuw te berekenen met behulp van de duur van de mp3 in plaats van de tijdmeting van de app. Het resultaat is de groene lijn op de grafiek hieronder (methode 2). Met deze methode worden de uitschieters in de grafiek wat minder extreem.

Op zich lijkt deze berekening realistischer dan de snelheden die de Runmeter heeft berekend, maar dat impliceert dat de tijdmeting van de iPhone niet goed werkt, wat ik me eigenlijk nauwelijks voor kan stellen. Maar na enig zoeken kwam ik een artikel tegen waarin stond dat de stop detection van de Runmeter soms hapert.

De stop detection onderbreekt de tijdmeting als je stilstaat, bijvoorbeeld voor een stoplicht. Nou zijn er in het park geen stoplichten, dus de stop time zou nul moeten zijn. Toch bleek dat Runmeter bij sommige lessen een totale stop time had gemeten die oploopt tot ruim 5 minuten (inderdaad, dat was les 28). Wellicht zorgen gps-fouten ervoor dat de app af en toe ten onrechte denkt dat je stilstaat (bij les 1 was er een extreem lange stop time waar ik geen verklaring voor heb).

Als je de stop time optelt bij de run time dan kom je uit op een totale tijd die ongeveer gelijk is aan de duur van de mp3, waarmee de puzzelstukjes op hun plek lijken te vallen. Voor de volledigheid heb ik nog de gemiddelde snelheid berekend op basis van run time + stop time (de grijze lijn op de grafiek hierboven) en dat levert inderdaad vrijwel dezelfde snelheden op als methode 2. Al met al is m’n voorlopige conclusie dat de Runmeter het beste werkt als je stop detection uitzet en geen rondjes loopt.

Summary: 

Towards the end of an mp3 running course, the iPhone Runmeter app measured improbably high speeds. Part of the explanation appears to be inaccurate gps, which can be remedied by running in a more or less straight line rather than running in circles in the park. There also appeared to be a problem with time measurement. I first calculated average speed using the mp3 duration rather than the run time recorded by the Runmeter (green line on the graph). Then I realised that the stop detection setting of the Runmeter probably caused the problem. Calculating average speed by adding stop time to the run time (grey line) produced almost exactly the same results as the second method (because run time + stop time is almost identical to mp3 duration).

Tags: 

Correctieknop op Twitter

Twee weken geleden werd in Amerika een website gelanceerd waar alle verwijderde twitterberichten van politici zijn terug te vinden. In Nederland werd zo’n site twee jaar geleden al opgezet door Hack de Overheid en sindsdien is het idee in 12 landen overgenomen.

Het terughalen van verwijderde twitterberichten klinkt spannend, maar volgens Bright gaat het vooral om berichten met tikfouten of zinnen die niet zo goed lopen. Voor dat soort situaties is er een elegantere oplossing te bedenken, vindt ontwerper Oliver Reichenstein van Information Architects. Hij pleit voor een correctieknop waarmee je een bericht niet verwijdert, maar de tekst doorstreept:

A strike through means: “This is just wrong, ignore it and look for a follow-up of this if you’re interested.” Unlike the deleted tweet that leaves a black hole ripe for interpretation, the strike through hints at a follow-up down the stream that corrects the mistake. A stupid idea? Fuck yYou might be right, but you have to agree that information that is struck through has a funny magic that might spice things up.

Naar verluidt sputtert Twitter nog een beetje tegen.

Rijke buurt, meer bomen?


De Amerikaanse journalist Tim De Chant heeft bedacht dat je met Google Earth rijke en arme buurten zou moeten kunnen opsporen door te kijken hoeveel bomen er staan (via Flowing Data). Onderzoek zou hebben aangetoond dat rijke buurten groener zijn.

Dat laatste lijkt misschien een open deur, maar in Amsterdam zijn er arme buurten met veel groen en rijke buurten met weinig groen. Betekent dit dat de correlatie tussen inkomen en groen niet opgaat voor Nederland? Dit valt na te gaan met de kerncijfers wijken en buurten van het CBS. Die bevatten cijfers over de gemiddelde afstand tot openbaar groen (terrein in gebruik als park of plantsoen, voor dagrecreatie, natuur of als bos). De meest recente cijfers zijn uit 2006.

Er blijkt inderdaad een statistisch significante correlatie te bestaan: hoe rijker de inwoners, hoe korter de gemiddelde afstand tot openbaar groen. De correlatie is niet heel sterk: 0,20 op gemeenteniveau en nog wat zwakker op wijk- en buurtniveau.

Volgens de CBS-cijfers wonen de niet zo rijke inwoners van Littenseradiel gemiddeld op meer dan 4km afstand van openbaar groen. Als je een luchtfoto van die gemeente bekijkt dan blijkt de omgeving hardstikke groen, maar dat is waarschijnlijk boerenland en geen openbaar groen. Dat er in rijke gemeenten als Bloemendaal veel bomen staan geloof ik ook zonder Google Earth wel.

Summary: 

According to American journalist Tim De Chant it should be possible to tell rich neighbourhoods from poor ones using Google Earth, because income and urban trees are correlated. In Amsterdam, this correlation is not so obvious. Using national data at city-level, however, I found a not very strong (0.20) but statistically significant correlation between income and the average distance to parks, forests and other green areas.

Tags: 

Pages