Sujet :
Génération de population agricole à partir de
données agrégées et d’un panel représentatif de fermes.
Lieu du
stage : Cemagref, groupement de Clermont-Ferrand
Unité de Recherche LISC (Laboratoire d'Ingénierie pour les Systèmes Complexes)
24, Avenue des Landais – BP 50085
63172 Aubière Cedex.
Unité de Recherche LISC (Laboratoire d'Ingénierie pour les Systèmes Complexes)
24, Avenue des Landais – BP 50085
63172 Aubière Cedex.
Remerciements :
Je tiens à remercier Thierry
Faure, mon maître de stage, pour m’avoir accordé sa confiance dans ce projet un
peu abrupt pour un néophyte en informatique.
Merci également à mes camarades
stagiaires qui par leur appui en langage JAVA, m’ont fait progresser bien plus
vite que n’importe quel livre.
Enfin, merci à toute l’équipe du
LISC, pour son accueil, sa disponibilité et sa bonne humeur permanente.
Mots
clés : statistiques,
données agrégées, échantillonnage, optimisation.
Résumé :
Ce stage a consisté en
l’étude des méthodes de reconstruction d’une population agricole à partir de
deux sources de données : des échantillons et des données agrégées au
niveau d’une ou plusieurs sous régions. Notre rapport décrit d’abord l’analyse statistique de la
population agricole du Honduras, effectuée principalement avec le logiciel Scilab.
Il détaille ensuite la conception d’une application visant à créer une telle
population à partir de ces deux sources de données.
Abstract :
During this internship, we have studied methods
of agricultural population re-creation from samples and aggregated data at the
level of several districts. First we have made a statistical analysis of the
Honduras’s agricultural population, with the Scilab software mainly. Then, we
have designed a program which creates a population from these two sources of
data.
Introduction
Ce rapport présente les travaux
que nous avons effectué au sein du LISC (Laboratoire d'Ingénierie pour les
Systèmes Complexes), unité de recherche du CEMAGREF de Clermont-Ferrand, dans
le cadre de notre stage de DESS qui s’est déroulé de début Avril à fin
Septembre 2002.
Le CIAT (Centre International de
l’Agriculture Tropicale) a développé des partenariats avec des organismes
publics de recherche français, dont le CEMAGREF. L’un de ces projets concerne l’étude de la diffusion de
l’innovation agricole.
Cette étude nécessite la
manipulation de données de recensement à l’échelle individuelle (surface de
l’exploitation, types et quantités de production, informations sur les
agriculteurs…).
Mais pour des raisons de
confidentialité, on ne dispose généralement pas de telles données au niveau
individuel mais plutôt de données agrégées à l’échelle de la commune ou du
département et de quelques échantillons de données individuelles.
Le LISC, au cours de précédents
travaux (projet européen IMAGES), a commencé à développer des méthodes
permettant de générer une population d’exploitations statistiquement valide à
partir d’échantillons et de données agrégées.
Notre stage a consisté à
développer en JAVA un outil générique mettant en œuvre de telles méthodes afin
d’automatiser et de faciliter les opérations statistiques que nous venons de
voir.
Afin de pouvoir manipuler à la
fois les données individuelles et les données de recensement agrégées nous
disposions de la base de données
complète du paysage agricole du Honduras. Avant de concevoir l’application en
tant que telle, nous avons donc créé des données agrégées de cette population
et testé différents outils statistiques afin d’ébaucher au mieux la structure
de données et les fonctions du programme, ainsi que les paramètres les plus
représentatifs pour la recréation de population.
I.
Présentation de l’entreprise
Le CEMAGREF, c'est-à-dire le Centre national d'Etudes sur
le Machinisme Agricole, le Génie Rural, les Eaux et Forêts, est un
établissement public à caractère scientifique et technologique (EPST). Il
existe depuis 1981 et comporte aujourd’hui 32 unités de recherche réparties
dans toute la France sur 10 groupements géographiques. Il dépend à la fois du
ministère de l'Education nationale, de l'Enseignement Supérieur, de la
Recherche et de la Technologie et du ministère de l'Agriculture, de la Pêche et
de l'Alimentation.
Outre la contribution au progrès
des connaissances, le CEMAGREF diffuse des méthodes de diagnostic et de
contrôle, il développe des outils de négociation et de gestion, il conçoit des
technologies innovantes et apporte son expertise aux services publics et aux
entreprises.
La figure suivante montre de
manière synthétique ses principales activités et ses principaux
partenaires :
Figure 1 :
Activités du CEMAGREF
Les compétences du CEMAGREF
s’orientent sur quatre grands domaines d’étude, qui constituent chacun un
département scientifique :
-
le fonctionnement des hydrosystèmes,
-
le génie des équipements et services pour l’eau et les
déchets,
-
la gestion des territoires à dominante rurale,
-
le génie des équipements dans le secteur agricole et
alimentaire.
Pour les années à venir, les deux
priorités scientifiques du CEMAGREF concernent les hydrosystèmes et leurs
relations avec l'agriculture d'une part, la gestion des risques naturels
d'autre part.
Les méthodologies scientifiques
telles que modélisation, information géographique et informatique scientifique,
qui constituent un apport essentiel à la recherche en ingénierie sont également privilégiées.
·
Produits de la recherche
Les recherches et les activités
conduites au CEMAGREF donnent lieu à des produits variés.
Ainsi, les publications, les participations à des colloques, les expertises et conseils aux services publics, les essais et analyses, les brevets et logiciels, la formation initiale et continue, la participation à la normalisation illustrent les missions de l'institut.
Pour ces productions, adaptées aux utilisateurs auxquelles elles sont destinées, le CEMAGREF met en place une démarche qualité, aujourd'hui acquise pour les essais et les analyses, en cours pour les activités de recherche.
Ainsi, les publications, les participations à des colloques, les expertises et conseils aux services publics, les essais et analyses, les brevets et logiciels, la formation initiale et continue, la participation à la normalisation illustrent les missions de l'institut.
Pour ces productions, adaptées aux utilisateurs auxquelles elles sont destinées, le CEMAGREF met en place une démarche qualité, aujourd'hui acquise pour les essais et les analyses, en cours pour les activités de recherche.
Les produits du CEMAGREF
sont :
-
Les publications (740 publications/an),
-
les participations à des colloques (320
communications/an),
-
les expertises et conseils aux services publics (800
mois-ingénieurs/an),
-
les essais et analyses (560 mois-ingénieurs/an),
-
les brevets (28),
-
les logiciels
(10 commercialisés),
-
la formation
initiale et continue (10 % du temps/an des ingénieurs et des chercheurs dans
plus de 50 universités),
-
la participation
à la normalisation (30 mois-ingénieurs/an).
Le CEMAGREF emploie environ 1 000 permanents dont 450 ingénieurs
et chercheurs. Leurs compétences, centrées sur les sciences de l'ingénieur,
intègrent les sciences de la nature et du vivant, les sciences de l'univers et
mobilisent les sciences humaines et sociales. Leur origine diversifiée facilite
la construction de partenariats variés. Le CEMAGREF accueille en moyenne une
centaine de thésards et 500 stagiaires de longue durée.
L'effectif des ingénieurs et
chercheurs se répartit équitablement selon les grandes orientations
scientifiques, comme le montre la figure :
Figure 2 : Effectif
des ingénieurs et chercheurs
Deux tiers des emplois sont financés par le budget civil
de la recherche et du développement. Le dernier tiers est mis à disposition
principalement par le ministère de l'agriculture, de la pêche et de
l'alimentation.
Le budget 2001 est de 63 millions
d’euros (413 MF). Les recettes provenant des contrats s'élèvent à 13 millions
d’euros (85 MF) et assurent l'essentiel des moyens de fonctionnement des unités
de recherche. Chaque année, plus de 150 contrats de recherche et de transferts
sont signés.
La figure suivante montre la répartition des dépenses pour
2001 :
Figure 3 :
Répartition des dépenses
Le groupement de
Clermont–Ferrand, l’une des 9 délégations du territoire français, est implanté
sur le campus scientifique des Cézeaux ou en plus de son rôle d’institut de
recherche il s'applique à développer des partenariats scientifiques,
d'enseignement supérieur et de formation. Il possède également une antenne à
Montoldre (Allier).
Le CEMAGREF de Clermont-Ferrand
est constitué de 3 unités de recherche, qui ont la particularité d’appartenir à
des départements scientifiques différents :
-
DFCF : Dynamiques et Fonctions des espaces
ruraux
-
TSCF : Technologies, Systèmes d'information et
procédés pour l'agriculture et l'agroalimentaire (C’est l’unité la plus
importante en terme de personnel)
-
LISC : Laboratoire d'Ingénierie des Systèmes
Complexes
Le LISC est une unité qui
n’appartient en fait à aucun des quatre départements scientifiques définis à
l’échelon national, mais est rattachée directement à la direction scientifique
du CEMAGREF.
Et du fait de son statut
interdisciplinaire, l’unité de recherche participe à des projets scientifiques
en collaboration avec les quatre départements.
Le rôle du LISC est d’évaluer et
de développer des méthodes de modélisation de systèmes complexes. Ce travail
est mené en collaboration étroite avec les équipes thématiques de
l’établissement et des partenaires extérieurs au travers de projets communs,
souvent interdisciplinaires.
Les recherches font appel à
diverses disciplines, dont les principales sont les mathématiques appliquées,
les statistiques, l'informatique et l'intelligence artificielle.
Les aspects théoriques et informatiques des modèles sont développés dans le
cadre de projets en partenariat avec des équipes thématiques. La recherche se
déploie dans trois directions principales :
-
les modèles dynamiques distribués spatialement,
-
les modèles statistiques et les bases de connaissances,
-
les méthodes et outils d'utilisation collective de
modèles dans une négociation.
Le thème de recherche de l’unité,
MAGESTYC (Modèles pour l’Aide à la GESTion des sYstèmes Complexes), vise à
élaborer, tester, valider des méthodes de modélisation génériques utilisables
dans les domaines du CEMAGREF : écosystèmes, dynamiques sociales et
interactions avec le milieu, interactions entre équipements et milieux
naturels.
Le travail de recherche se concentre
particulièrement sur l’utilisation de modèles géométriques dynamiques, qui
permettent de définir l’évolution locale de formes, à diverses échelles. Ces
modèles sont élaborés dans une démarche incrémentale, en étroite liaison avec
des experts du terrain et des domaines abordés. Leur confrontation aux
historiques de données disponibles et à l’appréciation des acteurs est une
question particulièrement sensible. Les applications principalement visées sont
des outils de gestion de la connaissance, généralement destinés aux experts
d’un domaine, ou directement des outils d’aide à la décision ou à la
négociation pour les acteurs de terrain et les décideurs publics.
Basé à Cali, en Colombie le CIAT
(Centre International de l’Agriculture Tropicale), organisme à l’origine de
notre projet, est en fait un des centres de recherche du CGIAR (Consultative
Group on International Agricultural Research).
Crée en 1971, Le CGIAR est une
association internationale dont les membres publics et privés supportent 16
centres dans plus d’une centaine de pays.
Son but est d’utiliser l’outil
scientifique pour améliorer la production agricole et d’apporter des solutions
aux problèmes de nutrition, de santé et d’environnement des pays tropicaux
principalement.
Plus de 8500 chercheurs
travaillent au CGIAR et les produits de leur recherche débouchent dans le
domaine public.
II. Présentation de l’étude
Le CIAT (Centre International de l’Agriculture
Tropicale), pour étudier la diffusion de l’innovation agricole dans les pays
concernés par son action, doit disposer de données de recensement à l’échelle
individuelle ou familiale. (Ces données sont des informations sur les
exploitants, les terrains et les productions des fermes).
Or, non seulement les recensements sont peu
nombreux et espacés dans le temps, mais il est rare que ceux ci soient
disponibles de manière exhaustive. Souvent on ne dispose, pour des raisons de
confidentialité, que d’échantillons (de taille variable, mais représentatifs de
la population) et de données agrégées à l’échelle du village, de la commune ou
de districts supérieurs.
Il faut donc à
partir de ces deux sources de données pouvoir recréer une population statistiquement valide, avec
une erreur minimale d’erreur entre population générée et population réelle.
Le CIAT a donc
développé un partenariat avec le LISC, du CEMAGRF de Clermont-Ferrand, qui a
commencé à développer des méthodes de recréation de population lors du projet
IMAGES (CT 96 2092), projet qui
concernait l’étude des décisions des agriculteurs européens sous
l’application de la Politique Agricole Commune (PAC).
L’objectif
premier de notre stage au sein du LISC a donc été de concevoir une application
dotée d’une interface conviviale qui effectuerait cette recréation de
population à partir de données agrégées et d’échantillons. Nous allons
maintenant voir plus en détail les objectifs et contraintes du programme.
Voici les spécifications qui sont
apparues au début de l’étude :
·
Le programme sera codé en JAVA, langage dont la
robustesse et l’approche objet conviennent parfaitement pour une telle application, et qui n’a pas
besoin de hautes performances en termes de vitesse d’exécution. De plus,
programme et code sources seront disponibles en libre accès : il ne doit
donc pas y avoir de classes protégées par copyright ni d’appels à des modules
externes appartenant à des applications payantes.
·
Le programme devra reposer sur une interface
graphique suffisamment intuitive pour permettre à l’utilisateur néophyte de le
faire fonctionner rapidement sans recourir constamment à un mode d’emploi.
·
Il devra comporter un module de localisation car
il sera utilisé par des personnes de langue espagnole ou anglaise.
·
L’outil doit être générique : On doit
pouvoir traiter des données d’entrée qui varient selon la population
étudiée :
- Le
nombre de paramètres est variable et ceux-ci peuvent être qualitatifs ou
quantitatifs : ils doivent être reconnus comme tels par le programme,
- Le
nombre de niveaux d’agrégation (échelles géographiques) peut varier.
·
Il y a donc nécessité de garder une certaine
souplesse pour définir la structure des fichiers d’entrée. Les contraintes de
format devront être suffisamment souples pour tenir compte de la variété des
cas rencontrés.
Au fur et à mesure du déroulement
du stage, de nouveaux objectifs sont apparus :
Le principal a été
d’envisager d’ajouter au programme la fonction « inverse » de celle
qu’il effectue : C’est à dire créer un échantillon représentatif (au taux
d’erreur désiré) à partir de la population entière. Cet ajout trouve tout son
intérêt car on rencontre de plus en plus le besoin de créer un échantillon type
a partir d’une population mère : pensons par exemple à un bureau de
recensement, ou une agence publicitaire désireuse de connaître les profils
types de ses clients pour mieux les cibler.
C’est une manipulation qui
demande peu d’ajout de code, car les structures de données et les fonctions
d’optimisation demeurent les mêmes. Le seul problème étant la quantité de
mémoire requise pour charger la matrice de population entière.
Voyons maintenant plus
précisément les spécifications du programme en décrivant les différents modules
qu’il comportera (en termes de code, un module correspondra à une ou plusieurs
classes ou même un package) :
- Module « population »
Il contiendra
toutes les variables concernant les données de la matrice de population, les
données agrégées, les échelles…
- Module « statistiques »
Le programme
doit disposer de nombreux outils pour faire l’agrégation des données : les plus
classiques comme moyenne, somme, variance, écart-type mais aussi d’autres qui sont de plus en plus utilisés,
comme les quantiles. On pourra également rajouter des modules plus complexes
comme des analyses factorielles des correspondances, des analyses par clusters…
- Module « optimisation »
Il comportera
au moins 2 algorithmes de minimisation pour optimiser le taux d’erreur lors de
la recréation de population :
Un algorithme
quadratique et un algorithme de type génétique, qui travailleront séparément ou
ensemble.
Notons qu’au début du projet, il était
prévu de rechercher dans la littérature un algorithme quadratique qui
conviendrait au mieux au problème mais le temps et la complexité
qu’impliqueraient son codage nous ont incité à rechercher un algorithme déjà
écrit : Or il existe peu de tels algorithmes disponibles dans le domaine
public : celui de Scilab (appelé par la fonction
" optim") s’est révélé vaste et incompréhensible, car il
contient de nombreuses routines en Fortran non documentées. Nous avons
finalement opté pour un algorithme
venant de "R" : un environnement de calcul statistique en
sources libres.
- module « visualisation »
Ce module
servira à visualiser les différentes données traitées par le programme sous
forme graphique. Nous avons projeté de l’élaborer à partir de JAS (Java
Analysis Studio), un package gratuit spécialisé dans cette tâche.
- Un module « plan d’expérience »
Comme son nom
l’indique, il servira à établir facilement des plans d’expériences mais
il permettra aussi de les mémoriser.
·
Première quinzaine d’avril : bibliographie sur les
méthodes d’optimisation (algorithmes
quadratiques et génétiques) et articles sur les méthodes statistiques de
recensement de population.
·
Deuxième quinzaine d’avril à mi-juin :
Analyse de données avec Scilab sur la population du Honduras : calcul des
données agrégées pour les paramètres de terrains, les paramètres de
producteurs puis analyse des corrélations.
Découverte du
langage JAVA et entraînement à la conception d’interfaces graphiques (avec
jcreator).
·
Fin juin à mi-juillet : Définition
de la structure du programme, Conception UML du diagramme de classes, ébauche
de l’interface graphique.
·
Mi-juillet à fin août : Codage du
programme. Rédaction du rapport.
·
Mois de septembre : codage,
perfectionnement et ajout de nouveaux modules.
III. Descriptif des outils acquis
Durant ce stage nous avons
nettement amélioré nos compétences en langage orienté objet (vues en DESS avec
le langage C++), grâce à la pratique de l’UML et du langage JAVA.
Nous avons également manipulé des outils
statistiques tels que Scilab. Enfin nous avons abordé des méthodes
d’optimisation de type quadratique et génétique pour les besoins de notre
application.
1. Logiciels et langages
1.1
Scilab 2.6
Scilab (pour
Scientific Laboratory) est un programme français de statistiques et de
mathématiques gratuit et en sources libres (licence GNU), développé par l’INRIA
depuis 1989. Il regroupe de nombreuses et diverses fonctions visant à faciliter
le travail sur des groupes de données (matrices et vecteurs).
Nous n’avons pas utilisé le
logiciel Matlab, plus performant mais payant, pour rester dans une optique de
gratuité des outils et des travaux fournis : En effet, le programme et les
outils qui lui sont associés pour le pré-traitement des données, tels que
Scilab, doivent être en sources libres.
1.2
Microsoft EXCEL
Nous avons utilisé Excel en appui
à Scilab pour plus de facilité dans l’édition des données agrégées et la
création de graphiques.
Si le logiciel est performant
pour ces tâches d’édition et de présentation il n’est cependant pas d’une
grande efficacité pour les fonctions statistiques (nombre de lignes limité à
65000, mauvaise gestion des intervalles de classe dans les graphiques…).
1.3
Le langage JAVA
Créé en 1995 par la société Sun, ce langage objet est en
constante amélioration et connaît un grand succès dans le monde grâce à ses
nombreux avantages :
Il est syntaxiquement proche du
C++, ce qui facilite le passage de l’un à l’autre.
Il est multi plate-forme (seule
l’installation de la machine virtuelle est requise)
Il est robuste : c’est un
langage complètement objet, très typé et qui possède beaucoup de gestions
d’exceptions.
Il possède beaucoup de fonctions
simplifiées grâce à un panel de classes livrées avec le JDK, à la suppression
des pointeurs et la gestion de la mémoire par le Garbage Collector.
La conception d’interfaces
graphiques est rendue très simple par les composants AWT et swing.
Le langage JAVA possède néanmoins
des points noirs comme sa relative lenteur (car c’est un langage interprété),
ou bien l’absence d’héritage multiple (compensée par les interfaces).
Durant ce stage nous avons
utilisé le JDK 1.3.
(Nous avons écarté le JDK 1.4 car il est trop
récent et souvent des problèmes incongrus peuvent se poser avec modules
externes ajoutés).
Nous avons utilisé les composants
graphiques SWING plutôt que les composants AWT car ils sont plus complets et
optimisés.
1.4
Jcreator
Plus exactement :
Jcreator 2.00 LE (Lite Edition) de Xinox software : c’est une version
gratuite de ce logiciel de développement en JAVA.
Nous l’avons utilisé au début de
notre stage lors de notre initiation au langage JAVA
Il est complet, tout en étant
très léger, et son interface ressemble trait pour trait à celle de Microsoft
Visual C++.
Le seul hic est qu’il ne
possède pas de débogueur intégré.
1.5
Jbuilder 5
Borland Jbuilder (utilisé avec le
JDK1.3) est un éditeur de développement JAVA proposant une
interface de conception visuelle complète
Nous l’avons choisi en raison de
sa capacité à créer rapidement une interface graphique.
De plus, de nombreux assistants,
audits de code et classes types permettent d’accélérer le codage.
Cependant certaines des classes
qu’il utilise sont sous licence et ne sont donc pas portables à
l’extérieur, car notre programme requiert une gratuité complète.
1.6
ArgoUML
ArgoUML permet de faire des diagrammes en
modélisation UML puis de générer du code JAVA à partir de ceux-ci.
ArgoUML est en version 0.10 : il
est en cours de développement et donc pas très stable. Son successeur, nommé
Poseïdon, fonctionne mieux mais est plus lourd. Nous avons donc préféré utiliser
ArgoUML car nous l’avons utilisé uniquement pour faire le diagramme de classes
du programme.
1.7
WinEdit 2000
WinEdit est un éditeur de
texte très complet qui remplace avantageusement le bloc-notes et devient
indispensable pour lire les très gros fichiers texte telles que les matrices de
paramètres utilisés durant notre stage.
1.8
Xanadu
Ce petit logiciel gratuit permet
de traduire facilement un mot dans la langue souhaitée.
C’est en fait une sorte de moteur
de recherche qui affiche dans un onglet une page de réponses pour chacun des
différents sites de traduction on-line auxquels il a fait sa requête.
La multiplicité des réponses, la
non présence de publicité et la
simplicité d’utilisation en font un outil très agréable à utiliser.
Nous l’avons utilisé pour des
traductions de l’espagnol et de l’anglais.
1.9
Java analysis studio
JAS (version 2.2.5 ) est une
application gratuite et multi-plateforme qui a pour ambition de faciliter
l’affichage et l’analyse de données, indépendamment de leur format ou de leur nature.
Elle dispose de nombreuses
fonctions statistiques et d’une interface graphique très riche et intuitive
permettant
Le code source étant disponible,
nous comptons utiliser certaines de ses classes pour le module de
visualisation.
Nous allons à présent voir les
différentes méthodes d’optimisation étudiées pour les besoins du programme.
2. Les méthodes de reconstruction de
population
Décrivons d’abord d’une manière
générale la méthode de reconstruction de population à partir de données
agrégées et d’échantillons que nous allons utiliser :
On définit d’abord tous les
individus de l’échantillon comme des « prototypes » : chaque
prototype représente une exploitation agricole type.
Cet échantillon ne devra pas être
trop petit et représenter suffisamment bien la population initiale (échantillon
non biaisé), ce qui n’est pas toujours évident dans la pratique.
On va ensuite attribuer des
coefficients (appelés λi ) à chaque prototype. Le produit des
prototypes par leurs coefficients nous donnera une nouvelle population. Tout le
travail d’optimisation consiste donc à choisir de façon optimale ces
coefficients afin de respecter les contraintes imposées par les données
agrégées.
Ce problème apparaît donc comme
la résolution d’un système linéaire. Cependant, dans la majeure partie des cas,
un tel système ne possède pas de solution.
Nous devrons donc le transposer
en un problème quadratique, ce qui permettra d’obtenir à priori une solution
optimale.
Mais on peut également
approcher le problème sous une toute autre approche, qui est celle des
algorithmes de type « génétique » :
Ceux ci aboutissent en général
rapidement à une solution sub-optimale mais ensuite, au fil des itérations,
leur progression devient très lente, avec peu d’assurance d’atteindre la
solution optimale.
Il est cependant intéressant de
comparer leurs solutions avec celles des algorithmes de type quadratique.
Nous allons d’abord voir la
méthode utilisée pour transformer le problème linéaire en un problème
quadratique puis nous présenterons l’algorithme quadratique utilisé dans le
programme et enfin nous allons comparer différents algorithmes de type
génétique.
2.1 Méthodes de
formulation du problème pour la résolution quadratique
Pour le problème qui nous
concerne, résoudre un système quadratique revient à trouver le minimum d’une
somme quadratique de différences.
Nous allons étudier ceci en
partant d’un exemple assez simplifié où deux types de paramètres sont
utilisés : le nombre de producteurs et les différentes productions.
Considérons une population P
initiale, constituée de N individus (agriculteurs).
Ces agriculteurs produisent K
sortes de produits k.
Considérons maintenant notre
échantillon : une population P’ de n individus : ce
sera donc l’ensemble des prototypes à partir desquels nous allons générer une
population P’’ semblable à P.
-
: nombre d’agriculteurs de P produisant k
: nombre d’agriculteurs de P produisant k
-
Et 
: quantité de k produite dans P.
: quantité de k produite dans P.
Nous noterons également
la quantité de k
produite par l’individu i de P’.
la quantité de k
produite par l’individu i de P’.
avec 
Où 
= 
et 
= 
= et =
-
= 1 si xi
produit k.
= 1 si xi
produit k.
-
= 0 si xi
ne produit pas k.
= 0 si xi
ne produit pas k.
avec
pour i >= j , i,j=1..n.
pi = 
2.2 L’algorithme
quadratique utilisé par l’application
L’algorithme utilisé par notre programme ne sera pas codé
dans une classe mais sera en fait appelé par un module extérieur :
« R »
2.3 Algorithmes de type génétique
Pour notre problème utiliser de
telles méthodes signifiera, comme pour un algorithme quadratique, générer des
coefficients λi pour multiplier les prototypes de façon à minimiser au maximum l’erreur entre données
agrégées initiales et données agrégées générées.
Mais ici, au lieu de chercher la
valeur des λi, nous leur donnons une valeur de départ quelconque
puis nous les modifions petit à petit selon diverses méthodes, en observant si
l’erreur résultante a été diminuée ou pas. C’est le nombre d’itérations qui est
déterminera la qualité de la solution : si celle ci progresse vite au
départ, elle atteint ensuite une phase de plateau.
Williamson et coll.(1998 )
ont exposé un éventail de méthodes de type génétique pour des travaux
d’estimation de population à partir des échantillons du recensement de 1991 au
Royaume Uni. Ces travaux correspondant assez aux nôtres, nous allons pouvoir
adopter l’une de ces méthodes pour notre programme, sans avoir à trop la
modifier.
Nous allons donc passer en revue
ces différentes méthodes et garder la meilleure.
Tout d’abord examinons la méthode
la plus basique que l’on puisse imaginer : Essayer toutes les combinaisons possibles
de coefficients multiplicateurs λi pour un échantillon donné : Le
problème se révèle tout de suite gigantesque pour une base de données telle que
la nôtre! Il faut donc trouver des méthodes plus élaborées pour arriver
rapidement à une solution, en général sub-optimale.
Voyons les 3 méthodes proposées
par les auteurs, et leurs variantes :
- L’approche “Hill climbing”(Ascension de
colline)
Par cette méthode, on n’essaie
plus toutes les combinaisons possibles mais on en choisit une seule, puis on
fait quelques changements minimes : si l’erreur est diminuée on conserve
les changements, sinon on les rejette, puis on fait de nouveaux changements.
Cette méthode a l’avantage de
faire diminuer rapidement l’erreur globale mais son gros problème est que si on
arrive a un pic sub-optimal (minima local de la fonction qui n’est pas le
minima absolu) on ne peux plus « en sortir », car l’approche hill
climbing veux que l’on progresse toujours dans un seul sens.
Voici le déroulement de cette
méthode :
a) on dispose d’un échantillon,
(ou bien on le choisit au hasard dans la population initiale, 1% par exemple).
b) on multiplie chaque prototype
de l’échantillon par des coefficients λi (de valeur quelconque au
début).
c) On calcule l’effectif des contraintes observées à partir
de la nouvelle population générée.
d) On calcule (ou on connaît)
l’effectif des contraintes attendues de la population initiale.
e) On calcule un indicateur
d’erreur appelé TAE (total des erreurs absolues) :
TAE = somme des valeurs absolues
des différences entre valeurs des contraintes observées (générées) et valeurs
des contraintes théoriques (dont on dispose au départ).
Si le TAE atteint la valeur de 0 alors la solution est
optimale.
Le choix de cet indicateur est
préférable à un test de χ² qui, selon les auteurs, n’est pas adapté à ce genre
de population (car des valeurs de paramètres très disparates aboutissent à
un khi ² anormalement fort). Les autres tests paramétriques sont également
proscrits du fait de la grande auto-corrélation qui règne souvent entre les
paramètres.
f) On change la valeur de
quelques λi (au hasard ou pas) et on recalcule le TAE : si le
TAE a diminué on conserve les changements opérés, sinon on revient à la
précédente configuration.
Puis on recommence un très grand
nombre de fois cette méthode , jusqu'à trouver un TAE acceptable.
Voyons deux variantes de cette
méthode :
HC 1 : On fait un
simple remplacement de coefficients λi au hasard.
HC 2 : Le seul
changement consiste, au lieu de sélectionner des coefficients λi au
hasard, à étudier la contribution pour
le TAE de plusieurs valeurs de λi
pour chaque élément (prototype) et d’éliminer celles qui augmentent le plus l’erreur totale.
La méthode HC2 semble plus
efficace que HC1 mais pourtant c’est cette dernière qui a les meilleurs
résultats. En effet, à l’expérience, HC2 tombe rapidement dans des pics
sub-optimaux et est plus lente, ceci étant dû à la perte de diversité due à sa
sélectivité supérieure.
- L’approche “simulated annealing” (recuit
simulé)
Le principe de base du recuit
simulé est emprunté à la métallurgie : on chauffe un morceau de métal,
puis on le laisse refroidir lentement. Le refroidissement lent et régulier du
métal permet aux atomes de se stabiliser peu à peu dans une position d'énergie
minimale. Ici nous allons minimiser, non pas l'énergie d'un cristal, mais une
fonction de coût (erreur totale) caractéristique du problème, où une solution
est d'autant meilleure que son coût est faible.
La méthode permet le
« back-tracking » : c’est à dire pouvoir redescendre d’un pic
sub-optimal (augmenter temporairement l’erreur) pour atteindre plus tard un pic
de moindre erreur.
Son fonctionnement repose sur une
formule de thermodynamique :
P(δE) = exp (-δE / T)
Avec :
P = probabilité
(d’augmentation)
δE = augmentation
potentielle du TAE (changement potentiel
de performance de recombinaison).
T = niveau maximum de
dégradation de performance acceptable pour la modification d’un élément dans une
combinaison.
Il en découle que :
Plus δE est faible et plus la
probabilité d’un changement potentiel sera grande.
Plus T est faible et moins une
baisse importante de performance sera acceptée.
Le déroulement de cette méthode est semblable à celui du hill
climbing hormis que les changements prévus sont soumis à cette formule.
Si un élément augmente la
performance globale (diminution de l’erreur), il est automatiquement
accepté.
Si un élément diminue la
performance globale il ne sera
accepté que si P(δE) est supérieure ou égale à un nombre aléatoire
compris entre 0 et 1.
La méthode du « simulated
annealing » a été testée en deux variantes, qui varient seulement au
niveau des valeurs de T initiales :
SA1 : Au départ on
fixe T comme la variation maximum de TAE pouvant être créée par un changement
de coefficient.
La période pour laquelle T
diminue a été fixée à 10*T. ( c’est un ratio empirique qui donne de très bons
résultats).
SA2 : T est choisie
plus faible mais la période de diminution de T l’est aussi, car on garde le
même ratio : 10*T . Ceci a pour conséquence de faire ressembler la méthode
à un hybride avec la méthode hill climbing.
SA2 fonctionne beaucoup mieux que
SA1, qui est handicapée par de trop grandes fluctuations dues à la facilité de
sortir des pics sub-optimaux.
Il faut donc, dans cette méthode,
minimiser le plus possible le back-tracking, sans toutefois le supprimer.
- L’approche par algorithme
génétique
L’algorithme génétique au sens
strict s’appuie sur une vision « évolutive » empruntée à la biologie.
Il fait intervenir des entités
appelées chromosomes, qui sont les vecteurs de la reproduction,
c’est à dire la transmission de l’information d’une itération de l’algorithme à
une autre. Dans notre cas on pourra définir un chromosome comme un ensemble de
coefficients λi. Chaque chromosome possède un niveau de santé
(fitness) qui correspond au complément de sa contribution au TAE selon un
nombre arbitraire. Ainsi, seuls les chromosomes ayant le meilleur niveau de
santé pourront se reproduire. La reproduction fonctionne par un processus
appelé croisement (cross-over) : deux chromosomes parents
s’échangent équitablement leur information (les coefficients dans notre cas) et
créent ainsi deux chromosomes fils.
Il peut y avoir plusieurs croisements et le taux d’information
transmise peut varier.
De plus plusieurs mécanismes
peuvent intervenir sur ce processus :
-
L’élitisme : On considère qu’un certain
pourcentage des chromosomes les plus sains (meilleurs niveaux de santé) feront
partie de la génération suivante sans passer par la reproduction.
-
La mutation : On intervient sur le
croisement entre deux parents en ajoutant une probabilité (faible) de
non-transmission d’un élément d’un parent à un enfant, qui conserve alors son
élément d’origine. Ceci permet
d’injecter ou de réinjecter de la diversité dans le déroulement de
l’algorithme car la sélection perpétuelle par le niveau de santé fait décroître
progressivement cette diversité.
Cinq variantes de l’algorithme génétique ont été testées.
Elles variaient sur plusieurs paramètres : nature de la fonction de calcul
du niveau de santé, taux d’élitisme, nombre de croisements, taux de mutation…
Les performances de chacune de ces variantes importent peu
ici, car aucune n’est meilleure que les algorithmes hill climbing ou simulated annealing.
Au final nous
retiendrons que c’est l’algorithme SA2 (simulated annealing avec une faible
valeur de T) qui donne les meilleurs résultats. C’est donc celui-ci que nous
choisirons et implémenterons dans notre application.
IV. L’étude
Cette étude pourrait se
décomposer de manière grossière en 2 grandes parties :
D’abord l’analyse des données
puis la réalisation du programme.
Les Données dont nous disposions
pour faire notre étude viennent d’un recensement effectué au Honduras : Ce
recensement a porté sur tout le pays et concernait la population agricole.
Le questionnaire soumis aux
exploitants portait sur trois types d’informations :
·
Les caractéristiques du producteur,
·
Les caractéristiques des exploitations
(subdivisées en 2 parties : propriété des terres et usage des terres),
·
Les productions (nature des productions et leur
quantités).
Le recensement a donc engendré
une base de données pour chacun de ces domaines, mais il a également établi les
localisations de chaque ferme recensée sous forme de coordonnées spatiales
(position X et Y) et sous forme de référence aux districts auxquelles elles
appartiennent.
Le Honduras, petit pays
d’Amérique Centrale (112088 km² et 5 600 000 habitants) est structuré
administrativement selon 3 échelles principales :
Les départements, qui
contiennent des municipalités, qui contiennent des villages.
Carte administrative
du Honduras
De façon chiffrée le pays
comporte :
-
18 départements
-
290 municipalités (soit environ 16 municipalités
par département)
-
3760 villages (soit environ 13 villages par
municipalité)
-
317187 fermes
(soit 84 fermes par villages)
Chaque ferme possède un
identifiant unique de 12 chiffres, constitué d’un « code village » de
5 chiffres, plus 7 chiffres propres à la ferme.
Ce code village contient aussi en
lui même les codes de municipalité et de
département de la ferme concernée. L’identifiant d’une ferme contient donc tous
les codes d’échelle.
Examinons maintenant plus en
détail les 3 bases de données du recensement :
- Les paramètres
d’exploitation : Ce sont toutes des surfaces, et elles sont données en Ha.
En voici la liste des paramètres
: il y a d’abord la liste des propriétés des surfaces puis l’usage des terres :
EXPLOITATIONS
|
||
numéro
|
propriété des terres
|
paramètre
|
1
|
terrains propres (personnels)
|
|
2
|
terrains nationaux
|
|
3
|
Ejidales (non traduit)
|
|
4
|
Terrains loués
|
|
5
|
Terrains occupés (sans contrat)
|
|
6
|
sous total
|
|
7
|
Terrains loués à un tiers
|
|
8
|
total de l'exploitation
|
|
9
|
usage des terres
|
cultures annuelles
|
10
|
cultures permanentes
|
|
11
|
repos long (plus d’un an)
|
|
12
|
repos court (moins d’un an)
|
|
13
|
pâturages naturels
|
|
14
|
pâturages cultivés
|
|
15
|
bois, forêts
|
|
16
|
étangs, lacs…
|
|
17
|
autres usages agricoles
|
|
18
|
autres usages non agricoles..
|
|
- Les paramètres des
producteurs : ce sont des données qualitatives sur les exploitants, codées
sous forme de classes (exemple : 5 classes de condition juridique) ou bien
binaires (Homme/Femme) :
PRODUCTEURS
|
|
1
|
condition juridique
|
2
|
age
|
3
|
sexe
|
4
|
alphabétisation
|
5
|
Plus haut niveau d'études atteint
|
6
|
Plus niveau d'études validé
|
7
|
type de questionnaire
|
- Malheureusement les données de
productions n’ont pas pu nous parvenir à temps, ni pour faire l’analyse de
données, ni pour les utiliser avec le programme (bien que celui soit configuré
pour les accueillir).
Notons que, cette base de données
étant peu compatible avec la structure de données du programme, il était prévu
lors de la phase de conception de la convertir en une base unique, toutes les
productions d’une ferme et leurs caractéristiques étant affichées sur une seule
ligne.
Pour terminer, la base de données des
coordonnées spatiales des fermes : nous ne l’avons pas utilisé pour
l’instant mais nous notons qu’elle représente un outil intéressant pour des
recherches de corrélation.
Nous disposons donc de deux
matrices de paramètres : exploitations
et producteurs. Elles possèdent chacune 317187 lignes (c’est à dire le nombre
de fermes du pays) et leur nombre de colonne est respectivement 24 et 10. (Et non pas 18 et 7, car aux
paramètres en tant que tels s’ajoutent l’identifiant de la ferme, le code de
village, d’autres champs de localisation et parfois des colonnes doublons).
Nous allons décrire point par
point les opérations effectuées avec Scilab sur ces données pour aboutir aux
données agrégées de la population et à leur analyse.
- remarques préalables :
Nous avons adopté le choix
d’utiliser des matrices sous forme de fichiers textes plutôt que sous forme de
fichiers codés, moins coûteux en espace mais non lisibles directement.
C’est pourquoi nous utilisons les
fonctions fscanfmat et fprintfmat : lecture et écriture de
matrices en mode texte.
Pour être lisibles par Scilab
nous avons enlevé l’entête du fichier d’origine et mis des espaces comme
séparateurs de données.
On trouvera
dans l’annexe 1 le code source des algorithmes les plus représentatifs
pour chacun des points développés ci
après.
A. Obtention
des codes municipalité et département
Il faut avant tout récupérer pour chaque ferme son numéro de
département et de municipalité, c’est à dire les deux échelles sur lesquelles
porteront la majorité des agrégations. Pour cela, nous utilisons la fonction floor
pour tronquer de manière entière le code village de manière
entière :
Code
département = floor (code village/10000) ;
Code
municipalité = floor (code village/100) ;
Notons ici qu’une erreur de zéro
s’est glissée dans l’e-mail qui nous informait de ces coefficients de division
: Et pour obtenir les codes municipalités nous avons divisé par 1000 au lieu de
100…
Et comme nous ne devions voir la
personne qui nous a fourni les données que deux mois plus tard, nous avons fait
toute notre analyse de données avec cette erreur :
Au final nous avions 38
municipalités au lieu de 290, et les données agrégées en découlant n’avaient
évidemment aucun utilité réelle.
Heureusement ceci n’a eu que peu
de préjudices pour la suite de nos travaux, si ce n’est d’empêcher la possibilité
de trouver des corrélations valables entre paramètres à ce niveau d’agrégation.
- Création des données agrégées (sommes et
variances) à chaque niveau d’agrégation pour les données d’exploitation.
Les paramètres d’exploitation
sont des données quantitatives (surfaces). Nous avons donc agrégé chaque
paramètre, district par district, pour chacune des échelles.
De plus nous avons ajouté une
colonne au fichier résultat, contenant la somme des fermes contenues dans
chaque district.
Ceci constitue donc les données
agrégées sous forme de sommes.
Nous avons aussi agrégé les
variances de chaque paramètre, en utilisant cette fois la fonction Corr au
lieu de faire une simple somme des valeurs.
Puis nous avons séparé cette matrice en
autant de fichiers que de colonnes, pour une plus grande facilité d’utilisation
de ces données, qui seront traitées sous Excel.
- Visualisation des données par
classes de superficie : (au niveau global, départemental et
municipal) et par déciles
Pour avoir un aperçu général des données,
nous avons sélectionné des paramètres représentatifs, tels que la surface
totale des exploitations, et les avons agrégé selon des classes définies.
Pour les surfaces, les
intervalles de classe ont été choisis d’ordre exponentiel car le Honduras,
comme de nombreux pays d’Amérique latine, possède une grande disparité
agricole : D’un coté des milliers de fermes de moins d’un hectare, de
l’autre quelques immenses exploitations de plus de 10000 hectares, avec tous
les intermédiaires entre les deux.
Nous avons également refait ce
classement par la méthode des quantiles (déciles plus exactement) qui est
plus parlante dans ce cas.
D. Agrégation
des paramètres pour les données des producteurs.
Ces paramètres sont d’ordre
qualitatif : il y a des variables binaires, comme le sexe (bien qu’il y
ait toujours en plus un champ supplémentaire : « non
renseigné ») et des variables de classes comme le niveau d’études.
Même l’age peut être considéré comme une variable de classe car le champ « 99 »
ne signifie pas « 99 ans » mais « non renseigné ».
Mais pour ce paramètre âge on
choisira des intervalles de classe adaptés : par tranche de 10 ans plutôt
que année par année.
Les données agrégées des
producteurs seront donc toutes organisées par classes : on séparera donc chaque
fichier colonne (contenant les données pour un paramètre) en autant de fichiers
que de classes contenues dans le paramètre.
- Agrégation des 2
matrices : producteurs et exploitations
Pour pouvoir rentrer tous les
paramètres en même temps dans le programme nous allons agréger les 2 matrices
de données
Scilab réalise très facilement et
très rapidement cette fonction. (Syntaxe : z = [x y])
Auparavant nous avons dû trier
chacune des matrices par ordre croissant de l’identifiant. Ceci grâce à la
fonction gsort, également très rapide (car c’est une fonction
interne de Scilab ; si nous avions du créer une routine de tri à l’aide
d’une boucle « for… », l’exécution de l’algorithme aurait été
beaucoup plus longue).
Notons d’ailleurs ici que pour
optimiser un algorithme utilisant de telles matrices, on peut agir à deux
endroits :
-
S’assurer que la matrice est entièrement en mémoire,
pour limiter les accès disque,
-
limiter le nombre de passages en revue de cette matrice
avec des boucles « for », « while »…
- formatage des fichiers pour le
programme
Le programme demandera un certain
formatage pour le fichier d’entrée. Il y aura en fait trois fichiers, pour plus
de souplesse :
- Infopop.txt : Ce premier fichier
contiendra les informations globales de la population : reprise de
l’entête du fichier initial avec noms des paramètres, types de variables
et catégories, ainsi que des informations sur les différentes échelles
utilisées.
- codevillage.txt : Ce fichier contiendra
les codes de village de chaque ferme. Ce champ a été extrait de la matrice
principale pour plus alléger les accès mémoire.
- matpop.txt : C’est la matrice globale
sans les entêtes. Il contient tous les paramètres de toutes les fermes,
séparés par un caractère défini (ici : une virgule).
Nous avons ensuite étudié
les corrélations entre les paramètres de
la population dans le but de
déterminer ceux qui seront
utilisés par l’application au niveau de l’algorithme de minimisation
quadratique, c’est à dire ceux à partir desquels on va créer les contraintes
pour la population à générer.
En effet, il serait inutile et
coûteux en termes de mémoire et de temps de définir des contraintes provenant
de deux paramètres très corrélés car les prototypes générés auraient le même profil
si on prenait en compte un seul paramètre.
Quant aux paramètres non
utilisés, ils serviront pour la validation : On vérifiera ainsi que les
données agrégées de la population initiale et celles de la population générée
sont semblables pour ces paramètres (qui ne sont pas intervenus dans le
processus de recréation).
Nous avons calculé la corrélation
de toutes les combinaisons de paramètres pris deux à deux car même si certains
couples n’ont pas de sens, on est sur de
ne pas passer ceux qui pourraient se révéler intéressants.
Faute de temps nous nous sommes
limités à traiter les corrélations pour les données quantitatives mais pas pour
les données qualitatives (Données des producteurs) : pour exploiter ces
dernières, il aurait fallu transformer les variables qualitatives en variables
binaires.
L’algorithme en Scilab pour le
calcul des corrélations se situe à l’annexe 1.G
Nous obtenons le coefficient de
corrélation par la formule :
Coefficient de corrélation
= Covariance / produit des Ecarts Types des 2 séries de données
La fonction Scilab corr permettant
d’obtenir la covariance.
Notons ici une source d’erreur
possible : Scilab n’utilise pas les variances (écarts types au carré) de
la même façon qu’Excel pour le calcul du coefficient de corrélation.
 |
