GSOC 2012 – Congratulations to the selected students!

Hi, I want to congratulate the four selected students for python-statsmodels! Their projects are very interesting and important to statsmodels, so I wish them to succeed during this summer and hope they have fun!

I wasn’t selected, but will work on my project anyways, since I have to do it for my doctorate thesis. Since I have not been selected, I can finish my Masters Thesis first, and then only continue to work on my project, meaning I’ll start working on it seriously at the beginning of July. Before that, I’ll only be able to work on it if I find some spare time.

Of course, I’ll use this blog to share my advancements, and keep people up-to-date!

I also wanted to thank Skipper Seaboald, Wes McKinney and every person from the statsmodels project for making me contribute to statsmodels, for their encouragement and dedication.

Econometric game 2012

Hi
tomorrow morning I depart for the Netherlands to participate at the Econometrics Games 2012 in Amsterdam, with my team from the University of Strasbourg. I’ll post pictures and details when I’ll come back. You can read more about the games at: http://www.econometricgame.com/
Wish me good luck!

GSOC 2012: Extend python-statsmodels to handle dynamic linear models

Hi everybody!

 

This post marks my second post in English and I will talk about the Google Summer of Code and my proposal to python-statsmodels. If you don’t know what the Google Summer of Code, or gsoc is, you can read about it here: https://code.google.com/soc/

 

Basically, the gsoc is a bunch of students working on free software (free as in freedom, or software libre) during the summer for various firms or free software projects. These students make proposals, and if they get selected they get to work on their proposals for 13 weeks and get paid by Google.

 

I started coding in Python some time ago, and plan on using it for my thesis work; for now I’m working on my Masters Thesis that deals with Markov-Switching DSGE models and the Great Moderation, but I have to use Matlab, since all the code I need is only available on Matlab. For now. What I plan to do is port all this, or the most important parts at least, to Python. Of course I looked on the Internet to see if other people were interested, and after meeting Skipper Seabold on the Scipy mailing list, he told me about python-statsmodels which is a project whose goal is to make Python a full-fledged statistical analysis software.

 

So I decided to begin contributing to statsmodels. For now, I haven’t done much unfortunately, since my Masters Thesis eats up most of my time, but I started working on gensys. Gensys is a function that was originally written by Christopher Sims for Matlab, Octave and R, and solves linear rational expectations models. Solving such models is the first part in estimating them. Let me explain.

 

Let’s imagine you want to estimate, using Bayesian inference, or maximum likelihood, a DSGE model. You begin by solving the optimization problems of the agents that live in your economy, collect all these optimality conditions and log-linearize them around their steady-state values. You get a matrix system:

 

A1 X(t) = A0 X(t-1) + C eps(t)

 

what you want is to have this system in the following form:

 

X(t) = G1 X(t-1) + impact eps(t)

 

This is called a transition equation. The code is available here: https://github.com/cbrunos/statsmodels/tree/dsge/statsmodels/dsge

 

For now it doesn’t work, but I plan on getting back to it soon enough. I will probably rewrite it from scratch by taking inspiration on the R version of gensys, which seems more up-to-date that the Matlab version.

 

So implementing gensys in Python will be the very first step of my gsoc work; I’ll then continue with a Kalman Filter written in Cython for maximum speed which is need to evaluate the likelihood of such dynamic linear models. You can read the details of my proposal here: https://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/cbrunos/1

 

Anyways, if I get selected this is where I’ll share my gsoc adventures with you guys!

Utiliser R et JAGS pour estimer un modèle avec l’approche bayésienne

Bonjour,

pour faire suite à billet nous allons voir aujourd’hui une application sur des données simulées.

Pour commencer, il faut installer R, Rstudio et JAGS (lien pour windows). Sous Ubuntu, et probablement aussi sur d’autres distributions linux, R et JAGS se trouvent dans les dépôts, mais pas encore Rstudio. Pour Windows, suivez les liens précédents, et JAGS se trouve ici pour OSX. Rstudio est facultatif, ce n’est qu’une interface pour R, mais à mes yeux la meilleure, je vous conseille de l’essayer.

Une fois tout ça installé, démarrez R et installez les librairies suivantes: rjags, R2jags, R2WinBUGS, coda. Pour cela, vous pouvez soit utiliser l’interface de Rstudio, soit taper le code suivant dans la console:

install.packages("rjags")
install.packages("coda")
install.packages("R2jags")
install.packages("R2WinBUGS")

Une fois que tout cela est installé, nous pouvez procéder à l’estimation d’un modèle. Nous allons simuler des données et commencer par un modèle linéaire très simple. On commence par rentrer le code suivant:


rm(list=ls())
set.seed(1234)
setwd("home/utilisateur/Mon/chemin/exemple/")
n=30
beta=c(2,5)
x=rnorm(n, mean=0, sd=1)
x=cbind(1,x)
eps=rnorm(n, mean=0, sd=0.5)
y=x%*%beta+eps

Jusque là, rien de bien méchant. On génère 30 observations x_i et eps_i tirés dans la loi normale centrée réduite et dans la loi normale de moyenne nulle et écart-type 0.5 respectivement, on définit beta, le vecteur des vraies valeurs du paramètre et ensuite on construit y en utilisant tout ça. Maintenant il faut écrire le modèle JAGS; JAGS est un acronyme pour «Just Another Gibbs Sampler». Comment ça marche? Rappelez-vous, pour faire de l’économétrie bayésienne, il faut spécifier une vraisemblance, et des aprioris. La multiplication de la vraisemblance et des aprioris donne la distribution aposteriori des paramètres. Dans certains cas, si la vraisemblance est très complexe, cette multiplication peut donner lieu à la formation d’une distribution aposteriori des paramètres qui s’avère très complexe, donc on utilise un algorithme pour simuler cette distribution sur laquelle on va ensuite baser nos inférences. L’algorithme pour simuler cette distribution aposteriori est l’argorithme de Gibbs ou des fois c’est celui de Metropolis-Hastings qui est utilisé. JAGS automatise tout cela et est très simple à utiliser. Dans Rstudio, cliquez sur Fichier, puis Nouveau et puis document texte et copiez collez ceci à l’intérieur:

