Séminaire : QAMML : une famille de distributions de probabilité pour l’Analyse de Données Fonctionnelles

Ce jeudi 2 mai à 14h le laboratoire Quaresmi aura le plaisir d’organiser son troisième séminaire intitulé : 

QAMML : une famille de distributions de probabilité pour l’Analyse de Données Fonctionnelles, par Étienne Cuvelier.

Les données fonctionnelles deviennent de plus en plus courantes. Ces données peuvent résulter des mesures répétées d’un phénomène au cours du temps, mais aussi lors de la variation d’un paramètre non temporel, comme par exemple une longueur d’onde. Ces données sont l’objet de l’Analyse de Données Fonctionnelles, ou Functional Data Analysis (FDA) en anglais. De telles données peuvent aussi avoir une origine statistique, comme lorsqu’on veut « résumer » le contenu d’une variable en utilisant sa distribution de probabilité, comme c’est le cas en Analyse de Données Symboliques.

Si ce type de données est souvent stocké sous forme discrétisée, c’est à dire sous forme multivariée, ces données sont par nature de dimension infinie. L’approche classique qui, consiste à appliquer des techniques multivariées aux versions discrétisées de ces données, donne lieu à un paradoxe : la minimisation de la perte d’informations lors du stockage, par augmentation de la finesse de discrétisation, est confrontée au fléau de la dimension, à savoir la raréfaction des données lors de l’augmentation de la dimensionnalité. La mise au point d’outils directement conçus pour ce type de données spécifiques que sont les données fonctionnelles est donc impérative. Mais l’infinité dimensionnelle de celles-ci rend difficile la mise au point de ce type d’outils, et c’est particulièrement vrai lors de la construction d’un incontournable en analyse de données : la notion de distribution de probabilité d’une variable aléatoire fonctionnelle.

Dans cet exposé, nous nous attacherons, tout en restant dans le cadre de l’analyse de données, à définir et construire une classe de distributions de probabilités directement définies dans l’espace de dimension infinie dans lequel sont plongées les données fonctionnelles. Cette classe de distributions, dénommées QAMML, est développée en associant un générateur de copule Archimédienne à une moyenne quasi-arithmétique.

Cette nouvelle famille de distributions de probabilités pour données fonctionnelles, nécessite aussi de définir un nouveau type de densité de probabilité, ce que nous faisons en utilisant la dérivée directionnelle de Gâteaux.

Notre approche n’est pas uniquement théorique, car nous illustrons l’utilité de ces distributions en analyse de données en « injectant », telles quelles, les distributions QAMML dans deux algorithmes initialement conçus dans le cadre de l’analyse multivariée : la classification non supervisée par décomposition de mélange et la classification supervisée bayésienne. Nous illustrons aussi l’usage de ces distributions en statistique en construisant des intervalles de confiance fonctionnels. Ces trois « illustrations » étant réalisées sur des données réelles.

Séminaire ouvert à tous. La présentation aura lieu à l’ICHEC, site Anjou, local E103. Pour faciliter l’organisation, merci de vous inscrire auprès de  celine.engelbeen@ichec.be

Au plaisir de vous y voir nombreux.

Conférence EGC2020

Le laboratoire Quaresmi est particulièrement heureux de vous annoncer qu’il sera l’organisateur de la 20ème  édition de la conférence “Extraction et Gestion de Connaissance”.

La conférence Extraction et Gestion des Connaissances (EGC) est un événement annuel réunissant des chercheurs et praticiens de disciplines relevant de la science des données et des connaissances. Ces disciplines incluent notamment l’apprentissage automatique, l’ingénierie et la représentation de connaissances, le raisonnement sur des données et des connaissances, la fouille et l’analyse de données, les systèmes d’information, les bases de données, le web sémantique et les données ouvertes, etc.

La conférence EGC est l’occasion de faire se rencontrer académiques et industriels afin de confronter des travaux théoriques et des applications pratiques sur des données réelles et de communiquer des travaux de qualité, d’échanger et de favoriser la fertilisation croisée des idées, à travers la présentation de travaux de recherche récents, de développements industriels et d’applications originales.

N’hésitez pas à consulter (gratuitement) les actes de l’édition 2019, comprenant les articles des communications orales ainsi que ceux associés aux posters via la revue RNTI. Les actes des ateliers sont disponibles via les pages de ceux-ci (lien). Vous pouvez aussi accéder aux slides des keynotes et enfin les vidéos des différentes sessions seront bientôt disponibles sur Canal C2.

Cette 20ème édition se déroulera sur le site de l’ICHEC situé Boulevard Brand Withlock (sis à côté du rond-point Montgomery). L’organisation de cette édition “anniversaire” se fera en étroite collaboration avec l’association EGC.

