Projets on Benjamin Geer

Comparer les performances de requêtes SQL

Thu, 29 Jan 2026 18:25:18 +0100

J’ai réalisé un petit programme en Rust, sqlstopwatch, pour comparer les performances de différentes requêtes SQL. J’ai été inspiré par l’article Benchmarking SQL publié par le projet jOOQ, dans lequel le code du test est implémenté en SQL. Je voulais quelque chose de semblable, mais j’avais quelques exigences supplémentaires :

Un programme en ligne de commande avec une interface utilisateur simple en mode texte (TUI) qui affiche une barre de progression.
Le programme devrait prendre en charge PostgreSQL, MySQL et SQLite.
Il devrait lire les requêtes SQL et les paramètres du test dans un fichier de configuration indiqué sur la ligne de commande.
Il devrait afficher les résultats sous forme de table dans le terminal ou les enregistrer dans un fichier au format CSV que je puisse utiliser pour générer un diagramme.

L’interface utilisateur a été facile à réaliser avec Ratatui. Pour interagir avec la base de données, j’ai utilisé la bibliothèque asynchrone sqlx, qui fournit une bibliothèque SQLite embarquée.

J’ai pensé à utiliser le format TOML pour le fichier de configuration, mais le fichier doit fournir les identifiants de connexion. Dans les environnements de test, il se peut que les identifiants doivent être chargés à partir de variables d’environnement ou de fichiers sur un système de fichiers monté, mais TOML ne permet pas d’effectuer de telles opérations. En plus, on pourrait vouloir générer plusieurs requêtes similaires pour les comparer, comme je l’ai fait dans ce projet d’optimisation de base de données. Par conséquent, il vaut mieux que le fichier de configuration soit un programme dans un langage de script. Mon exercice d’implémentation d’un interpréteur de langage de script m’avait permis d’apprécier à sa juste valeur la machine virtuelle Lua. Le fichier de configuration est donc un script en Lua, que je trouve plus commode de rédiger en Fennel, un dialect de Lisp qui se compile en Lua. Grâce à la bibliothèque mlua, il a été très facile d’embarquer un interpréteur Lua dans le programme et d’utiliser Serde pour convertir des tables Lua en structs Rust.

Créer un client Bittorrent en Rust

Thu, 15 Jan 2026 15:16:01 +0100

Aperçu #

Pour continuer mon apprentissage de Rust, j’ai décidé de réaliser un client pour Bittorrent, le protocole de transfert de données pair-à-pair. Les clients Bittorrent que j’ai utilisés ont des interfaces graphiques complexes qui semblent destinées aux gens qui téléchargent des torrents à longueur de journée, plutôt que pour l’utilisateur occasionnel comme moi, qui veut tout simplement obtenir un seul fichier. Et comme beaucoup d’applications à interface graphique, les clients Bittorrent ont tendance à accumuler des fichiers qui occupent de l’espace disque dans des répertoires obscurs. Je fais beaucoup de choses dans le terminal et quand j’ai besoin de télécharger un fichier, mon réflexe est d’utiliser curl. Je me suis donc dit, pourquoi ne pas créer quelque chose comme curl pour Bittorrent ? En pensant à l’indicateur de progression de curl, l’idée m’est venue à l’esprit de faire quelque chose de semblable avec Ratatui, une bibliothèque de création d’environnements en mode texte (TUI), que je voulais de toute façon essayer.

La réalisation d’un client Bittorrent semblait être une bonne occasion d’apprendre la programmation asynchrone en Rust. J’avais lu beaucoup de critiques d’async en Rust, mais je l’ai trouvé agréable à utiliser (en utilisant la bibliothèque Tokio) et certainement plus confortable que les infrastructures logicielles comparables que j’avais utilisées en Scala (Akka et Cats Effect). J’aime particulièrement le fait qu’une fonction async peut être exécutée dans une tâche existante ou dans sa propre tâche, à la différence du Future de Scala, qui est affecté à un fil d’exécution et se lance dès sa construction. L’approche de Rust semble mieux adapté au remaniement et à la maintenabilité. En même temps, je suis content de ne pas avoir à gérer la complexité liée à l’utilisation des monades comme dans Cats Effect.

Le résultat est Sayaca, qui porte le nom d’un oiseau sud-américain qui joue un rôle important dans la dispersion des graines (le verbe anglais to seed veut dire ensemencer, et dans la terminologie de Bittorrent, envoyer des données aux autres pairs).

La conception #