model{
#Définition de la vraisemblance
for (i in 1:n) {y[i,1]~dnorm(mu[i], tau)
mu[i] }
#Définition des aprioris
for(j in 1:2){
b[j] ~ dnorm(0, 1.0E-4)
}
tau ~ dgamma(1.0E-3, 1.0E-3)}

Lisons ce code ligne par ligne. De la ligne 1 à 3, on spécifie la vraisemblance. Pour i allant de 1 à n, on dit que y suit une loi normale de moyenne mu et de précision tau. La précision est l’inverse de la variance,
et est très souvent utilisé en place et lieu de l’écart-type en économétrie bayésienne. On définit aussi mu avec la commande suivante: «mu[i] <- inprod(b[],x[i,])». La fonction inprod est propre à JAGS et retourne le
produit scalaire des vecteurs b et x. Notez bien que les vecteurs y et x définis dans ce modèle sont les mêmes que ceux définis dans votre script R! Ensuite nous définissons les aprioris. On utilise une boucle pour
définir b[1] et b[2] comme suivants tous les deux une loi normale contrée sur 0 avec une très faible précision (et donc une grande variance) pour couvrir un maximum de données. C’est bien la définition d’une
apriori vague. Pour tau on définit une densité gamma avec les paramètres 0.001 et 0.001 qui est une apriori vague aussi.

Maintenant, nous pouvons retourner à notre script R. Il faut maintenant encore définir au moins deux choses pour pouvoir utiliser JAGS. Le vecteur de paramètre que nous voulons estimer, et les données qu’il faut utiliser et, si on le souhaite, des valeurs initiales pour nos paramètres.

parameters = c("b","tau")
data = list("x","y","n")
inits = function(){
list(b1 = 0,
b2 = 0,
tau = 1) }


Prenez note de la syntaxe, c’est ainsi que vous devrez procéder. Ici, on met une valeur initiale de 0 pour b1 et b2 et de 1 pour tau. Maintenant, on peut enfin lancer l’estimation:

model_fit<-jags(data,inits=NULL,parameters,n.iter=100000,n.burnin=50000,
model.file="bugs.txt",n.chains=4,DIC=T)

La commande pour lancer l’estimation est “jags” et prend en argument la liste data, les valeurs initiales inits, la définition des paramètres ainsi que le nombre d’itération, n.iter, ensuite le nombre
de valeurs qu’on laisse de côté, n.burnin, notre modèle défini dans le fichier bugs.txt, le nombre de chaînes et enfin si oui ou non on veut calculer le DIC. Le nombre d’itération doit être assez grand pour permettre
aux chaînes de converger, et le nombre de valeurs qu’on laisse de côté doit aussi être assez grand pour que les chaînes soient stationnaires, en général on met de côté la première moitié des valeurs simulées. Les résultats sont accessibles avec cette commande:

model_fit$BUGSoutput

Dans notre exemple on obtient les résultats suivants:

Rappelez-vous que les vraies valeurs de beta étaient 2 et 5. Ici les estimations sont très satisfaisantes, avec 1.7 et 5. tau égal à 4.2 ce qui donne 0.49 pour l’écart type dont la vraie valeur était 0.50. Notez aussi que la valeur du DIC est de 52.5. Ceci n’est qu’utile si vous voulez comparer différents modèles. Celui avec le DIC le plus faible est à préférer, c’est équivalent au AIC par exemple. Regarde aussi la colonne Rhat, qui est un critère de convergence. Pour chaque paramètre la valeur est 1, ce qui signifie que les chaînes ont convergé. Maintenant, on va regarder quelques critères de convergence ainsi que quelques graphiques pour s’assurer que tout s’est bien passé. Pour cela, on va utiliser les fonctions de la librairie coda. Pour des raisons de compatibilité avec coda, il faut d’abord changer la classe de notre modèle. La fonction jags retourne un modèle de classe jags, et coda n’accepte que des modèles de classe mcmc. Pas de soucis, il suffit d’entrer cette ligne:

model.mcmc<-as.mcmc(model_fit)

et maintenant on peut utiliser coda. On va d’abord s’assurer que les chaînes sont bien stationnaires et convergentes avec un outil graphique, les traces:

xyplot(model.mcmc)

qui donne ce graphique:

Comme vous pouvez le voir, les chaînes sont bien stationnaires (fluctuent autour d’une moyenne) et convergent (on voit la convergence au «mixing», c’est-à-dire que les traces des 4 chaînes sont bien confondues). On peut aussi regarder les densités aposteriori:

densityplot(model.mcmc)

ce qui donne le graphique suivant:

Il y a encore tout un tas de tests dans la librairie coda. Nous allons en rester là pour aujourd’hui, je vous conseille d’essayer cet exemple chez vous et de découvrir par vous-même tout ce qui est contenu dans coda!

L’économétrie bayésienne

Bonjour à tous!

Aujourd’hui un post un peu plus technique à nouveau, on va parler d’économétrie bayésienne.