De plus amples informations bientôt.

Stay tuned, suivez-nous sur Twitter : 

Atelier DAHLIA – EGC 2019

Ce mardi 22 janvier, j’ai eu l’occasion de présenter brièvement notre travail réalisé sur une partie de l’œuvre de l’encyclopédiste médiéval Vincent de Beauvais lors de l’atelier DAHLIA (Groupe de travail DigitAl Humanities and cuLtural herItAge) qui précédait la conférence EGC 2019 à Metz.

Face au volume très important que représente l’ensemble des encyclopédies médiévales, la question de l’identification des sources utilisées par les encyclopédistes paraît naturelle, mais représente une tâche colossale et fastidieuse pour les historiens si elle est entreprise manuellement. Le but de ce travail présenté est de créer un outil d’identification automatique des sources utilisées par Vincent de Beauvais dans ses livres 16 à 22 du speculum naturale.

Afin de créer cet outil, il a été nécessaire de découper en petites entités, appelées notices, les différentes œuvres sur lesquelles nous avons travaillé. Pour le speculum maius de Vincent de Beauvais, cette division existait déjà. Cette présentation, ainsi que les questions du public, ont été l’occasion de revenir sur la façon dont nous avons choisi d’effectuer ce découpage pour les différentes sources utilisées. Je suis également revenue brièvement sur les conséquences de cette subdivision sur l’outil.

Python va-t-il tuer R ?

Le présent

Le dernier sondage en date du site KDnuggets semble annoncer une domination future du langage Python sur le langage R dans le “petit monde”  des data sciences et du machine learning. En 2016 R pouvait encore toiser Python puisque 42% des sondés déclaraient utiliser l’implémentation open source du langage S contre 34% pour le langage au nom inspiré par les inénarrables Monty Pyhton ( 8.5% annonçant utiliser les deux) . En 2017 la tendance s’inverse : 36% pour R et 41% pour Python (et 12% pour les deux) : 

Graphique de l'évolution des parts de marché de R et Python en 2016 et 2017.

Source : KDnuggets

La tendance haussière de Python n’est pas nouvelle puisque la part d’utilisateurs de ce langage augmente de façon quasi-constante depuis 2014, en ayant par ailleurs doublé son nombre de déclarants dans ces enquêtes depuis 2014 :

Graphique de l'évolution des parts de marché de R et Python de 2014 à 2017.

Source : KDnuggets

On pourrait contester ce résultats en se basant sur le fait qu’il ne s’agit que d’enquêtes en ligne avec un bon millier de répondants. Outre le fait que ce nombre de répondants est assez classique et statistiquement suffisant pour des résultats fiables, ces résultats ne contredisent pas des enquêtes plus larges : celles d’IEEE Spectrum ou de TIOBE .

Au vu de la forte progression de Python, on peut légitimement se poser la question du titre : Python va-t-il finalement (et rapidement?) tuer R ?

La transition

Ce qui me parait particulièrement intéressant dans l’article de KDnuggets c’est le schéma suivant :

Schéma de transition entre les langages R, Python, le deux et les autres en 2017.

Source : KDnuggets

Ce dernier permet de visualiser précisément quelles sont les proportions de répondants qui sont restés fidèles à leur(s) langage(s) ou qui ont migré d’une situation à l’autre. Cela m’a rappelé un article que j’avais particulièrement apprécié  : The eigenvector of “Why we moved from language X to language Y”. Dans cet article Erik Bernhardsson avait scrappé des données à  propos des requêtes Google du type from <language 1> to <language 2>, switch to <language 2> from <language 1>. Et il en avait fait une matrice de transition pour essayer de prédire le futur… Je me suis inspiré de cet article pour appliquer la même technique aux résultats 2017 de KDnuggets.

Les informations reprises dans la figure ci-dessus peuvent être traduites en la matrice de transition suivante :

P=\begin{matrix} \begin{matrix} Pyth & Both & R & Others\end{matrix} & \\ \left( \begin{matrix} 0.91 & 0.04 & 0.05 & 0.01\\0.38 & 0.49 & 0.11 & 0.01\\0.10 & 0.15 & 0.74 & 0.01\\0.19 & 0.04 & 0.17 & 0.60 \end{matrix}\right) & \begin{array}{l} Pyth \\ Both\\ R\\ Others\end{array} \end{matrix}

Cette matrice se lit assez facilement :

  • chaque ligne représente une situation (utilisateurs de Python, utilisateurs des deux langages, …),
  • chaque colonne représente une transition possible : de la situation X vers Python pour la première, de la situation X vers les deux langages pour la deuxième,…