Ma première tâche a été de réaliser un analyseur syntaxique pour Bencode, le format de données utilisées dans le protocole Bittorrent. Au niveau conceptuel, Bencode ressemble à JSON, mais il est destiné à la représentation de données binaires plutôt que textuelles. J’avais envie d’essayer d’utiliser une bibliothèque de combinateurs d’analyseurs syntaxiques, et je n’ai pas eu de mal à implémenter l’analyseur en utilisant nom. Comme je voulais être en mesure de sérialiser et de désérialiser des structs en Rust au format Bencode, j’ai ajouté la prise en charge de la bibliothèque Serde. J’ai publié la crate issue de ce travail sous le nom de bside.

La principale difficulté dans la conception du client résidait dans le caractère confus des spécifications Bittorrent. Il y a des ambigüités (le mot piece a deux sens différents) et les implémentations se sont écartées des spécifications (par exemple, les identifiants de pair ne sont pas utilisés pour identifier les pairs). Une grande partie des informations relatives au protocole ne figure pas dans les spécifications officielles, mais dans d’autres documents dispersés sur le Web. Il y a une longue liste (non mise à jour depuis 2018) de projets d’extension du protocole qui sont pris en charge par de nombreux clients. Une extension dite de chiffrement (qui semble en réalité décrire une forme de brouillage) semble être largement mise en œuvre, mais d’après ce que je peux en juger, depuis 2023, sa spécification n’est conservée que dans la Wayback Machine de l’Internet Archive. Il existe un projet de spécification du protocole BitTorrent v2 (non mis à jour depuis 2017) qui tente de corriger certains défauts du protocole d’origine, comme sa dépendance vis-à-vis de la fonction de hachage SHA-1 (qui n’est plus considérée comme sécurisée depuis 2005). J’aurais pu errer longtemps dans un dédale de documents et dans le code source des clients existants. Pour simplifier les choses, j’ai décidé de ne mettre en œuvre que le protocole d’origine et l’extension IPv6 tracker.

Quand un client Bittorrent enregistre des données sur le disque, il devrait offrir de bonnes performances avec des fichiers volumineux, être capable d’interrompre un téléchargement et de le reprendre plus tard (ce qui signifie qu’il doit noter quels fragments ont été téléchargées) et gérer les torrents qui comprennent plusieurs fichiers. Pour faire tout cela, et pour que les choses soient claires pour l’utilisateur, j’ai choisi d’enregistrer les données téléchargées dans un fichier intermédiaire (avec l’extension .sayaca), dans le même répertoire où les fichiers finaux seront enregistrés. Le fichier intermédiaire contient un champ de bits indiquant les fragments qui ont été téléchargés (il s’agit du même champ de bits qu’il faut de toute façon envoyer aux pairs). Pour lire et écrire ce fichier, Sayaca utilise la projection en mémoire, ce qui devrait offrir de bonnes performances d’entrée-sortie avec des fichiers volumineux. Une fois le téléchargement terminé, il copie les données depuis le fichier intermédiaire vers les fichiers finaux. Lorsque le programme se ferme, le fichier intermédiaire est supprimé s’il n’est plus nécessaire.

Comme un client Bittorrent est tributaire des entrées-sorties (I/O bound), j’ai décidé d’employer une architecture événementielle dans laquelle une seule tâche accomplit la majeure partie du travail, comme dans Redis. Cette tâche principale délègue toute les entrées-sorties réseau à d’autres tâches, avec lesquelles elle communique via des canaux. Cela a été très simple à mettre en œuvre et a eu l’avantage de rendre facile la création de tests unitaires pour la tâche principale.

Une grande partie du travail effectué par un client Bittorrent revient à tenir une sorte de comptabilité. Dans Sayaca, ce travail est la responsabilité du Bookkeeper (« comptable »). Par exemple, dans l’algorithme recommandé de sélection des fragments à demander aux pairs, le client essaie de demander d’abord les fragments les plus rares. Cela nécessite une structure de données qui note les fragments dont dispose chaque pair, ainsi que la rareté de chaque fragment, entre autres. Il y a plusieurs façons de réaliser cela et j’ai décidé d’utiliser un tableau associatif ordonné, trié par ordre de rareté, pour stocker les identifiants de fragments et les ensembles de pairs qui les possèdent. Le Bookkeeper peut ainsi trouver facilement un fragment, choisi au hasard parmi les plus rares, associé à un pair choisi au hasard parmi ceux qui possèdent ce fragment et qui nous ont autorisé à leur envoyer des demandes. Ainsi une grande partie du travail du client consiste à mettre à jour le Bookkeper lors de la réception de nouvelles informations et à l’interroger pour savoir ce qu’il faut faire ensuite.

J’aime bien les TUI et il a été facile de créer un TUI simple avec Ratatui. Mais comme le client est une bibliothèque qui communique avec son interface utilisateur via des canaux, il serait simple d’intégrer le client dans une autre interface utilisateur, comme une interface en ligne de commande plus accessible.

D’autres approches possibles #