L’économétrie bayésienne est une branche assez différente de l’économétrie classique, dite aussi fréquentiste qui prend son origine dans le fameux théorème de Bayes, issu des travaux du révérend Thomas Bayes au 18ème siècle. Dans son interprétation la plus simple, le théorème relie une probabilité conditionnelle à son inverse, c’est-à-dire qu’elle relie P(A|B) à P(B|A). En inférence bayésienne, le théorème est plutôt utilisé pour réviser la probabilité d’un événement.

En économétrie bayésienne, on utilise le théorème sous cette forme:p(theta|y) est la distribution aposteriori, p(y|theta)  est la vraisemblance et p(theta) est la distribution apriori.

Wat?

Reprenons. Déjà, le symbole tout bizarre qui ressemble à symbole d’infini mais qui n’en est pas un, signifie «est proportionnel à». Le membre de gauche est donc proportionnel à celui de droite. y sont les données observées. theta est un vecteur de paramètres de notre modèle que nous cherchons à estimer. Jusque là, pas de différences avec l’approche classique. p(y|theta) est une vraisemblance qui dépend du modèle que l’on considère. Dans le cas de la régression linéaire simple par exemple, il est naturel de choisir la loi normale pour former la vraisemblance. Dans le cas de données de comptage, il est usuel d’utiliser la loi de poisson, etc…

p(theta) est appelé la distribution apriori, ou juste l’apriori. C’est une apriori subjective que l’on a sur la vrai densité des paramètres. Ce qui est très important c’est de pouvoir justifier le choix de cet apriori. L’apriori peut aussi être choisie en étudiant les données, avec des méthodes non-paramétriques comme un histogramme par exemple. Un autre façon de procéder, est de choisir des aprioris conjuguées avec la vraisemblance, en effet, comme on multiplie ces deux objets, il est intéressant de choisir une apriori dans la même famille de loi que la vraisemblance afin d’avoir une loi à posteriori de la même famille aussi.  Et si on a vraiment aucune idée, on peut choisir des aprioris plates. Ce sont des aprioris comme une loi uniforme entre 0 et 1 (si vous êtes sûrs et certains que theta ne peut prendre des valeurs en dehors de 0 et de 1 par exemple) ou une loi normale avec une très grande variance (et qui couvre donc un large champ de valeurs).

En multipliant ces deux éléments, on obtient donc la distribution aposteriori de nos paramètres. Mais quel rapport avec ce bon vieux théorème de Bayes? Regardons ce théorème d’un peu plus près:

Ne voyez pas une certaine ressemblance avec l’expression du haut? C’est exactement la même chose. p(A) peut être considéré comme une apriori et p(B|A) comme la vraisemblance. Je vous conseille de lire ce billet si vous voulez des exemples.

Bon c’est bien joli tout ça, mais à quoi ça sert? Imaginez par exemple que vous êtes intéressés à l’estimation de la consommation et que vous avez deux modèles pour expliquer la consommation. Le premier modèle est C=10+0.9Y et le deuxième est C=Y (Y est le revenu). Donc dans le premier cas, theta1=(10, 0.9) et dans le deuxième cas theta2=(0,1). Vous vous dites que ces deux modèles sont équiprobables p(A)=p(B)=1/2 si A est l’événement «le premier modèle est le bon», et B l’événement «le deuxième modèle est le bon».

Supposez maintenant que vous avez observé des données, E, et que vous vous dites, «tiens, vu theta1 je dirai qu’il est plutôt invraisemblable que ce modèle ait généré les données que je vois» et vous formez les vraisemblances p(E|theta1) et p(E|theta2) et vous placez des probabilités apriori p(E|theta_1)=0.1 et p(E|theta_2)=0.6. En utilisant la formule de bayes, vous obtenez que p(theta_1|E)=1/7 et p(theta_2|E)=6/7. Au départ, les théories theta_1 et theta_2 étaient aussi probables l’une que l’autre, et maintenant, après avoir tenu compte de l’information des données, on voit bien que la deuxième théorie est la plus probable. Maintenant imaginez utiliser cette astuce dans des cas beaucoup plus complexes, où l’on a pas des probabilités d’événements, mais des densités de probabilités, des modèles avec 10 paramètres, des mélanges de lois pour la vraisemblance…bref, les possibilités offertes sont quasi-infinies!

Avec l’approche bayésienne, l’estimation de modèles complexes devient très simple, et il est possible de réviser ses croyances en se servant des données observées. Dans un prochain billet, je donnerai un exemple concret d’estimation avec R et JAGS, un logiciel qui marche main dans la main avec R pour estimer des modèles avec l’approche bayésienne en utilisant ce qu’on appelle en bon anglais: Markov Chain Monte Carlo.

Is Python ready for use by economists?

Disclaimer: I am not a native English speaker. The only reason I am writing this entry in English is to reach a broader audience. If you see any mistakes, please let me know, I’ll be happy to correct them. Also, I am not a real economist yet, I study economics at the University of Strasbourg, France. This blog entry is more a compilation of my personal experience relative to the use of software as an apprentice economist.

For the past 6 weeks, I’ve had my first extensive experience as an economist at my faculty. I am doing an internship and work with more advanced and complicated economic models than those I studied in class, mainly RBC and DSGE models. In order to solve and simulate these models, economists have to use computer programs but there is something very important that characterizes economists; they’re not programmers.
This means that they need easy to use software, that doesn’t need a long learning curve (because, you know, they have ‘other more important things to do’). That’s why the majority of the researchers at my faculty use Matlab. Matlab is a proprietary software that features an easy to learn language which is relatively close to human language. I had to work with it, and despite it’s benefits (a lot of code is already available for economists that use Matlab, it comes nicely prepackaged with a GUI and toolboxes, etc…) I don’t like it.

First of all, it’s rather bloated. The GUI is written in Java, at least on Linux platforms, and we all know that Java applications are not well-known for their snappiness.