En effet Excel utilise la variance calculée pour une population : (fonction var.p) de formule :
Alors que Scilab utilise la variance
d’un échantillon,
de formule :
 |
Les résultats de l’analyse de
données sont présentés dans l’annexe 2.
Nous avons omis les diagrammes
qui portaient sur les municipalités car comme nous l’avons vus, ils se sont
révélés faux. Et le temps nous à manqué pour les refaire.
Malheureusement les corrélations
ont été faites entièrement au niveau des municipalités, nous ne pouvons donc
rien en tirer si ce n’est qu’elles ont montré que sur des données trop
disparates, comme les surfaces des fermes, les corrélations sont biaisées. ( Il
y avait par exemple une zone avec une ferme de plus de 13000 ha ! cette
disproportion augmentait artificiellement le coefficient de corrélation).
Le programme a été conçu sous Jbuilder 3.5.
L’interface utilise uniquement des composants swing.
Nous nous sommes assurés que le code soit vide de toute
classe sous licence Jbuilder (par exemple le VerticalFlowLayout : classe
servant à disposer facilement des objets graphiques alignés verticalement).
Les classes sont regroupées dans un package portant le nom
de JStatBox, qui est également le nom de l’application.
Le programme démarre à partir d’une classe Main qui
appelle une classe Interface. Celle-ci appellera à son tour les classes
des différents modules, au fur et à mesure qu’ils sont requis par
l’utilisateur. Fondamentalement les classes principales sont indépendantes de
l’interface graphique. Mais on ne peut pas les faire fonctionner de façon autonome pour autant (mode Batch)
car certaines opérations de l’utilisateur ne sont possibles que par l’intermédiaire
de l’interface (du moins pour
l’instant).
Nous allons décrire l’application module par module, en
partant d’une vision globale par l’approche UML pour décrire ensuite les
attributs et méthodes clés des classes de chaque module.
Le programme n’étant pas terminé à l’heure où nous écrivons,
nous nous concentrerons principalement sur le module Population et sur
l’interface.
C’est le module qui se charge de lire les données d’entrée,
de les traiter pour qu’elles soient facilement utilisables par les autres
modules, en les mémorisant sous forme d’arborescence de fichiers grâce à la
classe Echelle
Voyons sa structure sous forme de diagramme en modélisation
UML (nous ne faisons apparaître que les méthodes les plus importantes, les
méthodes d’accès aux données privées sont ignorées) :
Diagramme de
classe du module Population
Les classes prototype
et agrégation ont des relations de
composition vis à vis de la classe Population, tandis pour les objets
Echelle et ChoixAgreg , il n’y a qu’une seule instance de chaque par
classe Population.
Nous allons d’abord voir la classe Population puis voir
ensuite les classes qui lui sont subordonnées.
1)
Classe Population
La classe Population est l’objet
qui va contenir toutes les données concernant une population étudiée :
Attributs :
Vector vpop : vecteur contenant tous les prototypes
(objets prototypes) de la population étudiée.
Vector vagreg : vecteur contenant toutes les données
agrégées calculées (objets Agreg) de la population étudiée
char sep : le caractère
de séparation des données de la matrice globale.
Vector ventete : vecteur contenant le nom de chaque
paramètre.
Vector vcategorie : vecteur contenant la catégorie
(exploitation, producteur ou production) de chaque paramètre.
Vector vtype : vecteur
contenant le type (float, int, boolean…) de chaque paramètre.
Vector vech : vecteur contenant les noms des différentes
échelles de la population.
Vector vfraction : diviseur pour
l'agrégation (10000 pour dep , 100 pour mun, 1 pour village)
Vector vCodeEch :
contient la liste des codes village pour chaque prototype.
ChoixAgreg choixagreg : objet contenant tout les paramètres
d’agrégation et ceux qu’on aura sélectionnés effectivement pour le calcul des
données agrégées.
Echelle arbre :
l’arborescence des différentes sous régions.
Vector vreference :
vecteur contenant les références de chemin (sous forme d’objets File) de tous
les villages (c’est à dire la plus petite sous région de la population)
Méthodes :
public void lirefichierInfo(File
data, String nom) : lecture du fichier infopop.txt (informations sur les
paramètres et les échelles de la population ) en utilisant la classe
BufferedReader.
public void lirefichierData(File
data, String nom) : lecture du
fichier de données matpop.txt
public void lirefichierEchelle(File
data, String nom) : lecture du
fichier des codes village des prototypes codevilage.txt
public String getCodeEchelle(int
idxCode, int idxEch) : méthode qui
reçoit un n° de prototype et un niveau
d'échelle et qui renvoie le code d’échelle correspondant.
public void ecrirefichier(Population
pop, String fsortie, char separ) :
écriture de la matrice de population dans un fichier texte en utilisant
la classe BufferedWriter. Cette méthode a été écartée au profit d’une methode
plus efficace : l’écriture des données dans des répertoires
arborescents.(voir plus loin)
public void creeVreference(Vector
v) : méthode qui crée les références (sous forme d’objet File) aux différents
répertoires de l’arborescence, pour un accès plus rapide.
2)
Classe Prototype
L’objet Prototype représente un
vecteur ligne de la matrice de population c'est-à-dire une ferme avec tous ses
paramètres, contenus sous forme de chaîne de caractères dans un vecteur
(vligne) : D’abord l’identifiant puis les caractéristiques du terrain, les
caractéristiques de l’exploitant et enfin les caractéristiques des productions.
Attributs :
Vector vligne :
Vecteur contenant les paramètres d’un prototype, sous forme de chaînes de
caractère.
3)
Classe Agreg
L’objet Agreg représente une donnée agrégée pour un
paramètre donné, un outil d’agrégation (somme, variance…) et éventuellement un
paramètre de référence de classe.
Ce paramètre de référence de classe est un autre paramètre
de la population à partir duquel on peut découper le premier paramètre en un
certain nombre de classes. Ceci
A cet objet Agreg correspondra un fichier agreg.txt. Donc le
niveau d’échelle de l’agrégation n’a pas besoin d’être précisé puisqu’ il est
défini par l’endroit ou se situera le fichier dans l’arborescence de
répertoires.
Attributs :
String paraAgreg : nom du paramètre
agrégé sous forme codée
int codeType : le type des données
(elles sont traitées différemment si elles sont quantitatives ou qualitatives).
int refProto : le numéro de
paramètre sur lequel porte les données agrégées
int nbClasses : le nombre de
classes, si le paramètre a été séparé en classes. (par défaut c’est 1 si il n’y
a pas de découpage).
int refClasseProto : le numéro de
paramètre utilisé comme référence pour le découpage en classes.
int[] tabBorne : tableau des
intervalles de classes.
int[] tabData : tableau des
données agrégées pour chaque classe (de même taille que tabBorne)
4)
Classe échelle
Le but de cet objet est la création d’une arborescence de
répertoires qui reprendra la structure imbriquée des différentes sous régions
du pays étudié. Chaque répertoire (ou nœud de l’arbre) correspondra à un
district (département, municipalité, village…) et contiendra un fichier
d’informations. Ensuite viendront s’ajouter dans les répertoires de la dernière
échelle (ici les villages) des fichiers contenant les données des prototypes de
ces nœuds (village) en question.
On transforme donc la grande matrice de population en une
série de petits fichiers auxquels on accède lorsque l’on en a besoin, plutôt
que de charger en mémoire la matrice globale dans son ensemble.
Ensuite, on n’utilisera plus que cette structure en arbre
que l’on pourra charger au démarrage de
l’application et abandonner l’usage de la matrice globale.
L ‘arbre est en fait une liste chaînée d’objets
Echelle. Une méthode récursive crée un nœud et remplit ses descendants (sous
régions de ce nœud) avec cette même méthode (appel récursif), jusqu’à atteindre
la limite d’échelles.
La construction de l’arbre se fait par parcours en
profondeur des différentes échelles, pour n’avoir qu’un seul parcours de la
matrice de population globale. Un parcours en largeur aurait pris beaucoup plus
de temps.
Attributs :
Vector vfils : tableau contenant
la liste des objets échelle successeurs de l'objet Echelle courant
String nomEchelle : nom d’échelle
du nœud : "dep" si
l'objet Echelle est un département
int niveau : code correspondant au niveau d’échelle.
"1" si l'objet Echelle est un
département.
String code : numéro de district
int nbSousNiveau : taille du vecteur
vechelonLocal, c’est à dire le nombre de
descendants du nœud.
Vector vechelonLocal : tableau
des informations (sous forme d’objets InfoNoeud)
de chaque échelon contenu
dans l'objet échelle courant.
File ref : référence de chemin de
l’objet échelle (ex: global\dep_1\)
Méthodes :
Echelle creerArbre
(Population pop) : méthode qui initialise la création de l’arbre.
void remplir(Population
pop, int numProto, Echelle pere, int niveauCourant) : méthode récursive
qui crée un nœud de l’arbre et le remplit de ses descendants en s’appelant elle
même.
void writeArbre(Echelle
arb, File repPater, String repfils) : méthode qui crée les repertoires pour
chaque nœud de l’arbre et y ajoute des fichiers d’information.
void ecrireVpoptoProto(Population
pop) méthode qui écrit dans des fichiers séparés (et qui les placent dans
l’arborescence) les données de chaque village.
5)
Classe Infonoeud
Cette classe contient diverses informations pour chaque nœud
de l’arborescence.
Attributs :
String nom :
nom du nœud (département, municipalité, village…)
float superficie :
somme des superficies des fermes contenues
dans le nœud et ses descendants.
int nbProto :
nombre de fermes(producteurs) contenu dans le nœud et ses descendants.
6)
Classe ChoixAgreg
Paramètres de population, outils d’agrégation et échelles
peuvent varier d’une étude de cas à l’autre Ils doivent donc être définis sous
formes dynamiques : on utilise donc des
vecteurs pour les stocker. De même pour les 3 vecteurs qui leurs sont
associés et qui stockent les choix de l’utilisateur pour l’agrégation.
Attributs :
Vector vNomParam :
vecteur contenant la liste ordonnée des noms de paramètres affichés dans
l’onglet Statistiques
Vector vChoixParam :
vecteur contenant true ou false selon les paramètres choisis pour l’agrégation.
Vector vNomEchelle :
vecteur contenant la liste ordonnée des noms d’échelle affichés dans l’onglet
Statistiques
Vector vChoixEchelle :
vecteur contenant true ou false selon les échelles choisies pour l’agrégation.
Vector vNomOutil :
vecteur contenant la liste ordonnée des noms d’outils affichés dans l’onglet
Statistiques
Vector vChoixOutil :
vecteur contenant true ou false selon les outils choisis pour l’agrégation.
Méthodes :
void creervListeAgreg(Population
pop,String sEchelle) : méthode générale qui appelle les 3 suivantes :
void creervNomEchelle(pop,sEchelle) :
méthode qui crée le vecteur vNomEchelle et qui initialise le vecteur
vChoixEchelle à zéro.
void creervNomParam(pop) :
méthode qui crée le vecteur vNomParam et qui initialise le vecteur vChoixParam
à zéro.
void creervNomOutil() :
méthode qui crée le vecteur vNomOutil et qui initialise le vecteur vChoixOutil
à zéro.
Le module de statistiques a pour
but de fournir des méthodes pour créer les données
agrégées à partir des trois
types de paramètres que l’utilisateur aura choisi:
Echelles, Paramètres de la
population et outils d’agrégation.
Par outil d’agrégation nous entendons :
somme, variance, écart type, quantiles, voire fonctions plus élaborées par la
suite.
Ce module est en cours de codage à l’heure où nous écrivons.
Il comprend les deux algorithmes
que nous avons présenté antérieurement :
- L’algorithme de minimisation quadratique
provenant de « R ». La classe d’appel est créée et fonctionnelle
mais non encore implémentée dans le programme.
- l’algorithme de type génétique (SA2 : recuit
simulé) n’est pas encore créé.
L’interface dispose d’une barre
de menu : pour fonctions diverses dont choix de la langue
pour cela nous avons créé un
« Ressource Bundle » : organisation des chaînes de caractères
sur des fichiers différents pour chaque langue, ensuite on choisit quel fichier
charger pour avoir la langue voulue.
On voit ensuite un onglet pour
chaque module. Pour l’instant ne sont terminés que les onglets population et
statistiques. Puis viendrons s’ajouter les onglets Minimisation, et
Visualisation qui correspondent aux modules correspondants.
Voyons un aperçu de l’onglet
population (page suivante) :
A gauche : la liste des
paramètres lorsque la population est chargée.
Au milieu : les boutons de
lecture et d’écriture de la matrice de population et de l’arbre
d ‘échelles.
Lorsque la population n’est pas
chargée, les autres onglets sont inaccessibles, de même que les boutons qui
font références à la population chargée.
La fenêtre
principale avec l’onglet population
Voyons à présent un aperçu de
l’onglet Statistiques (page suivante) :
Il est constitué de trois
panneaux contenant des boutons à cocher créés dynamiquement.
Ces panneaux correspondent
aux paramètres à définir pour calculer
les données agrégées (Paramètres de population, Echelles, Outils).
A droite une liste de boutons
permettant de lancer ,de réinitialiser le processus de création des données
agrégées, et de sauver celles ci.
La fenêtre
principale avec l’onglet Statistiques
V. Conclusion
Bilan
Ce vaste projet est terminé en ce
qui concerne la partie analyse de données mais ne l’est pas pour l’application.
Au final les résultats de
l’analyse de données se révèlent mitigés au niveau de leur qualité, à cause
notamment d’une simple erreur de zéro qui a eu de fâcheuses conséquences.
Nous avons également entrevu la
difficulté de trouver des tests statistiques convenant le mieux aux différents
cas, c’est à dire capables de faire « parler » les données.
Et puis nous regrettons de
n’avoir pu disposer des données de production, certainement très riches en
information.
Quoi qu’il en soit cette première partie du
stage a rempli parfaitement son rôle de découverte des méthodes de
reconstruction de population et de préparation nécessaire à la deuxième partie.
En ce qui concerne l’application,
il reste beaucoup a faire. Un certain retard a été pris lorsque nous avons
travaillé sur la structure de l’objet Echelle, qui demandait une structure
parfaitement optimisée pour satisfaire les limitations en mémoire du programme.
Beaucoup de temps à également été passé au début de la phase de code, car la
programmation objet demande une certaine « mécanique de pensée » qui
ne s’acquiert qu’avec une pratique intensive.
En ce qui nous concerne, ce stage
a été doublement bénéfique puisqu’il nous a fait pratiquer de nombreuses
techniques statistiques et fait découvrir toute la conception d’un projet
informatique, depuis la formalisation UML jusqu’au codage en langage
objet.
Perspectives
D’ici la fin de notre stage, il
faudra tout d’abord terminer le noyau de base du programme : C'est-à-dire
le module Statistiques et le module Minimisation avec ses deux algorithmes de
minimisation.
Puis de nombreuses améliorations
seront à faire, dans le souci d’assurer une bonne succession du code pour la ou
les personnes qui prendront le relais du développement ( ce sera à priori
essentiellement notre maître de stage) Et il y a également le souci de fournir
un outil documenté et facile d’accès aux destinataires du programme.
Ainsi, nous prévoyons de :
- Documenter les classes en HTML
(avec javadoc)
- Ecrire un mode d’emploi
- terminer la localisation en
anglais et en espagnol.
Puis plus tard pourront être
réalisés :
- le module visualisation des
données.
- l’implémentation d’outils
statistiques évoluées dans module statistiques.
- la création d’un module
permettant de sauver et charger des plans d’expérience.
Ce projet est un point de départ.
On peux déjà imaginer la possibilité d’y greffer des modules dont les objectifs serviraient un autre
domaine, mais qui utiliseraient les structures et outils de cette application.
Références bibliographiques
Williamson P., Birkin M., Rees P. H. 1998, “The
estimation of population microdata by using data from small area statistics and
samples of anonymised records”. Environment and planning A 30
785-816.
Charlton J. 1998, “Use of the Census Samples of
anonymised Records (SARs) and survey data in combination to obtain estimates at
local authority level”. Environment and planning A 30 775-784.
Goldfarb D., Idnani A. 1983, “A numerically
stable dual method for solving strictly convex quadratic programs”. Mathematical
programming 27 1-33.
ANNEXES
1.A. Création des listes de code : département
et municipalité
Analyse
des données
Pour les caractéristiques des exploitations et des
producteurs
 |