J’ai choisi d’utiliser Tokio parce que je voulais en savoir plus à son sujet et sur async, mais je pense que le programme n’aurait probablement pas été très différent si j’avais utilisé des fils d’exécution à la place, avec la même communication via des canaux.

Créer une machine virtuelle en Rust

Sun, 12 Oct 2025 00:00:00 +0000

Aperçu #

Pour m’aider à apprendre le langage Rust, j’ai décidé de réaliser un interpréteur pour Lox, le langage de script que Robert Nystrom a créé pour son livre Crafting Interpreters. Je m’intéresse aux langages de script qui sont destinés à être embarqués dans des applications, et cet exercice m’a semblé un bon moyen d’en savoir plus sur la construction de ce type de langage.

Le livre de Nystrom présente, étape par étape, le développement de deux versions de l’interpréteur. Alors que la première, en Java, parcourt un arbre de syntaxe abstraite (AST) pour exécuter un script, la deuxième, en C, comporte une machine virtuelle qui exécute du bytecode. Cette deuxième version m’intéressait davantage. Au fil des ans, j’avais réalisé deux interpréteurs qui parcourent des arbres de syntaxe abstraite, en commençant par Apache FreeMarker, ainsi qu’un compilateur source à source optimisant utilisant l’inférence de types. Mais je n’avais pas encore fait de machine virtuelle. L’idée me rappelait de bons souvenirs de programmation en assembleur sur l’Apple II quand j’avais quinze ans. Le jeu d’instructions de la machine virtuelle de Nystrom est plus simple que celle du processeur Motorola 6502 de l’Apple II, mais le principe est le même. J’ai donc sauté la première partie du livre pour aller directement à celle où il s’agit de la machine virtuelle.

Le résultat est OrganicLox. La conception est globalement celle présentée dans le livre, mais j’ai essayé de coder dans un Rust courant, en visant des performances raisonnables, sans écrire de code non sécurisé. Les fonctionnalités d’OrganicLox devraient être identiques à celles du programme clox de Nystrom : au moins, ses 246 tests automatisés passent.

J’ai décidé de ne pas créer mon propre ramasse-miettes, car tout le monde semble s’accorder à dire que les ramasse-miettes sont particulièrement difficiles à réaliser en Rust. Par souci de simplicité, j’ai opté plutôt pour le comptage des références (au moyen de Rc). Sur la branche main, cela veut dire que les cycles de propriétés d’objets ne seront pas nettoyés. Sur la branche with_dumpster_gc, j’ai remplacé Rc par la crate dumpster, qui assure le comptage des références et nettoie aussi les cycles.

Ce que j’ai préféré #

J’ai beaucoup aimé ce livre : les explications claires de Nystrom, ses illustrations utiles, son style léger et son humour ont rendu le livre agréable à lire.

Pour moi, la mise en œuvre des variables locales et des fermetures dans une machine virtuelle à pile ont été parmi les aspects les plus intéressants de la conception que présente Nystrom, conception qui s’inspire largement de celle de l’interpréteur Lua. J’ai aimé apprendre que le compilateur associe les variables locales à des positions spécifiques sur la pile, de sorte que la machine virtuelle n’a besoin de connaître que ces positions et non pas les noms des variables concernés.

La mise en œuvre des upvalues, à savoir les variables qui sont capturées par les fermetures et qui doivent donc éventuellement être allouées sur le tas, n’a pas été simple à faire correctement. En corrigeant un bogue, j’ai été heureux de me rendre compte que l’appel récursif d’une function définie dans une portée locale nécessite que la fermeture de la fonction soit une des ses propres upvalues.

Ce que j’aurais souhaité #

Les explications de Nystrom sont tantôt ascendantes, tantôt descendantes. L’approche ascendante a présenté plus de difficultés quant à la traduction de sa conception en Rust, car je devais deviner où il voulait en venir. Plusieurs fois j’ai dû remanier beaucoup de code parce que je n’avais pas deviné juste. Comme l’implémentation de Lox dans toutes sortes de langages de programmation semble être un exercice courant, il aurait été utile d’avoir plus souvent une vue d’ensemble de la conception.

Cela m’a fait plaisir de découvrir la technique de Pratt pour construire un analyseur syntaxique descendant reposant sur la précédence des opérateurs et de constater qu’il est vraiment possible de générer du bytecode sans d’abord construire un AST. Mais il aurait peut-être été plus utile de construire un AST et d’apprendre quelque chose sur la conception d’une deuxième phase pour optimiser le bytecode.

La performance #

L’optimisation principale que j’ai faite au départ a été de faire en sorte que l’analyseur lexical mette tous les identifiants dans un pool de chaînes de caractères (en utilisant string_interner), pour que ni le compilateur ni la machine virtuelle aient à comparer des chaînes représentant des identifiants.