Then there’s the keyboard shortcuts. Mathworks, the guys behind Matlab decided that the classic keyboard shortcuts used by every single software on the planet weren’t good enough anymore. Want to undo? Forget ctrl-z. Now it’s ctrl-shift-minus. What about redo? You might think it’s ctrl-shift-plus right? No, it isn’t, it would be way too consistent. It’s ctrl-shift-z. Every single keyboard shortcut is like that, for no good reason. I am a keyboard guy, I merely touch my mouse even for web browsing, so these keyboard shortcuts drive me insane.

And then of course, it’s proprietary, and apart from being expensive, I don’t like the idea of my work being tied to a closed-source software that might, one day, be discontinued/unavailable for my platform making all my work lost.

But what alternatives are there? Well, there’s GNU Octave, which is developed to be a drop-in replacement of Matlab. But I decided to try something else. I decided to use a programming language called Python.

Python was developed in 1991 by Guido van Rossum, whose design philosophy emphasizes code readability. Python code is probably the most easy to read and understand code there is. It’s so easy that you can learn and begin using Python in a matter of days, even more so if you already have experience with programming.

But can Python be used for economics? Well, Python can be pretty much used for anything. A lot of software is written in Python, for example Ubiquity, the Ubuntu installer is written in Python. Even video games use Python, such as Civilization IV. And of course Python can be used for math and algebra, thus economics.

To use Python for scientific computation, you’ll need certain modules that contain useful functions for calculation. Scipy and Numpy are two of those modules and are mandatory if you want to use Python for scientific computation. Matplotlib is another useful module that can plot very good looking graphs.

On a GNU/Linux operating system, installation of Python and these modules is very straightforward (Python is even pre-installed in most cases). Then there’s the question of what editor to use to write your code; unlike Matlab, you can use pretty much any text editor, but there are of course IDEs for Python, and even one for scientific computing with Python, called Spyder. I use vim myself and followed this guide to make coding Python in vim better, but use whatever editor you’re comfortable with. On windows, I read that your best option to install Python and Scipy/Numpy is to install Python(x,y).

Well that sounds great right? Well it depends. Python is great and Scipy and Numpy will allow you to do most of what you do now with Matlab, but you wil need to relearn some things. For example, while you can work with a matrix class in Python, very much like Matlab, it is recommended to work with arrays, which is an obscure term for most economists and arrays work very differently that matrices in Matlab. For example, matrix multiplication in Matlab is achieved with A*B, while in Python this is element-wise multiplication. Array multiplication is achieved with dot(A,B) which can be really confusing at first. There are other slight differences, like index access which begins at index 0 in Python and at 1 in Matlab and also something where I personally lost some time with, for-loops. In Python, for loops go from [1,n), n is not included, while in Matlab n will be included.

Another downside of using Python/Scipy is the lack of polished and exhaustive documentation. There is documentation for most functions, but not all, and I find the documentation better in Matlab.

I am however willing to accept these downsides to continue working with software libre, which is really important for me.

Canonical, le libre et les trolls

Bonjour à tous!

Disclaimer: Ce billet s’adresse à un public qui connaît les notions de logiciel libre, de licences libres copyleft, de licences libres non-copyleft, etc. Si vous ne savez pas trop ce que c’est, prenez le temps de lire un peu les pages suivantes sur wikipedia si jamais cela vous intéresse (et entre nous, cela devrait vous intéresser): Licence GPL, Copyleft, Licence Apache, Licences BSD, Canonical, Canonical’s contributor agreement. C’est long, mais c’est intéressant.

Aujourd’hui, je vais tenter de rédiger un billet qui n’a aucun rapport avec l’économie et les statistiques, mais qui va parler de Canonical et de la philosophie du libre. Ce billet est un peu une réponse/réaction à celui de mon cyber-pote Darthwound, administrateur du site francophone de la distribution Crunchbang (distribution minimaliste basée sur Debian, qui vise plutôt les utilisateurs intermédiaires ou avancés). Vous pouvez lire son billet qui a suscité cette réaction chez moi ici.

Canonical est l’entité commerciale qui produit Ubuntu, et beaucoup de gens ont peur, peut-être à tord ou à raison, que Canonical finira par nuire tôt ou tard au libre (ou nuit déjà). Il y a une guerre intestine sur les forum et chats des GNU/Linuxiens en ce moment (enfin il y en a toujours eu…) entre les utilisateurs d’Ubuntu et ceux qui n’utilisent pas Ubuntu.
Mais quels sont donc les reproches que l’on fait à Ubuntu? Je vais commencer les plus évidents et qui, en fait, ne sont pas des problèmes.

• L’interface ressemble trop à OSX.

C’est l’une des préférées des détracteurs. Je commencerai par dire que non, elle ne ressemble en rien à l’interface d’OSX. Jugez par vous même: ici OSX Lion et ici Ubuntu Natty Narwhal. C’est quand même pas pareil; la seule once de ressemblance vient de la barre de menu tout en haut de l’écran. C’est tout. Les couleurs sont différentes, les icônes sont différentes, et Ubuntu a des possibilités de personnalisation quasi-infinies. Bien sûr, on ne peut pas nier une certaine influence d’OSX sur Ubuntu; certains trouveront ça très grave d’autres non. Je peux comprendre qu’on n’aime pas l’interface par défaut d’Ubuntu, moi-même je n’en suis pas fan, mais rien n’oblige qui que ce soit à l’utiliser. On peut très facilement revenir à l’interface traditionnelle de Gnome 2 dans Natty Narwhal, sur Oneiric Ocelot, la prochaine, Gnome 3 sera présente et il suffira d’installer le shell qui sera accessible via les dépôts. D’ailleurs, l’utilisateur peut installer n’importe quelle autre interface à côté d’Unity.