Le nombre de fermes est très variable d’un département à l’autre (pour la plupart il y en a de 10000 à 25000). On note également de très faibles effectifs : le département 9 avec 3800 fermes et surtout le département 11 avec un peu plus de 300 fermes. C’est dans ce dernier que l’on notera plus tard de grandes différences avec les autres départements dans l’analyse des différents paramètres.
Au niveau village, la variabilité devient beaucoup plus
importante : les villages vont d’une seule ferme à 1391.(moyenne : 84
, variance : 7818).
Surfaces totales :
 |
Ces graphiques ne permettent pas de voir si il y a des zones de fermes de même taille.
(ex : municipalité contenant une majorité de grandes
fermes). On va donc séparer les tailles de fermes en classes de superficie
(voir plus loin).
Répartition de la taille des fermes suivant la méthode
des déciles :
Intervalles :
surface totale (Ha)
|
% de fermes dans
l’intervalle
|
|
0
|
0,068
|
0
|
0,068
|
0,616
|
10
|
0,616
|
0,685
|
10
|
0,685
|
1,027
|
10
|
1,027
|
1,37
|
10
|
1,37
|
2,055
|
10
|
2,055
|
2,74
|
10
|
2,74
|
4,658
|
10
|
4,658
|
8,219
|
10
|
8,219
|
19,863
|
10
|
19,863
|
13461,644
|
10
|
100
|
||
Corrélations entre fermes de grande et de petite
taille :
On ne voit pas de corrélation évidente : le fait qu’il
y ait de grandes ou très grandes fermes n’empêche pas la présence de fermes de
petite taille : ceci est confirmé par le graphique suivant :
On voit qu’il n’y a pas de fortes différences entre les
municipalités : toutes contiennent des fermes de tailles variées en
proportions comparables (sauf pour les fermes de très grande taille qui sont
rares et plutôt dispersées parmi les municipalités).
On note cependant pour le département 15 une proportion plus faible de fermes de 0 à 1
Ha au profit de fermes plus grandes (10 à 50 mais aussi 50 à 100).
a)
Propriété des terres
 |