Après avoir fini le chapitre 24, j’ai passé un peu de temps à me pencher sur la performance, en suivant les conseils du Rust Performance Book. J’ai fait des tests de performance avec criterion et du profilage avec perf et hotspot, j’ai ajusté la configuration du compilateur Rust and j’ai marqué quelques fonctions inline.

Ensuite j’ai regardé quelques autres versions de Lox en Rust et j’ai remarqué que tout le monde semble avoir eu du mal à obtenir des performances proches de celles du clox de Nystrom et que les versions qui y arrivent comportent beaucoup de code non sécurisé, ce que je voulais éviter.

Je recommande vivement billet de blog de Manuel Cerón sur sa tentative impressionnante, déterminée et partiellement réussie d’égaler la vitesse de clox en Rust en écrivant de plus en plus de code non sécurisé.

À titre de comparaison, voici les résultats de l’exécution de quelques-uns des tests de performance de Nystrom sur les versions suivantes :

Le clox de Nystrom
La version sécurisée du loxido de Cerón
La version non sécurisée de loxido
OrganicLox avec Rc
OrganicLox avec le ramasse-miettes dumpster

OrganicLox avec Rc est donc deux à quatre fois plus lent que clox, ce qui est peut-être typique des interpréteurs réalisés en Rust par rapport à ceux réalisés en C. La version avec dumpster est beaucoup plus lente. Il semble clair qu’un ramasse-miettes rapide est essentiel pour une machine virtuelle très performante.

Quelle est l’importance de ces différences ? Les tests de performance sont conçus pour simuler des scénarios extrêmes, par exemple en utilisant de longues boucles ou la récursivité profonde, ou en créant une charge de travail importante pour le ramasse-miettes. Ils ne sont donc pas forcément représentatifs des cas d’utilisation réels. Il arrive souvent que les scripts exécutés par une application dans un interpréteur embarqué sont courts et font très peu de travail. On pourrait se faire une idée plus réaliste de la performance d’une machine virtuelle dans un tel scénario en exécutant la suite de tests d’intégration de Nystrom, qui exécute 246 scripts courts en Lox et vérifie leurs sorties. Voici une comparaison :

Dans une application où chaque cycle CPU compte, les écarts entre les performances de ces différentes implémentations pourraient avoir beaucoup d’importance. Mais dans d’autres cas d’utilisation, ils pourraient être insignifiants.

D’autres approches possibles #

Il est tentant d’essayer d’ajouter un compilateur à la volée (JIT) pour améliorer la performance de l’interpréteur, soit en en écrivant un à partir de zéro, soit en en utilisant un backend existant comme LLVM ou Cranelift. Roto et Dora sont des exemples en Rust de cette approche. Mais même si on adopte cette démarche, il n’est pas facile d’atteindre un haut niveau de performance. Dans ces tests de performance, le nouveau JIT de Python n’a aucun effet mesurable sur les performances (voir aussi ces résultats de tests de la performance de Dora).

Voilà une raison d’envisager d’utiliser un interpréteur existant qui a déjà bénéficié d’années de développement, plutôt que d’en créer un nouveau. Le langage Lua est une option largement utilisée, mais il n’est pas assez rapide pour certaines applications. La machine virtuelle LuaJIT est un ordre de grandeur plus rapide que la machine virtuelle Lua standard pour certains cas d’utilisation, mais c’est un compilateur à la volée basé sur les arbres de traces, ce qui a des avantages et des inconvénients. Les développeurs de Lua ont publié un article intéressant qui traite des limites de cette approche et propose une autre solution (un langage supplémentaire à typage statique, un peu comme Cython).

Pour certains cas d’utilisation, si des scripts embarqués ne font pas beaucoup de travail, leurs performances pourraient ne pas être critiques. S’ils font tellement de travail que leurs performances sont insuffisantes, une autre option consiste à ne pas intégrer d’interpréteur du tout. Cloudflare, qui avait investi massivement pendant plus de 20 ans dans des scripts en utilisant LuaJIT embarqué dans OpenResty, les a récemment remplacés par du code Rust.

Calculer des mesures de centralité avec le réseau de transport en commun parisien

Fri, 29 Aug 2025 00:00:00 +0000

J’ai pensé qu’il serait intéressant d’essayer un peu d’analyse de réseau élémentaire en utilisant le réseau du métro et du RER parisiens, en commençant par des indices de centralité. Il s’agit de mesures qui classent les sommets d’un graphe en fonction de leur importance, selon une définition quelconque de l’importance. Par exemple, dans un réseau de transport, la centralité d’une station pourrait donner une indication de la probabilité que les passagers passent par cette station au cours de leur itinéraire. Un opérateur de transports en commun pourrait utiliser ces informations pour évaluer les inconvénients que causerait la fermeture de certaines stations, par exemple en raison d’inondations ou de travaux, et pour l’aider à identifier les moyens les plus efficaces d’améliorer la résilience du réseau. J’utiliserai ici Python, networkx et SQLite.