De plus, toutes les interfaces finissent par se ressembler; l’interface de Linux Mint est aussi proche de celle de Windows XP que celle de Natty Narwhal est proche d’OSX. Vous me croyez pas? Interface Windows XP et interface Linux Mint. Voilà, la seule once de ressemblance c’est la barre de tâche, comme pour Ubuntu et OSX.

• Ubuntu devient trop noob-friendly

L’une de mes préférées personnellement. On reproche à Ubuntu de prendre les utilisateurs trop par la main, de ne pas les laisser découvrir leur système ni son fonctionnement. Seulement voilà, certains n’en ont vraiment rien à faire. Certaines personnes utilisent leur ordinateur pour travailler et sont bien contentes de pouvoir se mettre directement au boulot après l’installation du système, sans devoir encore faire des réglages. Si ces personnes veulent vraiment apprendre comment fonctionne le système en profondeur, d’autres distributions sont plus aptes à ça. Certaines personnes n’ont pas les mêmes contraintes de temps aussi; il faut du temps pour se faire une installation aux petits oignons, avec un système qui ne fait pas les réglages à la place de l’utilisateur comme Archlinux par exemple. Certains n’ont simplement pas le temps.

N’oublions pas qu’Ubuntu c’est Linux for Human Beings et que dans Human Beings il y a aussi les non-geeks. De plus rien n’empêche d’utiliser Ubuntu à un haut niveau: l’utilisateur avancé peut faire une netinstall et créer pratiquement sa propre distribution à partir de rien.
Autre chose qui a fait jaser dans les forums: Ubuntu abandonne synaptic en faveur de son software center. Synaptic est une interface qui permet d’installer et désinstaller des paquets. Très pratique lorsqu’on est un utilisateur intermédiaire et qu’il nous faut installer tel ou tel autre paquet. L’Ubuntu Software Center introduit depuis Karmic Koala (avant Linux Mint; le software manager de Mint est apparu dans Linux Mint 9, lien, qui est basée sur Ubuntu Lucid Lynx qui est venue après Karmic Koala. Avant sur Linux Mint, c’était quelque chose de plus proche de synaptic, lien), lui installe des applications. Ce sont deux choses très proches, mais très différentes. Et cela est parfaitement cohérent avec la politique de Canonical de viser le grand publique est les débutants. Pour les débutants, la notion de paquet n’est pas très claire et soporifique. Les débutants veulent installer une application. Ils veulent installer VLC par exemple, et se soucient peu de voir les dépendances que cela apporte. Ceux qui préfèrent synaptic sont en général des utilisateurs intermédiaires qui ont l’habitude et qui l’installeront en une ligne de commande.

• Canonical se sert du libre, veut amener des logiciels payants dans leur Software Center, fermeront le code d’Ubuntu dès qu’Ubuntu sera assez connue ne contribuent pas assez et sont une menace pour le libre en général

Je sens que ce paragraphe va être long. On va procéder par chefs d’accusation: Canonical se sert du libre. La réponse est oui, et heureusement. C’est le principe même du libre, se servir de ce qui existe déjà pour ne pas avoir à ré-inventer la roue un milliers de fois. Certains reprochent ensuite de ne pas rendre à la communauté et je dois avouer que je ne comprends pas. Les logiciels que Canonical utilise pour ses besoins sont pour la très grande majorité sous licence GPL, donc toutes les modifications que Canonical apporte au code sont sous licence GPL aussi et donc librement accessibles. C’est comme ça que font tous les développeurs, non? Certains reprochent à Canonical de ne pas citer les projets desquels ils s’inspirent. Oui mais la GPL ne prévoit pas ça. Si on veut être cité, la licence Apache est plus adéquate. Seulement voilà, la licence Apache est dite permissive, et autorise l’inclusion de code sous licence Apache dans des projets propriétaires. La licence BSD inclut une clause similaire, qui d’ailleurs a suscité pas mal de controverses. (3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the <organization>.) Ces deux licences ne sont pas copyleft; maintenant vous êtes prévenus, si vous voulez absolument être cités, optez pour une licence BSD ou Apache! Je ne vois pas pourquoi on reprocherait à Canonical de ne pas faire ce que personne ne fait (ou du moins, n’est pas obligé de faire). De plus Canonical a développé un tas de logiciels qui sont maintenant utilisés dans d’autres distributions ou projets, comme Ubiquity, Bazaar, Launchpad, AppInidicators, Quickly, Storm, Gufw… pour ne citer qu’eux…

Concernant les logiciels payants, oui, Canonical veut en amener un maximum dans leur Software Center. Et à nouveau, je ne vois pas où est le problème. Ça donne plus de choix aux gens, et le choix c’est justement la force de l’univers GNU/Linux. Ne devrions-nous pas laisser le choix des logiciels propriétaires aux gens? Leur imposer de ne pas utiliser du non-libre est restreindre leurs libertés, donc nous avons un problème. Bien sûr l’idéal est que tout le monde comprenne les enjeux du libre et utilise du libre. Seulement voilà, en fonction de votre secteur d’activité le libre offre des options très pauvres voire inexistantes. Par exemple les architectes auront du mal à faire leur travail sur du tout libre alors qu’en termes de logiciels privateurs et payants il existe Bricscad. Devrions nous pour autant fermer nos portes aux architectes? N’est-il pas une bonne chose de leur donner l’opportunité d’utiliser un système d’exploitation GNU/Linux? Ce qui m’a fait rire dans le billet de mon cyber-pote Darthwound (sans rancune l’ami ) c’est qu’après avoir critiqué Ubuntu pour ça (ce qui est son droit bien entendu), il annonce boycotter totalement Ubuntu pour ensuite conseiller aux gens d’utiliser…Linux Mint, qui non seulement est basée sur Ubuntu (donc pour le boycott on repassera), mais qui en plus pré-installe des logiciels privateurs par défaut, Flash Player et Skype pour ne citer qu’eux, alors qu’Ubuntu, bien que proposant des logiciels privateurs dans sa logithèque, n’en installe aucun par défaut. On reproche aussi à Ubuntu d’introduire l’esprit mercantile dans le libre, ce qui est très grave. Oui mais non. D’une, l’esprit mercantile dans le libre, ça fait des décennies que ça existe, et de deux, ça rapporte des millions. Il suffit de regarder Red Hat qui se porte très bien financièrement grâce au libre, ou encore Google, Intel, IBM…même que le libre rapporte indirectement des sous à Apple! (oui, webkit est libre et contribue, de manière indirecte, au succès de leur système d’exploitation).