Propriété des terres
On voit de grandes variations pour les classes « terres
personnelles » « terres nationales » et « ejidales »
(les 3 classes les plus représentées).
Par exemple le département 9 contient une majorité de terres
nationales.
Le département 15 qui possède également une part importante
de terres nationales. (Corrélation possible avec le fait que ce département
comporte beaucoup de fermes de grande taille).
b)
Usage des terres
Ici on observe beaucoup de
variabilité, pour presque tous les paramètres, mais on ne distingue pas de
corrélation particulière.
Les terres semblent avoir un
usage agricole similaire dans toutes les régions. On notera cependant la
concentration de « plans d’eau » dans le département 6 (lac
… ?)
a)
Condition juridique
La quasi-totalité des fermes sont individuelles. Ceci
explique la forte corrélation de ce paramètre avec la surface totale.
b)
Age du producteur
Pas de différence fondamentale de classes d’âge entre les différentes
municipalités (à part le département 11 : faible pourcentage de 20-29 ans)
c) Sexe
du producteur
Il y a à priori peu de variations de sexes entre
départements : environ 10% de femmes sauf dans le département 9 ou il y en
a presque 30% .
d) Alphabétisation
Alphabétisation : 50 à 60 % en moyenne sauf département
11 : plus de 90% (mais c’est un
département de très petite taille : effet d’une variance plus
élevée ?).
e) Niveau
d’études atteint et niveau d’études validé
Le niveau d’études se situe pour tous les départements entre
« aucun » et « primaire » avec un pourcentage similaire
(sauf pour département 11 : peut être à cause de sa taille).
Aucun commentaire:
Enregistrer un commentaire