Construire le graphe #

J’ai choisi ici de faire un seul graphe qui comprend le métro et le RER. Le premier problème est de construire ce graphe en établissant la liste de liens et la liste de sommets. Les établissements qui régissent les transports en commun parisiens ne fournissent pas de tel jeu de données, mais ils fournissent un jeu de données GTFS qui représente les horaires prévus sur toutes les lignes de transport pendant les 30 prochains jours. (Je tiens à remercier Oliver Blanthorn de me l’avoir signalé.) Les données GTFS représentent les courses (les séquences d’arrêts) que les trains devraient parcourir sur les lignes de métro ou de RER. Pour construire la liste de liens du réseau, nous pouvons parcourir chaque course, en enregistrant un lien entre chaque arrêt et l’arrêt suivant. Certaines courses vont dans une direction, d’autres dans la direction inverse, et beaucoup ne comprennent pas tous les arrêts de la ligne, mais en les parcourant toutes, nous devrions accumuler un graphe orienté complet du réseau. Il faudra parcourir environ 64 000 courses, qui comprennent au total presque 1,5 million d’arrêts, et une grande partie des données sera redonante pour nous, mais cela n’a pas d’importance tant que le traitement des données ne prend pas trop de temps.

Il s’agit donc de réaliser un procédé ETL (Extract, transform, load). D’abord j’ai créé un script shell qui télécharge les données GTFS, ainsi que plusieurs fichiers d’un jeu de données qui s’appelle Référentiel des lignes de transport en commun d’île-de-France, dont nous aurons également besoin. Comme tous ces fichiers sont au format CSV et utilisent des identifiants uniques pour relier les données des différents fichiers, notre tâche sera plus facile si nous utilisons une base de données relationnelle. Dans un deuxième script shell, j’importe les fichiers pertinents dans une base de données intermédiaire gérée par SQLite et je crée quelques index pour accélérer les requêtes de l’étape de transformation. Ce script s’exécute en 21 secondes environ sur mon ordinateur portable et la taille de la base de données obtenue est de 2,1 Go.

Enfin, j’ai créé un script Python pour les étapes de transformation et de chargement. Il lit la base de données intermédiaire et construit la base de données de sortie, qui ne contient que la table de liens et la table de sommets. Comme la base de données de sortie est petite (132 Ko), le script la crée en mémore pour améliorer la performance de cette étape, puis la sauvegarde quand elle est complète. L’exécution de ce script prend environ 8 secondes.

Dans le Référentiel, les liens entre le métro et le RER sont représentés par des zones de correspondance et des pôles d’échange, qui peuvent comprendre plusieurs stations reliées par des couloirs. Pour inclure ces relations dans le graphe, j’ai choisi d’ajouter des liens entre toutes les stations faisant partie du même groupe.

La base de données de sortie représente un multigraphe orienté, puisque deux stations peuvent être reliées par plusieurs lignes. Dans un tel cas, nous pouvons considérer que les deux stations en question ont un lien plus fort que deux stations qui ne sont reliées que par une seule ligne. Toutes choses étant égales par ailleurs, plus il y a de lignes entre deux stations, plus il y aura de passagers qui voyagent entre les deux. Nous conserverons ces informations sur les liens multiples en faisant nos calculs.

Visualiser des parties du graphe #

Visualisons d’abord une partie des données pour vérifier qu’elles sont correctes. Nous pouvons créer une fonction qui affiche le graphe d’un réseau de transport. Ici, nous nous intéressons uniquement aux sommets et aux liens, et non pas à leur position géographique. Pour repérer facilement les lignes, nous pouvons utiliser les couleurs précisées pour le plan du réseau, qui se trouvent dans le jeu de données GTFS, ainsi que le noir pour les liens que j’ai ajoutés pour les zones de correspondance et les pôles d’échange.

%config InlineBackend.figure_formats = ['svg']
import sqlite3
import pandas as pd
import networkx as nx
import numpy as np
import matplotlib.pyplot as plt
import itertools as it


def draw_graph(G, title, height, label_x_offset):
    plt.figure(figsize=(12, height))
    plt.margins(x=0.18, y=0)
    plt.title(title)

    pos = nx.nx_agraph.graphviz_layout(G, prog="dot")

    # See https://networkx.org/documentation/stable/auto_examples/drawing/plot_multigraphs.html
    connectionstyle = [f"arc3,rad={r}" for r in it.accumulate([0.15] * 4)]

    nx.draw_networkx_nodes(G, pos, node_size=30, node_color="#000000")

    edge_colors = [
        f"#{G[source_node_id][target_node_id][edge_key]["route_color"]}"
        for source_node_id, target_node_id, edge_key in G.edges
    ]

    nx.draw_networkx_edges(
        G, pos, edge_color=edge_colors, connectionstyle=connectionstyle
    )

    label_pos = {
        node_id: (node_pos[0] + label_x_offset, node_pos[1])
        for node_id, node_pos in pos.items()
    }

    text = nx.draw_networkx_labels(
        G,
        label_pos,
        labels=nx.get_node_attributes(G, "node_name"),
        horizontalalignment="left",
        verticalalignment="bottom",
        font_size=6,
    )

    for _, t in text.items():
        t.set_rotation(15)