Par exemple la première ligne est celle des utilisateurs (ou déclarés comme tels) de Python en 2016. Ceux-ci sont restés fidèles à ce langage dans 91% des cas, ont utilisé les deux en 2017 pour 4%, ont migré vers R dans 5% des cas et vers d’autres langages pour 1% d’entre eux.  Les autres lignes peuvent se lire de façon similaire. Comme de toute situation de départ en 2016 on doit arriver à une situation existante en 2017, la somme de chacune des lignes doit faire 1. Malheureusement ce n’est pas le cas pour les lignes 1 et 2 qui dont les sommes valent respectivement 1.01 et 0.99. Ne sachant d’où vient cette très probable erreur d’arrondi (même après avoir cherché les “données brutes” sur le site de KDnuggets) j’ai appliqué une correction générale à chacune des lignes en les divisant respectivement par leurs sommes ce qui donne donc la belle matrice de transition suivante :

P=\left( \begin{matrix} 0.9009901 & 0.03960396 & 0.04950495 & 0.00990099\\0.3838384 & 0.49494949 & 0.11111111 & 0.01010101\\0.1000000 & 0.15000000 & 0.74000000 & 0.01000000\\0.1900000 & 0.04000000 & 0.17000000 & 0.60000000 \end{matrix} \right)

 

Les pourcentages utilisateurs déclarés en 2016 peuvent aussi s’écrire sous cette forme :


\pi^{(2016)}=\begin{matrix}\left(\begin{matrix} 0.34\\0.08\\0.42\\0.16\end{matrix}\right) & \begin{array}{l}Pyth \\ Both\\ R\\ Others\end{array} \end{matrix}

C’est ce que l’on appelle un vecteur d’état : il donne la probabilité de chacun des états (ici un état étant “utilisateur de…”) . La somme des nombres d’un tel vecteur devant aussi faire 1 puisque tout sondé doit se retrouver dans un des états. C’est pour respecter cette contrainte d’unité de la somme que j’ai corrigé le 8.5% en 8% en supposant que c’est une erreur puisque la somme valait 1.05 (j’aurais aussi pu tout diviser par 1.05 comme ci-dessus).

De même la situation de 2017 peut s’écrire 

\pi^{(2017)}=\begin{matrix}\left(\begin{matrix} 0.41\\0.12\\0.36\\0.11\end{matrix}\right) & \begin{array}{l}Pyth \\ Both\\ R\\ Others\end{array} \end{matrix}

L’avantage, une fois que tout est écrit sous cette forme, c’est qu’en supposant que la matrice P est une matrice stochastique décrivant un processus de Markov on peut facilement calculer ce qui se passe d’année en année (sous la supposition forte que les probabilités de transitions ne changeront pas au cours du temps), ainsi on peut écrire que :

\pi^{(2017)}= P^{\tau} \cdot \pi^{(2016)}

Et effectivement si on effectue ce calcul on retrouve, aux arrondis prés, les valeurs pour 2017:

P^{\tau} \cdot \pi^{(2016)}=\left(\begin{matrix} 0.4093163\\0.1243145\\0.3624638\\0.1039054\end{matrix}\right)

Bien entendu on peut continuer le processus et estimer ce qui se passera en 2018 (toutes choses restants égales par ailleurs comme disent les économistes) : 

\pi^{(2018)}= P^{\tau} \cdot \pi^{(2017)}=\left(\begin{matrix}0.4724950\\0.1362657\\0.3199630\\0.0712762\end{matrix}\right)

Ce sera à vérifier dans un an mais il semblerait donc que Python continuera à violemment gagner du terrain alors que la position de R continuera à s’effriter, pendant que les utilisateurs des deux progresseront timidement.

Le futur?

Évidemment, à ce stade,  on a en généralement envie (les mathématisants en tous cas)  de continuer le processus pour voir si la situation finit par se stabiliser :

\pi^{(2018)}, \pi^{(2019)}, \pi^{(2020)}\cdots, \pi^{(20xx)} \longrightarrow v

C’est évidemment assez facile à calculer en utilisant un langage comme R (!) (ou Python pour être tout à fait honnête) mais, quand s’arrêter?  “Quand les chosent se stabilisent”  pourrait-on dire platement. Mais les mathématiciens et les probabilistes se sont bien entendu déjà penchés sur ce genre de question et la réponse est assez simple : il suffit d’utiliser le concept (très puissant mais mal aimé des étudiants) de vecteurs propres et de valeurs propres. Pour rappel un vecteur v est vecteur propre de valeur propre \lambda si et seulement si :

A \cdot v= \lambda \cdot v