Vient maintenant la fermeture du code. Certains pensent que Canonical finiront par fermer le code une fois qu’Ubuntu sera assez connue. Malheureusement, personne à ce jour n’a pu me dire ce que ça rapporterait à Canonical de fermer le code, et ces personnes oublient un peu vite qu’il est juridiquement impossible de fermer du code qui est sous licence GPL (c’est un peu le but de la GPL). Canonical sait que s’ils font ça, ils auront des gros problèmes juridiques avec la FSF et qu’ils perdront facilement 90% de leurs utilisateurs (voire plus). Cela dit, il y a peut-être une part de vérité.

(Petit aparté: je sens qu’on va me citer l’exemple de Google qui a fermé le code d’Android 3 pour me dire tu vois qu’on peut fermer du code! Sauf qu’Android n’est pas sous licence GPL mais Apache…et la licence Apache ne prévoit absolument pas que le code doit être libéré.)

En effet, certains projets développés par Canonical, notamment Unity et Ubuntu software center sont soumis au Canonical’s Contributor Agreement. Ce sont les logiciels qui ont bénéficié de fonds de la part de Canonical qui sont sujets à cet accord particulier qui stipule que Canonical reste le détenteur des droits des logiciels quoi qu’il arrive. En échange, le contributeur est libre de faire ce qu’il veut du code: In it, the contributor assigns copyright to Canonical and at the same time Canonical gives the contributor “a world-wide, non-exclusive, royalty-free and perpetual right to use, copy, modify, communicate and make available to the public (including without limitation via the Internet) and distribute, in each case in an original or modified form, the Assigned Contributions as (they) wish.”

Cela ressemble un peu à une licence BSD si j’ose dire…en simplifiant beaucoup hein, me sautez pas dessus! Le truc avec cet accord, c’est que Canonical se réserve le droit de changer la licence des logiciels qui font partie de cette liste, et peut la changer pour une licence non libre. Et ce qui est bizarre, c’est que jamais, je dis bien jamais, on ne pointe Canonical du doigt pour ça dans les forums, alors que là, on est d’accord, c’est potentiellement grave. Les détracteurs préfèrent s’attarder sur le thème de couleurs par défaut ou sur l’interface…allez savoir!

Est-ce que Canonical changeront la licence de leurs projets sous cet accord pour une licence non-libre? Seul l’avenir nous le dira, en tout cas, pour l’instant, rien ne permet de l’affirmer.

En tout cas, quitte à critiquer Canonical critiquez les vrais problèmes, comme le Canonical’s Contributor Agreement ou le fiasco avec leur lecteur de musique (sur lequel ils ont désactivé l’Amazon Store en faveur du leur et l’histoire aussi avec le partage des revenus ici).

 

• Paragraphe bonus! Ubuntu s’éloigne de l’esprit Linux!

Non. Ubuntu s’éloigne de l’esprit GNU, oui. Pas de l’esprit linux. Linux n’est qu’un noyau, dont l’auteur n’est pas si apprécié que ça par Stallman…et qui n’est pas si opposé aux logiciels privateurs que ça.

Une alternative à Google – Duck Duck Go

Bonjour à tous,

aujourd’hui, je tiens à vous présenter une alternative au moteur de recherche de Google. Avant de continuer, pourquoi utiliser une alternative à Google? Après tout, Google est rapide, fiable et utilisé par pratiquement tout le monde. Toutefois, il se peut que vous ne soyez pas à l’aise à l’idée que Google ait accès à toutes vos informations. Tout ce que vous recherchez en vous servant de leur moteur de recherche leur permet de vous viser avec de la pub ciblée. Cela pourrait vous déranger.
Il se peut aussi que vous n’aimiez tout simplement pas Google. Bref quelque soit la raison, vous serez peut-être intéressé de savoir qu’il existe des alternatives, la meilleure, à mes yeux, étant Duck Duck Go.

Duck Duck Go est rapide, offre des options intéressantes (comme le premier paragraphe de la page wikipedia directement lisible sur la page des résultats) et surtout protège votre vie privée. Duck Duck Go ne stocke aucune données sur vous, sur les mots clés que vous avez utilisé et les sites que vous accédez à travers Duck Duck Go ne peuvent pas savoir quels critères de recherche vous avez utilisé pour les trouver ni que vous vous êtes servis de Duck Duck Go.

Duck Duck Go ne contient presque pas de publicités non plus. Vous pouvez l’ajouter à Firefox avec l’addon disponible à cette adresse et pour Chrome/Chromium ici .