Essayons avec les lignes de métro 1 et 4 et le RER A:

DATABASE = "../../../notebook-data/paris-rail-data/paris-graph.db"

conn = sqlite3.connect(f"file:{DATABASE}?mode=ro")

nodes = pd.read_sql_query(
    """select distinct
        nodes.node_id, nodes.node_name
    from nodes
    inner join edges on
        nodes.node_id = edges.source_node_id or
        nodes.node_id = edges.target_node_id
    where
        (edges.route_type = 1 and edges.route_name = '1') or
        (edges.route_type = 1 and edges.route_name = '4') or
        (edges.route_type = 2 and edges.route_name = 'A') or
        (edges.route_type is null and
            (edges.route_name = 'PdE Châtelet - Les Halles' or
            edges.route_name = 'ZdC Gare de Lyon'))""",
    conn,
    index_col="node_id",
)

edges = pd.read_sql_query(
    """select * from edges where
        (edges.route_type = 1 and edges.route_name = '1') or
        (edges.route_type = 1 and edges.route_name = '4') or
        (edges.route_type = 2 and edges.route_name = 'A') or
        (edges.route_type is null and
            (edges.route_name = 'PdE Châtelet - Les Halles' or
            edges.route_name = 'ZdC Gare de Lyon'))""",
    conn,
).replace({np.nan: None})

G = nx.from_pandas_edgelist(
    edges,
    source="source_node_id",
    target="target_node_id",
    edge_attr=True,
    create_using=nx.MultiDiGraph(),
)

node_attributes = nodes.to_dict(orient="index")
nx.set_node_attributes(G, node_attributes)

draw_graph(
    G,
    title="Les lignes de métro 1 et 4 et le RER A",
    height=20,
    label_x_offset=6,
)

Cela semble correct.

Visualiser les résultats #

Les fonctions proposées par networkx pour le calcul des mesures de centralité renvoient un dictionnaire dont les clés sont des identifiants de sommet et dont les valeurs sont des scores de centralité. Nous pouvons créer une fonction qui accepte un tel dictionnaire et affiche un diagramme à barres des 25 stations les plus importantes par ordre décroissant de centralité.

def centrality_chart(centrality_dict, title):
    names_and_scores = [
        (node_attributes[item[0]]["node_name"], item[1])
        for item in centrality_dict.items()
    ]

    top_25 = sorted(names_and_scores, key=lambda t: t[1], reverse=True)[:25]

    top_25_df = pd.DataFrame(
        top_25,
        columns=["Station", "Score de centralité"],
    ).set_index("Station")

    ax = top_25_df.plot.barh(title=title)
    ax.invert_yaxis()

La centralité de degré #

Lisons d’abord l’intégralité du graphe :

nodes = pd.read_sql_query(
    "select * from nodes",
    conn,
    index_col="node_id",
)

edges = pd.read_sql_query(
    "select * from edges",
    conn,
).replace({np.nan: None})

conn.close()

G = nx.from_pandas_edgelist(
    edges,
    source="source_node_id",
    target="target_node_id",
    edge_attr=True,
    create_using=nx.MultiDiGraph(),
)

node_attributes = nodes.to_dict(orient="index")
nx.set_node_attributes(G, node_attributes)
print(f"{len(G.nodes)} sommets et {len(G.edges)} liens chargés.")

563 sommets et 1363 liens chargés.

La mesure de centralité la plus simple est la centralité de degré : pour chaque sommet, nous pouvons compter ses liens entrants ou sortants et normaliser le résultat en le divisant par $n - 1$, où $n$ est le nombre de sommets. Dans ce cas présent, les resultats sont les mêmes pour la centralité de degré entrant et la centralité de degré sortant.

1
2

in_degree_centrality_dict = nx.in_degree_centrality(G)
centrality_chart(in_degree_centrality_dict, "Centralité de degré entrant")

On voit tout de suite que les stations ayant les scores le plus élevés sont surtout des stations de métro plutôt que des stations RER. Une explication possible serait la structure apparemment plus radiale du réseau RER par rapport au métro. En plus d’être situées sur plusieurs lignes, plusieurs de ces stations (telles que Havre-Caumartin) font partie d’un pôle d’échange.