Or il se fait que la définition d’un état stable est assez proche car un état est dit stable pour les processus de Markov quand l’application de la matrice de transition ne change plus rien c’est-à-dire quand :

P^{\tau}\cdot v = v

en d’autres termes, un état stable est un vecteur propre de valeur propre 1. 

Si on calcule ce vecteur v pour notre match Python vs R on obtient :

v=\begin{matrix}\left(\begin{matrix} 0.67257910\\0.11156674\\0.19159885\\0.02425531\end{matrix}\right) & \begin{array}{l}Pyth \\ Both\\ R\\ Others\end{array} \end{matrix}

Ce qui signifie que dans un horizon “relativement” proche(1), Python dominerait en raflant le 2/3 du marché alors que R se contenterait d’une niche de 20% et, surprise, les utilisateurs des deux langages resteraient assez limités à  11%.

Conclusion

Évidemment, comme dans la citation prêtée à Niels Bohr (mais aussi à d’autres) :

les prévisions sont difficiles surtout lorsqu’elles concernent l’avenir.

 

Il faut donc être prudent. Mais néanmoins le jeu  des prévisions est toujours excitant et il est difficile de ne pas s’y prêter.  

Même si la répartition future entre R et Python sera vraisemblablement, au moins sensiblement, différente de celle prédite ici, la répartition de parts de chacun des langages me paraît assez plausible. En effet, outre la progression fulgurante de Python ces dernières années, ce dernier me paraît avoir des avantages décisifs (et mon coeur d’aficionados de R saigne en l’écrivant) par rapport à R. Celui-ci est un langage de programmation dédié aux statistiques et autre analyses de données, et dans ce rôle il fait un boulot remarquable, notamment soutenu par un écosystème très dynamique avec une pléthore de packages , dont certains très spécialisés. Et c’est, selon moi, une de ses forces car on peut y trouver des packages qui contiennent l’implémentation de méthodes issues directement de travaux de recherche récents. On peut donc, en tant que chercheur, y tester très rapidement de nouvelles idées. Par contre, il n’est pas  spécialement adéquat pour être utilisé “en production” pour des projets industriels avec des données massives (même si c’est possible). 

L’avantage premier de Python est que c’est un langage de programmation généraliste pour lequel on est occupé à créer des environnements/librairies dédiées aux calcul scientifique et aux data science :

Ecosystème Python pour le Machine Learning

Source: http://python.astrotech.io/machine-learning/wprowadzenie-do-machine-learning.html

Ce qui signifie que ce langage, doté de ces boîtes à outils, permet non seulement d’effectuer des analyses de données mais permet aussi de développer de véritables applications. Avantage non négligeable dans un environnement business. Et, cerise sur le gâteau, ce langage permet de développer des applications web, “d’entreprise” (sur ordinateur) et embarquées comme l’illustre ci-dessous la copie d’écran du tableau de la page d’IEEE Spectrum

 The Top Programming Languages 2018

Source : IEEE Spectrum

Même si actuellement Python n’est pas aussi riche en librairies que R et que ce dernier se débrouille nettement mieux en termes de visualisations (mais les choses changeront sans doute dans le futur), il me parait assez inéluctable que ce dernier se voie finalement retranché dans la seule niche scientifique, pour laquelle il a été a priori créé. Il vivrait ainsi un destin un peu similaire au langage Pascal, créé pour l’enseignement et qui, au vu du nombre d’étudiants ayant appris à coder avec lui se retrouvant sur le marché du travail, a vu une carrière “commerciale” s’ouvrir à lui avant que celle-ci  ne finisse par se refermer, entre autres pour des raisons techniques (comme l’absence initiale de chaînes de caractères à zéro terminal), et qu’il ne se retrouve confiné dans sa niche éducative (même si on le retrouve encore à la 17ème place du classement TIOBE).  En espérant pour R que cette niche scientifique ne soit pas elle-même réduite à peau de chagrin. La bonne nouvelle, a priori, c’est que l’on peut espérer répondre non à la question initiale.

Signé : un utilisateuR heuReux  que son langage pRéféRé se soit pas déjà condamné à une moRt rapide, même si il a déjà un peu commencé à pRogrammer en Python, on n’est jamais tRop pRudent ;).

 

(1) Un horizon de 9 à 11 ans toutes choses restant égales par ailleurs. J’ai essayé d’évaluer ce laps de temps en regardant après combien de temps |\pi^{(20xx)} - v| était en moyenne plus petit que 1% ou que le maximum de ces différences soit plus petit que 1%. Bien entendu si les proportions de migrations changent, il en sera de même de cet horizon temporel (retour au texte).