Une autre fonctionnalité très intéressante est ce qu’on appelle les !bangs. Vous voulez chercher le mot «sac à main» sur amazon et vous vous trouvez déjà sur Duck Duck Go? Tapez !amazon sac à main et vous serez directement redirigé vers amazon sur la page de résultats de sac à main. Ici se trouve la liste de tous les !bang.

Il y aussi une alternative à la fonctionnalité «J’ai de la chance» de Google qui vous redirige directement vers le premier résultat; tapez \mot_clé pour aller directement sur le premier résultat de mot_clé.

Vous pouvez aussi poser directement des questions, comme «age of obama» pour avoir directement la réponse, fournie par Wolfram Alpha. En effet Duck Duck Go utilise plusieurs moteurs de recherche simultanément, et reclasse de manière intelligente les résultats pour les présenter de la meilleure façon à l’utilisateur.

Essayez-le, Duck Duck est vraiment un moteur de recherche très intéressant.

Faire ses présentations avec LaTeX et Beamer

Bonjour à tous!

Aujourd’hui, suite à un échange avec Astrid Toubou (une lectrice de ce blog) qui a besoin de faire une présentation pour son stage, et qui considère Beamer pour le faire, j’ai décidé de rédiger un petit billet sur Beamer, étant donné que je m’en suis déjà servi.

La plupart des gens font leurs présentations en utilisant Powerpoint. D’ailleurs, dans le langage courant, il est coutume de dire «un powerpoint» quand on veut dire «une présentation». Powerpoint a ses qualités et ses défauts, je ne vais pas m’éterniser la-dessus. Toutefois, s’il y a bien un soucis avec Powerpoint, c’est quand on veut faire une présentation qui comporte beaucoup de mathématiques. Bien sûr, on peut y arriver avec Powerpoint, mais ce n’est pas l’outil le plus efficace.

C’est là qu’il est intéressant d’utiliser Beamer. Beamer est une classe de document pour LaTeX qui permet de faire des présentations à projeter. D’ailleurs Beamer est un pseudo-anglicisme allemand, signifiant projecteur. En gros, on peut utiliser la puissance et la souplesse de LaTeX afin de créer des présentations de toute beauté.

Pour cela, il y a deux choses à faire dans le préambule. Pour commencer il faut définir la classe du document comme étant de type Beamer comme suit:

\documentclass{beamer}

Ensuite il faut définir un thème. Le thème va donner l’apparence à votre présentation. Voici la liste des thèmes disponibles:

http://deic.uab.es/~iblanes/beamer_gallery/index_by_theme.html

Une fois que vous avez choisi un thème, définissez le comme suit dans votre préambule:

\usetheme{Singapore}

Maintenant que votre préambule est clairement défini, il ne reste plus qu’à savoir comment définir les slides. Chaque slide est défini par les deux commandes suivantes:

\begin{frame}

écrivez ici votre code LaTeX comme d’habitude, avec vos formules, listes etc…

\end{frame}

et ainsi de suite. Faites attention à ne pas trop surcharger un slide, il se pourrait que tout le texte ne rentre pas dedans. N’hésitez pas à faire des puces avec itemize aussi.

Les séries temporelles avec R

Voici un petit billet qui est sensé aiguiller les étudiants lorsqu’ils font une étude économétrique sur les séries temporelles.
Ce semestre j’ai dû rendre un dossier dans lequel j’ai fait des prévisions de la masse monétaire M2 aux États-Unis, et comme j’ai déjà reçu ma note, je vais compiler ici ce que j’ai trouvé, ça pourrait être utile à d’autres.

Pour commencer, installez Rstudio (à moins que vous en préféreriez une autre, sinon, je vous la conseille vivement). Ensuite, il faut savoir que par défaut, R dispose de pas mal de fonctions pour les séries temporelles, mais on peut ajouter des fonctionnalités supplémentaires au travers de packages. Nous allons utiliser la procédure de Box & Jenkins. Les données peuvent être téléchargées ici: http://dl.dropbox.com/u/1343895/M2SL%281%29.xls
Il s’agit de la masse monétaire M2 aux États-Unis.

Une première chose à faire, c’est importer notre série, et la définir comme une série temporelle avec date de départ et sa périodicité (données journalière, hebdomadaire, trimestrielle, semestrielle, annuelle). Commençons donc par les importer:

data<-read.csv("~/chemin/vers/vos/données/M2SL.csv", header=TRUE,dec=",")

Astuce: Souvent vos données seront au format xls (voire xlsx) avec pour première colonne les dates des observations, et souvent pas mal de commentaires dans les premières lignes. Effacez tous ces commentaires et la première colonne (on spécifiera les dates directement dans R) et enregistrez le tout au format csv, c’est plus simple. Après avoir importé les données il faut dire à R que ce sont des séries temporelles, donner la date de départ et aussi la périodicité:

m2<-ts(data$VALUE,start=c(1959,1),deltat=1/12)

ts est une fonction qui définit la classe d’un vecteur comme étant time series, avec comme date pour la première observation la première période de 1959, et deltat donne la périodicité (1/12 pour des données mensuelles, 1/4 pour des trimestres, etc). data$VALUE signifie qu’on s’intéresse qu’à la colonne VALUE des données data (c’était comme ça qu’étaient appelées les observations).

Maintenant qu’on a ça, on peut faire un graphique des données.

On voit que comme très souvent pour des données macro-économiques, il y a une tendance à la hausse exponentielle. Une bonne idée avant de continuer et de considérer le log des données, car cela permet d’obtenir des données avec une tendance linéaire et une variabilité constante.

lm2=log(m2);plot(lm2,type="l",col="blue")

Maintenant, nous pouvons commencer à étudier la série. Pour faire des prévisions fiables, il faut que la série soit stationnaire. Pour ça, les économètres font ce qu’on appelle un test de racine unitaire, le test de Dickey-Fuller. Le package forecast contient la fonction adf.test qui permet de mener ce test.