La centralité de vecteur propre #

Avec la centralité de vecteur propre, chaque sommet reçoit un score proportionnel à la somme des scores de ses voisins. Un sommet peut ainsi obtenir un score élevé en ayant beaucoup de voisins et/ou en ayant des voisins dont le score est élevé. Dans un graphe non orienté à $n$ sommets, la centralité de vecteur propre $x_i$ d’un sommet $i$, dont l’ensemble des voisins est $M(i)$, est définie par :

$$ x_i = \frac{1}{\lambda} \sum_{j \in M(i)} x_j $$

où $\lambda$ est une constante. Nous pouvons écrire cette équation en utilisant la matrice d’adjacence $A$ du réseau, dans laquelle $a_{ij}$ est égal à 1 s’il y a un lien entre les sommets $i$ et $j$ et à 0 s’il n’y en a pas :

$$ x_i = \frac{1}{\lambda} \sum_{j = 1}^n a_{ij} x_j $$

Cela équivaut à :

$$ \mathbf{x} = \frac{1}{\lambda} A\mathbf{x} $$

où $\mathbf{x}$ est un vecteur dont les éléments sont les scores de centralité. On peut donc écrire :

$$ A\mathbf{x} = \lambda\mathbf{x} $$

Il s’ensuit que $\lambda$ est une valeur propre de $A$ et que $\mathbf{x}$ est le vecteur propre correspondant. Étant donné les valeurs propres et les vecteurs propres de la matrice, il est simple de choisir le vecteur propre pertinent, car (selon le théorème de Perron-Frobenius), pour une matrice (comme la matrice d’adjacence) qui n’a pas d’éléments négatifs, seul le vecteur propre associé à la plus grande valeur propre peut être choisi de façon à ce qu’il n’ait pas d’éléments négatifs. Avec un graphe orienté comme notre réseau de transport, on peut choisir un vecteur propre à gauche ou un vecteur propre à droite. On préfère d’habitude le vecteur propre à gauche (et c’est ce que fait networkx), de sorte que le score d’un sommet dépend de ses liens entrants plutôt que de ses liens sortants. Cela ne change pas grand-chose dans le cas présent, car presque tous les liens entrants de notre réseau ont un lien sortant correspondant.

Lorsque la centralité de vecteur propre est utilisée avec un graphe orienté, celui-ci doit être fortement connexe. C’est le cas de notre réseau de transport, car chaque station est accessible depuis toutes les autres :

`1`	`nx.is_strongly_connected(G)`

True

Nous utiliserons ici la fonction networkx.eigenvector_centrality_numpy, qui construit d’abord la matrice d’adjacence. Dans un multigraphe orienté comme le nôtre, s’il y a $n$ liens allant dans le même sens entre deux sommets, networkx les représente par la valeur $n$ dans la matrice, ce qui équivaut à un seul lien d’intensité $n$. Ensuite il obtient le vecteur propre pertinent et renvoie un dictionnaire qui contient chaque identifiant de sommet et l’élément correspondant du vecteur propre.

1
2

eigenvector_centrality_dict = nx.eigenvector_centrality_numpy(G)
centrality_chart(eigenvector_centrality_dict, "Centralité de vecteur propre")

Si on compare ces résultats à ceux obtenus pour la centralité de degré, on peut constater que la station Havre-Caumartin, qui se trouve au milieu du pôle d’échange Paris Saint-Lazare - Opéra (qui comprend six stations), obtient un score plus élevé parce qu’elle est adjacente à deux stations, Saint-Lazare et Opéra, qui ont des scores élevés. Plusieurs autres stations, dont Saint-Augustin, Auber et and Haussmann Saint-Lazare, obtiennent des scores plus élevés pour la même raison.

La centralité d’intermédiarité #

La centralité d’intermédiarité compte le nombre de fois où un sommet se trouve sur un des plus courts chemins (c’est-à-dire qui traversent le moins de sommets possible) entre chaque paire d’autres sommets. Pour un sommet $v$, elle est définie par :

$$ c_B(v) =\sum_{s \neq v \neq t} \frac{\sigma(s, t|v)}{\sigma(s, t)} $$

où $s$ et $t$ sont n’importe quels autres sommets du réseau, $\sigma(s, t)$ est le nombre de plus courts chemins de $s$ à $t$ et $\sigma(s, t|v)$ est le nombre de ces chemins qui passent par $v$. Dans un réseau de transport, un station dont $c_B(v)$ a une valeur élevée est une station par laquelle beaucoup de passagers passeront probablement s’ils choissisent un des plus courts chemins menant à leur destination.

1
2

betweenness_centrality_dict = nx.betweenness_centrality(G)
centrality_chart(betweenness_centrality_dict, "Centralité d’intermédiarité")

La plupart des stations figurant sur cette liste sont des stations RER plutôt que des stations de métro, ce qui est logique, car le RER couvre une plus grande distance entre les arrêts. Ainsi, si le même trajet peut être effectué en métro ou en RER, le trajet le plus court sera généralement celui en RER. Il n’est pas surprenant de voir Châtelet les Halles en tête de liste, compte tenu de sa situation géographique centrale et du grand nombre de lignes qui passent par son pôle d’échange. Il semble qu’il y ait aussi d’autres configurations qui peuvent donner un score élevé à une station. Par exemple, Juvisy se trouve sur un long tronçon du RER C où il y a peu de correspondances, et elle est reliée à un tronçon semblable du RER D. Il semble donc probable que beaucoup de plus courts chemins doivent passer par cette station.

Conclusion #

Ceci n’est qu’une brève exploration de quelques mesures de centralité pour ce réseau, avec quelques exemples illustrant comment différentes définitions de l’importance d’un sommet peuvent donner lieu à des scores différents. Tous les scripts utilisés ici se trouvent dans le dépôt Git de ce blog, ainsi que le calepin Jupyter à partir duquel j’ai généré cette page. N’hésitez pas à me contacter pour toute question ou suggestion.

Mal partum

Thu, 06 Mar 2025 00:00:00 +0000

En 2024 j’ai fait les sous-titres anglais du court-métrage Mal partum, un beau documentaire sur la dépression post-partum. Émilie D. s’est appuyée sur son expérience personnelle pour réaliser un film qui apporte des connaissances pratiques dont nous pouvons tous nous servir.

كوكبنا

Fri, 20 Sep 2024 15:00:00 +0000

Un podcast en arabe que j’ai commencé en 2021, sur l’écologie, la migration et les inégalités, et que j’aimerais me remettre à publier un jour : كوكبنا.شبكة.

Tondauer

Fri, 20 Sep 2024 14:00:00 +0000

En 2020 j’ai commencé un projet qui s’appelle Tondauer, pour faire des éditions de partitions sous licence Creative Commons. C’est arrivé à cause du confinement lié au Covid-19 cette année-là. J’apprenais à jouer le Prélude Op. 104a, n° 2 (MSV U 123) de Felix Mendelssohn, parce qu’il convenait bien à mon sentiment de frustration et à mon humeur agitée à l’époque.

J’ai commencé par une édition du XIXe siècle qui pouvait être téléchargée gratuitement. Puis j’ai acheté une édition qui proposait des doigtés, et je me suis demandé pourquoi elle avait des notes différentes. J’ai cherché sans succès le manuscrit du compositeur, ne trouvant qu’un brouillon antérieur. Ayant lu la biographie de Mendelssohn écrite par R. Larry Todd, je lui ai envoyé un mail pour lui demander s’il savait où se trouvait le manuscrit de la version finale. Il m’a répondu que celui-ci n’avait pas été trouvé. Cela signifiait que les seules sources étaient les premières éditions, publiées après la mort du compositeur.

En travaillant dans le domaine des humanités numériques, j’avais appris quelque chose sur la façon dont les éditions critiques sont réalisées. J’ai donc décidé de faire ma propre édition critique. Pendant plusieurs mois, au fur et à mesure de la réouverture des bibliothèques et des archives, j’ai reçu des reproductions numériques des deux premières éditions, une allemande et une britannique. Les deux éditeurs avaient travaillés ensemble pour les publier simultanément, mais elles ne contenaient pas non plus les mêmes notes. Dans mon édition, j’ai essayé d’expliquer de façon plausible ce qui s’était passé et de reconstituer au mieux les intentions du compositeur. Finalement j’ai essayé de faire l’édition que j’aurais voulu avoir, en ajoutant des doigtés grâce à l’aide de Penelope Roskell.

Plus récemment, j’ai travaillé avec la musicologue Florence Launay sur des éditions d’œuvres oubliées de compositrices, en commençant par les Preludes for Piano d’Armande de Polignac. Ces pièces subsistaient uniquement dans un seul exemplaire de la première édition, conservé par les descendants de la compositrice. Florence l’avait photocopié et des pianistes avaient enregistré ces pièces en utilisant des photocopies de cette photocopie. Maintenant que nous avons publié une édition corrigée avec la préface de Florence, j’espère que d’autres pianistes prendront plaisir à jouer ces Préludes.

Ressources sociologiques

Fri, 20 Sep 2024 13:00:00 +0000

Mon ancien blog (2013-2021) sur la sociologie de l’autonomie et l’autonomie de la sociologie.

أبحاث لفتت نظري

Fri, 20 Sep 2024 12:00:00 +0000

Mon ancien blog en arabe (2009-2014), sur lequel je résumais des recherches que je trouvais intéressantes : أبحاث لفتت نظري.