install.packages("forecast");library("forecast")

On installe le package et on le charge, ensuite on peut utiliser adf.test.

adf.test(lm2)

Augmented Dickey-Fuller Test
data: lm2
Dickey-Fuller = -0.783, Lag order = 8, p-value = 0.9631
alternative hypothesis: stationary

En regardant la p-value, on voit qu’on peut accepter l’hypothèse nulle au seuil de 5%, ce qui signifie que notre série n’est pas stationnaire. On va donc différencier notre série et refaire le test:

dlm2<-diff(lm2,differences=1)

dlm2 est définie comme lm2(t)-lm2(t-1).

adf.test(dlm2)

Augmented Dickey-Fuller Test
data: dlm2
Dickey-Fuller = -4.8408, Lag order = 8, p-value = 0.01
alternative hypothesis: stationary
Warning message:
In adf.test(dlm2) : p-value smaller than printed p-value

Cette fois-ci, la p-value est largement inférieure au seuil de 5% et on peut rejeter l’hypothèse nulle de non-stationnarité. La prochaine étape est de trouver un modèle que la série suit. Notez que j’ai dit un modèle et non le modèle, en effet, plusieurs modèles peuvent être bons, et pour nous aider à choisir, on va utiliser le critère d’Akaike.

Remarque: les données ne sont pas saisonnières. Si votre graphique laisse apparaître une saisonnalité, vous devrez en tenir compte dans l’analyse!

Dans la suite, je fais le choix de continuer l’étude avec dlm2 et non lm2. Pourquoi? Parce que dlm2 est stationnaire et intégré d’ordre 0, alors que lm2 est intégré d’ordre 1. Donc dlm2 suivra un processus ARMA(p,q) tandis que lm2 un ARIMA(p,1,q). C’est parfaitement équivalent, mais pour alléger l’écriture, j’ai fait le choix de continuer avec dlm2.

Mais quel ARMA(p,q)? Dans R, il y a deux possibilités, et je vous conseille de faire les 2. D’abord, on va jeter un œil sur les fonctions d’autocorrélation et d’autocorrélation partielle de dlm2.

acf(dlm2,lag=70,col="red");pacf(dlm2,lag=50,col="red")

Lorsque la fonction d’autocorrélation partielle s’annule, on obtient l’ordre p de la partie AR, et pour lorsque la fonction d’autocorrelation s’annule on obtient l’ordre q de la partie MA. La, en comptant, je choisirais un ARMA(1,2). Mais pour être sûr, on va utiliser la fonction auto.arima du package forecast. Cette fonction confronte plusieurs modèles différents et nous retourne celui qui minimise le critère d’Akaike:

auto.arima(dlm2,max.p=5, max.q=5,d=0,trace=FALSE,test="adf",stationary=F)

Series: dlm2
ARIMA(5,0,1) with non-zero mean

Call: auto.arima(x = dlm2, d = 0, max.p = 5, max.q = 5, stationary = F, trace = F, test = “adf”)

Coefficients:
ar1 ar2 ar3 ar4 ar5 ma1 intercept
1.2364 -0.2634 0.0744 -0.2549 0.1656 -0.7807 0.0054
s.e. 0.1433 0.0872 0.0645 0.0633 0.0439 0.1445 0.0006

sigma^2 estimated as 7.435e-06: log likelihood = 2803.21
AIC = -5590.41 AICc = -5590.18 BIC = -5554.91

R nous conseille un ARMA(5,1) avec un AIC de -5590.41. Notre modèle de départ a un AIC plus grand (on peut vérifier l’AIC d’un modèle en le définissant). Nous allons donc garder le modèle que R nous propose.

model<-arima(dlm2, order=c(5,0,1))

Maintenant il faut savoir si ce modèle tient la route. Une des hypothèses de la méthode de Box & Jenkins est que les résidus forment un bruit blanc. On va donc étudier les résidus.

residuals(model)->res

La fonction residuals est une fonction générique que permet d’extraire les résidus de n’importe quel modèle.

plot(res, col="light blue");abline(a=0,b=0);hist(res,breaks=60,col="pink")

La commande du haut retourne un graphe des résidus avec une ligne horizontale qui passe par 0 (si les résidus forment un bruit blanc, alors leur moyenne sera nulle, un tel graphe nous donne déjà une idée), ainsi qu’un histogramme:

À première vue, ça s’annonce pas mal. On va tester la moyenne des résidus:

t.test(res,mu=0,conf.level=0.95)
One Sample t-test
data: res
t = 0.0797, df = 624, p-value = 0.9365
alternative hypothesis: true mean is not equal to 0
95 percent confidence interval:
-0.0002056558 0.0002230500
sample estimates:
mean of x
8.697097e-06

On peut accepter l’hypothèse nulle que la moyenne est…nulle. Il ne manque plus qu’à tester l’autocorrélation des erreurs. Pour cela, on va mener un test portmanteau, en particulier le test de Ljung-Box, avec la fonction Box.test:

Box.test(res,type ="Ljung-Box",lag=50)
Box-Ljung test
data: res
X-squared = 60.6484, df = 50, p-value = 0.1439

On accepte l’hypothèse nulle d’homoscédasticité. On peut donc avoir confiance en nos prédictions. Pour faire des prédictions, on utilise la fonction predict:

predict(model,n.ahead=5)->prediction

Et voilà! Maintenant il ne reste plus qu’à faire les transformations nécessaire pour avoir des prédictions de m2 (n’oubliez pas que vous avez les prédictions de dlm2 la, qui est la différence des logs des observations!), et le tour est joué.