• J’ai installé une nouvelle lib avec pip install et maintenant tout est cassé
• J’ai un venv que je veux reproduire en prod, comment faire ?
• J’ai installé python 3.10.2 et 3.11.2 mais je ne comprend pas comment utiliser l’un ou l’autre ?
• C’est quoi ce tas de trucs incomprehensibles avec pip, easy_install, poetry, conda, virtualenv, pdm ?
• Pourquoi des fois je vois des setup.py, et parfois des pyproject.toml ? Pourquoi des lockfiles pdm.lock ou poetry.lock ?
• J’ai mon venv qui marche niquel, avec pleins de belles librairies de data science, je fais un pip install d’une nouvelle lib et paf, tout est cassé, ça marche pas je ne sais pas pourquoi ?
• JE VEUX JUSTE UN TRUC SIMPLE QUI ME PERMETTE DE DEV DANS DES NOTEBOOKS DE MANIERE PRAGMATIQUE COMMENT JE FAIS ?

Pré-requis:

Avoir soit un linux sur lequel on peut installer ce qu’on veut, soit un wsl sous windows pour pouvoir travailler efficacement (l’install est simple désormais: https://learn.microsoft.com/en-us/windows/wsl/install), avoir un python d’installé (il y en a normalement un par défaut dans la plupart des linux couramment utilisés), ainsi que pip (idem)

J’ai installé une nouvelle lib avec pip install pandas et maintenant tout est cassé

Lorsqu’on fait un:

pip install pandas

directement dans le terminal sans autre précaution, on installe une librairie dans le système global, ça pose problème:

• Si on a un autre projet qui a besoin d’une autre version de pandas que ce projet courant, on ne pourra pas faire co-exister les deux
• On risque de modifier la version de pandas utilisée par l’autre projet (et donc le casser)

Dans ces deux cas on peut avoir des messages d’erreur parfois un peu obscurs, nous disant qu’il y a conflit.

Pour résoudre ce problème, en python on utilise des “environnements virtuels”, c’est à dire un mécanisme qui permet d’isoler les version de python et les dépendances.

Généralement, on va vouloir avoir un environnement virtuel (ou venv) par projet.

Pour en créer un:

python -m venv projet_a_env

Puis on l’active (on se “met dedans”)

source projet_a_env/bin/activate

On peut alors simplement installer les librairies qu’on souhaite:

pip install pandas

Si on veut sortir de l’environnement virtuel:

deactivate

On revient alors dans le système global, pandas n’est plus installé:

J’ai un venv que je veux reproduire en prod, comment faire ?

pip freeze > requirements.txt

Le fichier requirements.txt est ici de la forme:

numpy==1.24.4
pandas==2.0.3
python-dateutil==2.9.0.post0
pytz==2024.1
six==1.16.0
tzdata==2024.1

Puis une fois dans le nouveau venv de prod :

pip install -r requirements.txt

J’ai installé python 3.10.2 et 3.11.2 mais je ne comprend pas comment utiliser l’un ou l’autre ?

On peut vite se retrouver à devoir gérer plusieurs versions de python sur la même machine (dépendamment des projets sur lesquels on travaille). Pour gérer ce problème, le plus simple est d’installer et d’utiliser pyenv:

curl https://pyenv.run | bash

puis:

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc

(si vous utilisez zsh ou un autre shell, voir la doc https://github.com/pyenv/pyenv)

Ensuite on va installer les dépendances nécessaires (ici sur ubuntu/debian) pour pouvoir compiler d’autres versions de python:

sudo apt update
sudo apt install -y make build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm \
libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

Ensuite, c’est simple, pour installer une version de python sur le système:

pyenv install 3.10.2

Puis pour switcher vers une version de python spécifiquement pour le projet courant:

pyenv local 3.10.2

Ceci créé un fichier .python-version, qui contient donc la version de python du projet.

Quand vous créérez un venv, il sera automatiquement utilisé.

C’est quoi ce tas de trucs incomprehensibles avec pip, easy_install, poetry, conda, virtualenv, pdm ?

• pip: gestionnaire de paquets standard de python
• easy_install: un ancien outil d’installation de paquet, une autre époque, oublie
• poetry: un gestionnaire de paquet plus moderne qui résout pas mal de problemes de pip, notamment la gestion de conflits de paquets dans un venv, ainsi que la gestion de dépendances primaires et secondaires (voir après).
• conda: Gestionnaire de paquet et d’environnements pythons, populaire dans la communauté scientifique. J’ai eu plusieurs soucis d’exports windows/linux pour reproduire des environnements condas, ne suit pas vraiment les standards python, utilise son propre mécanisme d’environnements virtuels. Peut être bien dans un cadre scientifique, mais pas dans les cadres industriels que j’ai rencontrés.
• pdm: Comme poetry, en mieux: respecte les standards python, permet d’avoir plus de contrôle sur la construction et le publish des wheels, notamment.

Pourquoi des fois je vois des setup.py, et parfois des pyproject.toml ? Pourquoi des lockfiles pdm.lock ou poetry.lock ?

• setup.py: permet d’installer le projet courant comme paquet (pip l’utilisait quand on faisait pip install ). C’est l’ancienne façon de faire, à oublier
• pyproject.toml: standard depuis 2016 qui remplace le setup.py, et est le point de configuration central du projet, i.e., quelles sont les dependances primaires, de dev, comment build le projet, comment le distribuer, quelles sont les metadonnées, etc.

Lorsqu’on fait un “pip install pandas” et qu’on liste les dépendances, on a vu plus haut que ça nous donne une liste de toutes les librairies installées, c’est à dire à la fois les dépendances primaires, et les dépendances secondaires, si bien qu’on peut se retrouver perdu à ne plus s’y retrouver. Avec le pyprojet.toml, on obtient une liste de toutes les dépendances primaires:

Dans le fichier pdm.lock ou poetry.lock on va avoir les dépendances secondaires, c’est à dire les dépendances de dépendances. Elles vont être utiles pour pouvoir recréer le venv à l’identique ailleurs:

J’ai mon venv qui marche bien, avec pleins de belles librairies pour la data science, je fais un pip install d’une nouvelle lib et paf, tout est cassé, ça marche pas ?

Il y a en fait deux cas:

• Ca casse notre env car il y a une incompatibilité fondamentale et ça met le bazar sans nous dire pourquoi, c’est moche

Ici on installe d’abord seaborn puis numpy dans une version incompatible. Seaborn ne fonctionne plus: on a certes un message d’erreur, mais pas de rollback, le venv est dans état non fonctionnel pour notre code.

• Ca upgrade automatiquement une lib précédente, qu’on avait pourtant fixée :

Par exemple on installe numpy dans une version 1.1.15, on fait notre code, puis plus tard on installe seaborn. A ce moment là, numpy va automatiquement être mis à jour vers une version plus récente (sans nous demander notre avis), et donc potentiellement ne sera plus compatible avec notre ancien code.

En fait dans ces deux cas nous sommes dans des exemples de “dependency hell”:

Ici on est dans un cas simple, mais imaginez la complexité lorsqu’on a des dépendances au 5ème degré, avec des dizaines de librairies…

Pour mieux gérer ces problèmes, qui peuvent vite vous faire perdre des années de vie, je conseille d’utiliser pdm (https://pdm-project.org/en/latest/), et ce pour plusieurs raisons:

• Le rollback fonctionne, si on essaie d’installer quelque chose, on revient dans l’état du venv précédent qui lui était fonctionnel
• Lorsqu’on essaie d’installer une librairie où il y a un conflit, on a un message clair qui nous guide pour trouver une solution
• On a une séparation claire des dépendances primaires et secondaires
• On respecte les normes pep strictement (ce qui n’est pas le cas de poetry, par exemple)
• On peut choisir la façon de build ses wheels pour distribuer son programme, contrairement à poetry qui force son propre outil de build (qui a déjà été bloquant pour moi)
• Il est assez efficace

JE VEUX JUSTE UN TRUC SIMPLE QUI ME PERMETTE DE DEV DANS DES NOTEBOOKS DE MANIERE PRAGMATIQUE COMMENT JE FAIS ?

Si on est sous windows, installation du wsl en administrateur, le powershell on oublie:

wsl --install

Installation de pdm:

sudo apt install python3.10-venv
curl -sSL https://pdm-project.org/install-pdm.py | python3 -
echo export PATH=/home/romain/.local/bin:$PATH >> ~/.bashrc
source ~/.bashrc

Installation de pyenv et choix de la version de python:

curl https://pyenv.run | bash
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc

sudo apt update
sudo apt install -y make build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm \
libncursesw5-dev xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev

pyenv install 3.11.2
pyenv local 3.11.2

Creation du dossier de travail

mkdir my_project

Creation de l’environnement virtuel (répondre aux questions qui apparaissent pour initialiser le projet)

pdm init

Ajout de librairie(s)

pdm add pandas

Ajout de ipykernel pour pouvoir utiliser notre venv directement dans notre notebook

pdm add ipykernel

Attention: pdm créée par defaut le venv dans .venv, faire un “ls - a” pour le voir

On peut alors sélectionner l’environnement virtuel directement dans le notebook, dans vscode par exemple.

• Python (wich should install Pylance for static type checking)
• Ruff, one tool for linting, black formatting, isort etc
• Jupyter (Keymap, Slide show, cell tags)
• Coverage gutters for code coverage
• Remote ssh/explorer to connect to distant servers easily (no need for jupyther hub now)
• GitLens to supercharge git
• Vim
• Material icon theme
• Theme (publisher:”Mhammed Talhaouy”), personnal preference

Configuration file

Here is my config file, useful to handle copy paster in vim, or autolaunch ruff on save for example:

{
	"editor.minimap.enabled": false,  
	// Bracket-pair colorization  
	"editor.bracketPairColorization.enabled": false,  
	"notebook.diff.ignoreMetadata": true,  
	"gitlens.hovers.currentLine.over": "line",  
	"workbench.iconTheme": "material-icon-theme",  
	"files.autoSave": "afterDelay",  
	"git.confirmSync": false,  
	"jupyter.notebookFileRoot": "${workspaceFolder}",  
	"vim.commandLineModeKeyBindingsNonRecursive": [],  
	"vim.useSystemClipboard": true,  
	"vim.handleKeys": {  
		"<C-c>": false,  
		"<C-v>": false,
		"<C-j>": false  
	},  
	"vim.visualModeKeyBindingsNonRecursive": [  
	{  
		"before": [  
			"p",  
		],  
		"after": [  
			"p",  
			"g",  
			"v",  
			"y"  
		]  
	}  
	],  
	"[python]": {  
		"editor.formatOnSave": true,  
		"editor.codeActionsOnSave": {  
		"source.organizeImports": true,  
		"source.fixAll": true  
		},  
		"editor.formatOnType": true,
 		"editor.defaultFormatter": "charliermarsh.ruff"
	},  
	"python.analysis.typeCheckingMode": "basic",  
	"python.analysis.autoImportCompletions": true,  
	"python.analysis.stubPath": "",  
	"python.analysis.indexing": true,  
	"python.terminal.activateEnvironment": false,  
	"workbench.colorTheme": "Theme",  
	"gitlens.views.branches.branches.layout": "list",  
	"explorer.confirmDragAndDrop": false,  
	"files.exclude": {  
	"**/__pycache__": true,  
	"**/.pytest_cache": true  
	},  
	"python.analysis.inlayHints.pytestParameters": true,  
	"pythonTestExplorer.testFramework": "pytest",  
	"python.analysis.inlayHints.functionReturnTypes": false,  
}  

Testing

poetry add pytest pytest-cov

The first one will give a coverage visible directly in vs code, the other one a report inside the terminal

pytest . --cov-report xml:cov.xml --cov .
pytest . --cov-report term --cov .

Profiling

poetry add py-spy

You can then launch the py-spy to sample the running process and get a nice svg visualization:

py-spy record --pid 1400174 --format speedscope -r 1000

git checkout main
git pull
git checkout -b illustration_workflow

Commit

git add compute_sessions.py
git commit -m "illustration du workflow"

Revert

Add a commit that reverts previous changes (that way we can create a new tag to deploy anew a previous version)

git revert HEAD

Rebase on main

git checkout main
git pull
git checkout illustration_workflow
git rebase main

We can also use git fomo (see below aliases) If we have conflicts, handle them manually, then

git push -f

Push

git push -u --force-with-lease origin illustration_workflow

We can configure git to directly send the current branch without having to specify those arguement (simple “git push”):

git config --add --bool push.autoSetupRemote true

or for older git version:

git config --global push.default current

Reseting

git reflog
git reset HEAD@{index}

git reset –hard HEAD to delete permanently modifications made after HEAD

Add a small fix to last commit

git commit -am --amend --no-edit

Warning Only on local commit that have not been pushed ! To change only the commit message:

git commit --amend

Move the last commit from main to another branch

git checkout new_branch
git cherry-pick master
git checkout master
git reset HEAD~ --hard

Aliases

[alias]
     fomo = !git fetch origin main && git rebase origin/main
     ci = commit
     co = checkout
     st = status -sb
     sts = status -s
     br = branch
     tip = log -n 1 --abbrev-commit --decorate
     lol = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
     lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
     unstage = reset HEAD
     cp = cherry-pick
     cam = commit -am
     last = log -1 --stat
     cl = clone
     dc = diff --cached
     lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %Cblue<%an>%Creset' --abbrev-commit --date=relative --all
     dt = diff-tree --no-commit-id --name-only -r
     pushf = push --force-with-lease
     last = log -1 --stat
     oups = commit --amend --no-edit
     unadd = reset HEAD
     nvm = reset --hard HEAD
     hop = "!f() { git checkout -b $1 && git checkout main && git reset HEAD~ --hard && git checkout $1;}; f"

9 projets “data science” sur 10 ne finissent pas en production.
Une des raisons est la difficulté ainsi que le manque de normes pour passer d’un notebook à un produit fonctionnel réellement utile.
Dans ce tuto nous allons voir, à travers un cas simple, comment utiliser fastAPI pour créer une API permettant d’exposer des services IA, qui pourra ensuite être requetée depuis n’importe quelle brique logicielle, en HTTP.
Plus précisement, nous allons ici récupérer des données d’utilisations d’un logiciel présent sur un parc de machines, stockées dans elasticsearch, que nous allons raffiner afin d’en extraire des sessions (clustering selon l’axe du temps uniquement).

Qu’est ce que FastAPI ?

D’après la tres bonne doc officielle, FastAPI est “un framework web moderne, rapide pour construire des APIs python 3.7+ se basant sur les indices de typage standard python”.
Il est rapide (comparable à go et NodeJS), permet de developper rapidement, simple, et fourni plusieurs d’outils assez pratiques.

Pourquoi FastAPI plutot que d’autres web servers ?

• bien plus léger que Django Rest Framework
• plus performant que flask, profite du typage pour la doc et la validation automatique de la donnée d’entrée via pydantic.
• rajoute des utilitaires pratiques au dessus de starlette.

Création de l’environnement virtuel

poetry init 
poetry add pandas fastapi[all] elasticsearch[async]==7.13 requests pyYAML

L’arborescence du projet est alors:

tp_fast_api/   
├── .venv/
├── poetry.lock
└── pyproject.toml

Squelette de base

from fastapi import FastAPI

app = FastAPI(debug=True)

@app.post("/get_ecrans/") # on fait un post pour simplifier l'envoi de données: dans le body directement
def get_ecrans(): 
    return {"ecrans": ["ecran1", "ecran2"]}

Lancer le serveur web avec guvicorn, apres avoir lancé l’environnement virtuel:

poetry shell
uvicorn tp_fast_api.main:app --reload

Puis aller sur http://127.0.0.1:8000/docs

Ajout des parametres

On va maintenant ajouter des parametres: l’utilisateur sur lequel on veut requeter, une date min et une date max:

# main.py
from datetime import datetime

from fastapi import FastAPI
from pydantic import BaseModel

from tp_fast_api.data_collect import extract_ecrans


class Users(BaseModel):
    utils: list[str]
    date_min: datetime
    date_max: datetime


app = FastAPI(debug=True)


@app.post("/get_ecrans/")
def get_ecrans(users: Users):
    return {"ecrans": ["ecran1", "ecran2"], "users": users.utils}

On a utilisé pour cela pydantic.
Essayer d’envoyer le body suivant:

{
 "utils": ["romain"],
 "date_min": "2022-09-22 11:00Z",
 "date_max": "2022-09-28T12:00+02:00"
}

On obtient un 200:

{
  "ecrans": [
    "ecran1",
    "ecran2"
  ],
  "users": {
    "utils": [
      "romain"
    ],
    "date_min": "2022-09-22T11:00:00+00:00",
    "date_max": "2022-09-28T12:00:00+02:00"
  }
}

On se rend compte que les dates ont été automatiquement parsées dans le bon type (bien que deux formats différents aient été envoyés)
Pour la liste des types de date pris en charge par pydantic: https://pydantic-docs.helpmanual.io/usage/types/#datetime-types

Maintenant essayer de lancer avec une date dans un format inconnu, et “utils” mal écrit:

{
 "util": ["romain"],
 "date_min": "2022-09-22 11:00Z",
 "date_max": "2022-09-28 / 12:00+02:00"
}

On obtient un 422:

{
  "detail": [
    {
      "loc": [
        "body",
        "utils"
      ],
      "msg": "field required",
      "type": "value_error.missing"
    },
    {
      "loc": [
        "body",
        "date_max"
      ],
      "msg": "invalid datetime format",
      "type": "value_error.datetime"
    }
  ]
}

Avec uniquement ces quelques lignes en plus, on a:

• une lecture du body
• une convertion et validation de type
• une gestion des erreurs parlante en cas de probleme
• un support de l’IDE pour l’autocompletion du body d’entrée qu’on souhaite manipuler
• une documentation directe dans OpenAPI pour l’utilisateur

L’arborescence du projet est alors:

tp_fast_api/   
├── .venv/
├── poetry.lock
├── pyproject.toml
└── tp_fast_api/
    └── main.py

Requetage sur elastic

On crée un dossier config/ à la racine, qui va contenir les credentials (en YAML). On y mettra tous les tokens et clés qui ne doivent pas être commit. On y met notamment ici les tokens d’accès à elastic.

# credentials.yml
ES_PROD_ID: "<id>"
ES_PROD_API_KEY: "<api_key>"

On rajoute en suite un fichier settings.py permettant d’exposer les variables globales du projet, qui va se charger de créer la connexion à Elastic:

# settings.py
import pathlib

import yaml
from elasticsearch import Elasticsearch

CREDENTIAL_PATH = pathlib.Path(__file__).parent.parent / "config" / "credentials.yml"

with open(CREDENTIAL_PATH, "r") as f:
    credentials = yaml.safe_load(f)

URL_ELASTIC_PROD = "<url_elastic>:9200"

ES_PROD = Elasticsearch(
    hosts=[URL_ELASTIC_PROD],
    request_timeout=30,
    api_key=(credentials["ES_PROD_ID"], credentials["ES_PROD_API_KEY"]),
)

On créé maintenant une fonction qui va aller directement chercher les données dans elastic, dans un module data_collect.py, à part:

# data_collect.py
from datetime import datetime

from elasticsearch import helpers

import tp_fast_api.settings as settings


def extract_ecrans(utils: list[str], date_min: datetime, date_max: datetime) -> list[list[str]]:
    query = {
        "query": {
            "bool": {
                "must": [{"terms": {"util": utils}}],
                "filter": [
                    {
                        "range": {
                            "@timestamp": {
                                "gte": date_min.isoformat(),
                                "lte": date_max.isoformat(),
                                "format": "strict_date_optional_time",
                            }
                        }
                    }
                ],
            }
        }
    }

    data = []
    for doc in helpers.scan(settings.ES_PROD, index="<my_index>", query=query):
        doc = doc["_source"]

        elt = [
            doc.get("@timestamp"],
            doc.get("util"),
            doc.get("ecran"),
            doc.get("instance")
        ]
        data.append(elt)

    return data

Puis on met à jour le main pour retourner ces écrans:

# main.py
from datetime import datetime

from fastapi import FastAPI
from pydantic import BaseModel

from tp_fast_api.data_collect import extract_ecrans


class Users(BaseModel):
    utils: list[str]
    date_min: datetime
    date_max: datetime


app = FastAPI(debug=True)


@app.post("/get_ecrans/")
def get_ecrans(users: Users):
    ecrans = extract_ecrans(users.utils, users.date_min, users.date_max)
    return {"users": users, "ecrans": ecrans}

On peut alors tester l’envoi de requete, et constater qu’on reçoit bien une liste d’écrans:

{
  "ecrans": [
    [
      1663849892657,
      "romain",
      "connexion",
      "instance589",
    ],
    [...]
  ]
}

NB: le typage des dates s’est effectué automatiquement grâce à pydantic, ça nous a évité la gestion des convertions qui peut s’avérer pénible.

L’arborescence est alors:

tp_fast_api
├── config
│   └── credentials.yml
├── poetry.lock        
├── pyproject.toml     
└── tp_fast_api
    ├── data_collect.py
    ├── main.py
    └── settings.py

Tests

On va maintenant tester notre fonction. Pour cela, on va avoir besoin d’intercepter l’appel à elastic, et de mocker son resultat: l’environnement de test n’a pas forcément accès à elastic, et on ne veut rajouter de la charge potentielle sur le cluster à chaque requete.

On ajoute pytest:

poetry add pytest

Puis on ajoute le test unitaire:

# test_data_collect.py
from datetime import datetime
from unittest.mock import patch

from tp_fast_api.data_collect import extract_ecrans


@patch("tp_fast_api.data_collect.helpers.scan")
def test_extract_ecrans(mock_scan):
    mock_scan.return_value = [
        {
            "_index": "mon_index",
            "_type": "_doc",
            "_id": "1660119206971bdcad61d5b",
            "_score": 2.0,
            "_source": {
                "ecran": "connexion",
                "instance": "instance589",
                "@timestamp": 1660119206971,
                "util": "romain"
            },
        }
    ]

    # les parametres ici ne sont pas tres important puisque on intercepte la requete
    results = extract_ecrans(["romain"], datetime.now(), datetime.now())

    assert len(results) == 1
    assert results[0][1] == "romain"

Arborescence:

tp_fast_api
├── config
│   └── credentials.yml
├── tests
│   ├── __init__.py
│   └── test_data_collect.py
├── tp_fast_api
│   ├── __init__.py
│   ├── data_collect.py
│   ├── main.py
│   └── settings.py
├── poetry.lock
└── pyproject.toml

On lance les tests, avec pytest:

pytest .

Script de requetage

On va ecrire un code permettant de requeter à part notre service, afin notamment de faire un petit benchmark basique par la suite. On lance 100 requetes en asynchrone, avec les mêmes parametres.

import asyncio
import datetime
import time

import httpx


async def query_api():
    body = {
        "date_max": datetime.datetime.now().isoformat(),
        "date_min": (datetime.datetime.now() - datetime.timedelta(7)).isoformat(),
        "utils": ["util"],
    }
    async with httpx.AsyncClient() as client:
        await client.post("http://127.0.0.1:8000/get_ecrans/", json=body, timeout=None)


if __name__ == "__main__":
    start = time.time()

    loop = asyncio.get_event_loop()
    queries = asyncio.gather(*[query_api() for _ in range(100)])
    loop.run_until_complete(queries)
    loop.close()

    print(time.time() - start)

Temps d’execution: 16.18s
Note: puisque la requete elastic est toujours la même, elastic garde en cache les données.

Passage en asynchrone

Pour bien comprendre le mécanisme d’asynchrone, voir l’excellente doc fastAPI
On va maintenant adapter notre code pour profiter de l’asynchrone dans python, qui est géré par fastAPI (et starlette, derrière). On commence par créér un nouveau main_async.py:

# main_async.py
from datetime import datetime

from fastapi import FastAPI
from pydantic import BaseModel

from tp_fast_api.data_collect import extract_ecrans_async


class Users(BaseModel):
    utils: list[str]
    date_min: datetime
    date_max: datetime


app = FastAPI(debug=True)


@app.post("/get_ecrans/")
async def get_ecrans(users: Users):
    ecrans = await extract_ecrans_async(users.utils, users.date_min, users.date_max)
    return {"ecrans": ecrans}

On ajoute au settings.py une connexion asynchrone à elastic:

# settings.py
from elasticsearch import Elasticsearch, AsyncElasticsearch

# ...

ES_ASYNC = AsyncElasticsearch(
    hosts=[URL_ELASTIC_PROD],
    request_timeout=30,
    api_key=(credentials["ES_PROD_ID"], credentials["ES_PROD_API_KEY"]),
)

On ajoute à data_collect.py une fonction de collecte des ecrans asynchrone:

# data_collect.py

# ...

async def extract_ecrans_async(
    utils: list[str], date_min: datetime, date_max: datetime
):
    query = {
        "query": {
            "bool": {
                "must": [{"terms": {"util": utils}}],
                "filter": [
                    {
                        "range": {
                            "@timestamp": {
                                "gte": date_min.isoformat(),
                                "lte": date_max.isoformat(),
                                "format": "strict_date_optional_time",
                            }
                        }
                    }
                ],
            }
        }
    }

    data = []
    async for doc in helpers.async_scan(
        settings.ES_ASYNC, index="mon_index", query=query
    ):
        doc = doc["_source"]

        elt = [
            doc.get("@timestamp"],
            doc.get("util"),
            doc.get("ecran"),
            doc.get("instance")
        ]
        data.append(elt)

    return data

Si on lance notre petit scrip de benchmark, on obtient: 11.13s
Soit une augmentation de 1.5x la vitesse de traitement. En principe sur le papier on devrait plutôt être sur 2-3x dans une utilisation normale (il semblerait), avec des performances comparables à ce que peut donner un node express par exemple, et nettement plus que django ou flask. Pour plus d’infos, voir ici

Tests en asynchrone

Utiliser pytest de maniere classique ne nous permet pas de tester les fonctions asynchrones.
Pour ce faire, on commence par installer le package suivant:

poetry add pytest-asyncio

# test_data_collect.py
import pytest

@pytest.mark.asyncio # permet de tester une fonction asynchrone
@patch("tp_fast_api.data_collect.helpers.async_scan")
async def test_extract_ecrans_async(mock_scan): # on a un await dans le corps de la fonction, on doit donc la mettre en async
    mock_scan.return_value = AsyncIteratorMock(
        [
            {
                "_index": "mon_index",
                "_type": "_doc",
                "_id": "1660119206971bdcad61d5b",
                "_score": 2.0,
                "_source": {
                    "ecran": "connexion",
                    "instance": "instance589",
                    "@timestamp": 1660119206971,
                    "util": "romain"
                },
            }
        ]
    )

    results = await extract_ecrans_async(["romain"], datetime.now(), datetime.now())

    assert len(results) == 1
    assert results[0][1] == "romain"

On remarque qu’on utilise un objet AsyncIteratorMock.
En effet, extract_ecrans_async est une fonction de la forme “async for …”, qui necessite d’iterer sur un object possédant la méthode “__aiter__()”, ce qui n’est pas le cas de MagicMock (qu’on obtient grâce au @patch).
On crée donc une classe qui encapsule ce comportement, à laquelle on fournit les données sur lesquelles nous souhaitons itérer (trouvé ici):

class AsyncIteratorMock:
    def __init__(self, data):
        self.iter = iter(data)

    def __aiter__(self):
        return self

    async def __anext__(self):
        try:
            return next(self.iter)
        except StopIteration:
            raise StopAsyncIteration

Traitement IA

Nous allons maintenant rajouter un traitement sur ces données, pour les clusteriser et obtenir des sessions d’interactions, delimités par un debut et une fin, plutot que d’avoir la donnée brut plus difficile à interpréter. Nous utiliserons l’algorithme hdbscan.

poetry add joblib==1.1.0 hdbscan

NB: Au moment d’écriture de ce notebook, il y a y un conflit entre joblib et hdbscan sous windows, il faut donc specifier une version anterieure

Cette fois-ci commençons par écrire le test d’abord :

# test_compute_sessions.py
from tp_fast_api.compute_sessions import compute_sessions

 
def test_compute_sessions():
    data = [
       ["1", "romain", "instance"], 
       ["2", "romain", "instance"], 
       ["6", "romain", "instance"], 
       ["10", "romain", "instance"], 
       ["12", "romain", "instance"], 
       ["13", "romain", "instance"], 
       ["18", "anes", "instance"],
       ["19", "anes", "instance"] 
    ]

    data_cluster = compute_sessions(data)
    assert len(data_cluster) == 2

On va maintenant ecrire la fonction qui, pour une liste de données telle que retournée par extract_ecrans_async(), va nous clusteriser les données, et nous retourner une liste de dictionnaires, ayant chacun un debut, une fin, une instance et une personne.

# compute_sessions.py
import pandas as pd
import hdbscan

import tp_fast_api.settings as settings


def compute_sessions(data: list[list]) -> pd.DataFrame:
    df = pd.DataFrame(
        data=data,
        columns=["@timestamp", "personne", "instance"],
    )

    clusterer = hdbscan.HDBSCAN(min_cluster_size=settings.CLUSTER_MIN_POINTS)

    windows = []
    for _, group in df.groupby("personne"):
        # hdbscan pour un seul point semble nous mettre une erreur
        if len(group) > 1:
            group["cluster"] = clusterer.fit_predict(
                group["@timestamp"].array.reshape(-1, 1)
            )
        else:
            group["cluster"] = -1

        group = group[group["cluster"] >= 0]  # on supprime le bruit
        for _, cluster_group in group.groupby("cluster"):
            new_data = {
                "debut": cluster_group["@timestamp"].min(),
                "fin": cluster_group["@timestamp"].max(),
                "instance": cluster_group.at[cluster_group.index[0], "instance"],
                "personne": cluster_group.at[cluster_group.index[0], "personne"],
            }
            windows.append(new_data)

    return windows

Plus qu’à mettre à jour main_async:

# main_async.py
from datetime import datetime

from fastapi import FastAPI
from pydantic import BaseModel

from tp_fast_api.data_collect import extract_ecrans_async
from tp_fast_api.compute_sessions import compute_sessions

class Users(BaseModel):
    utils: list[str]
    date_min: datetime
    date_max: datetime


app = FastAPI(debug=True)


@app.post("/get_ecrans/")
async def get_ecrans(users: Users):
    ecrans = await extract_ecrans_async(users.utils, users.date_min, users.date_max)
    sessions = compute_sessions(ecrans)
    return {"session": sessions}

Et on obtient bien un service qui nous permet, pour des parametres spécifiés, d’obtenir une donnée raffinée, mieux exploitable pour le metier. On pourrait ensuite faire une dataviz avec, calculer d’autres métriques à partir de cette information, etc.
Pour la mise en production, plusieurs possibilités, voir la doc de fastAPI

Gestion du format de sortie

Pour finir, on va specifier grâce à pydantic le format de sortie, qui nous permettra d’eviter les erreurs de convertion de type dans la construction de la reponse, ainsi que mieux documenter notre api:

# main_async
from datetime import datetime

from fastapi import FastAPI
from pydantic import BaseModel

from tp_fast_api.data_collect import extract_ecrans, extract_ecrans_async
from tp_fast_api.compute_sessions import compute_sessions

app = FastAPI(debug=True)


class Users(BaseModel):
    utils: list[str]
    date_min: datetime
    date_max: datetime


class Session(BaseModel):
    debut: datetime
    fin: datetime
    instance: str
    personne: str


class OutResponse(BaseModel):
    sessions: list[Session]


@app.post("/get_ecrans/", response_model=OutResponse) 
async def get_ecrans(users: Users):
    ecrans = await extract_ecrans_async(users.utils, users.date_min, users.date_max)
    sessions = await compute_sessions(ecrans)
    return {"sessions": sessions}

Typage des données d’elastic

Apres reflexion, on se rend compte que le typage des données qui sortent d’elastic est important lui aussi: sans celui-ci, certains champs texte du type “01” pourront être malencrontreusement transformé en float ou int. Pour régler ce probleme, on pourrait utiliser elasticsearch-dsl, cependant celui-ci ne fonctionne pas en asynchrone. On peut donc utiliser directement pydantic, par exemple:

# data_collect.py
from datetime import datetime

from pydantic import BaseModel
from elasticsearch import helpers

import tp_fast_api.settings as settings

class Ecran(BaseModel):
    ecran: str
    instance: str 
    timestamp: datetime
    util: str

    
async def extract_ecrans_async(utils: list[str], date_min: datetime, date_max: datetime):
    query = {
        "query": {
            "bool": {
                "must": [{"terms": {"util": utils}}],
                "filter": [
                    {
                        "range": {
                            "@timestamp": {
                                "gte": date_min.isoformat(),
                                "lte": date_max.isoformat(),
                                "format": "strict_date_optional_time",
                            }
                        }
                    }
                ],
            }
        }
    }

    data = []
    async for doc in helpers.async_scan(settings.ES_ASYNC, index="mon_index", query=query):
        doc = doc["_source"]
        doc_parsed = Ecran(**doc, timestamp=doc["@timestamp"])
        elt = [
            doc_parsed.ecran,
            doc_parsed.timestamp,
            doc_parsed.util,
            doc_parsed.instance,
        ]
        data.append(elt)

    return data

NB: pour être plus propre, mieux vaut mettre les modeles de données pydantic à part dans un module modeles.py

Les algorithmes de clustering sont très utiles pour faire de l’analyse de données exploratoire, c’est à dire pour étudier un dataset et le faire parler sans connaissance à priori dessus. Les cas d’utilisations sont divers: labeliser automatiquement un jeu de données (étape coûteuse si faite par un expert), découvrir automatiquement des sujets de discussion, mieux comprendre le domaine sous-jascent, etc.

HDBSCAN (Hierarchichal DBSCAN) est un algorithme de clustering proposé par Campello et Al. en 2013 [2]. Il part du principe que:

• les algorithmes de clustering basés sur la densité, comme DBSCAN, ne clusterisent que selon un seuil de densité global, ce qui va empecher de trouver des clusters de densité trop variables.
• les algorithmes de type clustering hierarchique sont aussi intéressants, mais peuvent avoir une hiérarchie trop complexe, difficilement interprétable.
• Un autre problème rencontré est aussi la multiplication de paramètres, influençant grandement le résultat (par exemple le nombre de classes est à spécifier pour k-means)

Notons qu’un algorithme de clustering est différent d’un algorithme de partitionnement, comme k-means. Le but de ce dernier est d’associer à tout élément un des k regroupements, en minimisant la distance intra-regroupement. Dans notre définition du clustering, on s’autorise à avoir des points qui n’appartiennent à aucun regroupement: ils sont considérés comme étant du bruit.

En deux mots, HDBSCAN est un mélange entre un algorithme de clustering hierarchique et DBSCAN. Il va permettre de considérer des clusters de densités différentes, ne requiert que peu de paramétrage, donne de très bons résultats. De plus, une implémentation performante et intégrée à sk-learn a été proposée suite à des travaux plus récents [1].

NB: Les illustrations qui vont suivre sont prises depuis [4]. Ce notebook n’est pas une simple traduction mais une manière un peu différente de présenter l’algorithme.

import numpy as np
import matplotlib.pyplot as plt
import seaborn as sns
import sklearn.datasets as data
%matplotlib inline
plt.rcParams['figure.figsize'] = [14, 8]
from IPython.core.display import HTML
HTML("""
<style>
.output_png {
    display: table-cell;
    text-align: center;
    vertical-align: middle;
}
</style>
""")

sns.set_context('poster')
sns.set_style('white')
sns.set_color_codes()
plot_kwds = {'alpha' : 0.5, 's' : 80, 'linewidths':0}

Définitions

Core distance d’un point dcore(A): distance au mPts plus proche voisin. Plus elle est petite, plus la densité de points est forte au voisinage d’un point

Mutual Reachibility Distance dMRD(A, B): entre deux objets, la MRD est la valeur max entre la distance entre les deux objets, la core distance du premier object, et la core distance du deuxième objet.

Par exemple, la MRE entre le point vert et bleu va correspondre à la core distance du point vert, à la différence de la MRD entre le point vert et rouge, qui correpond à la distance entre ces deux points.

Mutual Reachability Graph: le graph complet où chaque pair de points est relié par un arc pondéré par sa MRD.

Equivalence entre le mutual reachability graph et DBSCAN

(On introduit la notion d’ε-voisinage uniquement pour DBSCAN)
ε-voisinage: pour un point A, ensemble des autres points à une distance < ε de A.

Le principe de DBSCAN, revisité dans le papier HDBSCAN, est de faire des groupements maximaux de points (=cluster) dont on sait que:

• chaque point à au moins mpts dans son ε-voisinage.
• toute paire de points (A, B) dans un groupement est connecté, c’est à dire que soit A est dans le ε-voisinage de B et reciproquement, soit il y a une chaîne de points entre A et B pour lesquels cette propriété tiens.

NB: Ce n’est pas exactement DBSCAN, on retire ici les points frontières.

Imaginons maintenant qu’on prenne le mutual reachability graph, qu’on enlève les arcs qui sont de poids > ε, et qu’on enlève les points isolés (outliers). On a alors, pour tous points A, B connectés dans ce nouveau graph:
\(d_{MRD}(A, B) \leq ε\) \(d_{core}(A) \leq ε\) \(d_{core}(B) \leq ε\) \(d(A, B) \leq ε\)

On a alors des groupements de points dont on sait qu’ils ont chacun au moins mpts dans leur ε-voisinage. De plus, chaque point des couples de points directement reliés est dans le ε-voisinage de l’autre. On est donc bien en présence d’un clustering équivalent à ce que produirait DBSCAN.

Proposition: Si on lance un algorithme de clustering hierarchique (Single Linkage) sur le mutual reachability graph, on obtient un dendogramme. Si on le coupe au niveau ε, on obtient un clustering de DBSCAN.

Cette méthode n’est cependant pas optimisée, les auteurs ont donc proposé d’implémenter cette idée d’une manière un peu différente.

Utilisation du Minimum Spanning Tree (MST)

Tout d’abord, générons quelques points pour la suite.

moons, _ = data.make_moons(n_samples=150, noise=0.08)
blobs, _ = data.make_blobs(n_samples=50, centers=[(-0.75,2.25), (1.0, 2.0)], cluster_std=0.40)
test_data = np.vstack([moons, blobs])
plt.scatter(test_data.T[0], test_data.T[1], color='b', **plot_kwds)

<matplotlib.collections.PathCollection at 0x21697a29400>

On lance hdbscan pour mieux illustrer la suite.

import hdbscan

clusterer = hdbscan.HDBSCAN(min_cluster_size=5, gen_min_span_tree=True)
clusterer.fit(test_data)

HDBSCAN(gen_min_span_tree=True)

La première étape consiste à générer un MST, avec la particularité que chaque noeud possède un arc vers lui-même, avec comme poids sa core distance.

clusterer.minimum_spanning_tree_.plot(edge_cmap='viridis', 
                                      edge_alpha=0.6, 
                                      node_size=60, 
                                      edge_linewidth=2)

<matplotlib.axes._subplots.AxesSubplot at 0x2169729bf10>

En fait, le dendogramme générée par un clustering hirerarchique (en single linkage) depuis le mutual reacheability graph peut être créé en générant cet MST, et en supprimant successivement les liens selon leur poids décroissant. On peut générer cet MST avec l’algorithme de Prim, par exemple.

On obtient donc le dendogramme suivant:

clusterer.single_linkage_tree_.plot(cmap='viridis', colorbar=True)

<matplotlib.axes._subplots.AxesSubplot at 0x21695d02bb0>

Le pseudocode principal de l’algorithme est le suivant:

1. Calculer la core distance de paramètre m_pts pour tout point X
2. Calculer le MST du Mutual Reachability Graph
3. Ajouter sur chaque noeud un arc pointant vers lui-même, ayant un poids de sa core_distance
4. Extraire le dendogramme depuis le MST:
    4.1 Pour la racine, mettre tous les objets dans le même cluster
    4.2 Pour chaque arc du MST, par ordre de poids décroissant (enlever tous ensemble ceux qui sont égaux):
        4.2.1 Définir la valeur courante du dendogramme sur la valeur de l'arc qu'on enlève
        4.2.2 Assigner de nouveaux labels au nouveaux clusters créés. Si l'un d'entre eux n'a plus d'arc, l'enlever (bruit).
        

La question maintenant va être de définir comment extraire des clusters depuis ce schéma. La méthode DBSCAN consisterait à tirer un trait horizontal, et de prendre tous les clusters de ce niveau. Mais nous voulons autoriser des variations de densités. Comment faire ?

Simplification Hierarchique

On introduit un nouveau paramètre mclSize, qui correpond au nombre minimal d’éléments dans un cluster (les auteurs conseillent de fixer mclSize = mpts).

L’idée ici va être de “lisser” les clusters, en considérant que les clusters créés lors d’une séparation sont du bruit s’ils n’ont pas mclSize points, et donc ils ne constituent pas un vrai “split”.

On redéfinit donc l’étape 4.2 de l’algorithme principal:

4.2 Pour chaque arc du MST, par ordre de poids décroissant (enlever tous ensemble ceux qui sont égaux):
      Si taille cluster formé < m_clSize -> Noise
      Si un seul cluster est créé -> garder le nom du cluster parent
      Si > 1 cluster, et que chacun à une taille > m_clSize -> assigner un nouveau label à chacun.

L’implémentation que nous utilisons de HDBSCAN nous permet de représenter les clusters au fil de l’algorithme.

clusterer.condensed_tree_.plot()

<matplotlib.axes._subplots.AxesSubplot at 0x21697b15fa0>

On constate que certains points “tombent” des différents clusters lors de la progression de l’algorithme. La $\lambda\ value$ correspond à $\frac{1}{\epsilon}$.

Maintenant que nous avons une hierarchie simplifiée, il nous faut en extraire des clusters.

Extraction des clusters

Notons qu’il faut que pour un point donnée, celui-ci ne soit couvert que par un seul cluster. L’idée ici va être d’utiliser une mesure de stabilité pour choisir quels clusters sont les plus pertinents.

On définit la stabilité d’un cluster par:

\(S(C) = \sum_{x \in C}^{} (\lambda_{max}(x, C) - \lambda_{min}(C))\) où λmin est le niveau de densité pour lequel le cluster s’est créé, λmax(x, C) est le niveau de densité auquel l’objet x disparait de C (soit quand le cluster est split, soit quand il devient du bruit). Un cluster est donc d’autant plus stable qu’il contient de nombreux objets qui “restent” (càd ne sont pas considérés comme étant du bruit lorsqu’on augmente la densité minimale).

On va ensuite procéder de manière bottom-up, en considérant que tous les clusters du bas sont selectionnés, puis en remonte suivant la règle suivante, à chaque fusion de clusters:

• si le cluster parent à une stabilité plus grande, le selectionner, et deselectionner les deux enfants.
• Sinon, garder les enfants et mettre la valeur du cluster selectionné égale à la somme des enfants.

On remonte ainsi jusqu’à la racine, et on obtient notre ensemble de clusters selectionnés.

clusterer.condensed_tree_.plot(select_clusters=True, selection_palette=sns.color_palette())

<matplotlib.axes._subplots.AxesSubplot at 0x216980a5f40>

palette = sns.color_palette()
cluster_colors = [sns.desaturate(palette[col], sat) 
                  if col >= 0 else (0.5, 0.5, 0.5) for col, sat in 
                  zip(clusterer.labels_, clusterer.probabilities_)]
plt.scatter(test_data.T[0], test_data.T[1], c=cluster_colors, **plot_kwds)

<matplotlib.collections.PathCollection at 0x2169936e910>

Quelques comparaisons

Essayons avec le célèbre k-means.

import sklearn.cluster as cluster
import time 
test_data

def plot_clusters(data, algorithm, args, kwds):
    start_time = time.time()
    labels = algorithm(*args, **kwds).fit_predict(data)
    end_time = time.time()
    palette = sns.color_palette('deep', np.unique(labels).max() + 1)
    colors = [palette[x] if x >= 0 else (0.0, 0.0, 0.0) for x in labels]
    plt.scatter(data.T[0], data.T[1], c=colors, **plot_kwds)
    frame = plt.gca()
    frame.axes.get_xaxis().set_visible(False)
    frame.axes.get_yaxis().set_visible(False)
    plt.title('Clusters found by {}'.format(str(algorithm.__name__)), fontsize=24)
    
plot_clusters(test_data, cluster.KMeans, (), {'n_clusters':4})

Tous les points ont été sélectionnés, mais on voit qu’on a un problème pour les formes de croissants en bas. Si on essaie de spécifier 3 classes, on obtient aussi un résultat peu satisfaisant:

plot_clusters(test_data, cluster.KMeans, (), {'n_clusters':3})

Essayons maintenant avec DBSCAN:

plot_clusters(test_data, cluster.DBSCAN, (), {'eps':0.1})

On a le problème du paramétrage qui n’est pas aisé. En tatonant, le meilleur clustering que je puisse trouver est le suivant:

plot_clusters(test_data, cluster.DBSCAN, (), {'eps':0.35})

Pour plus d’expériences et de comparaisons, voir [1] et [2]. Pour des comparatifs de performances voir [5].

Références:

[1] L. McInnes et J. Healy, « Accelerated Hierarchical Density Clustering », 2017 IEEE International Conference on Data Mining Workshops (ICDMW), p. 33‑42, nov. 2017.

[2] R. J. G. B. Campello, D. Moulavi, et J. Sander, « Density-Based Clustering Based on Hierarchical Density Estimates », in Advances in Knowledge Discovery and Data Mining, vol. 7819, J. Pei, V. S. Tseng, L. Cao, H. Motoda, et G. Xu, Éd. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013, p. 160‑172.

[3] https://nbviewer.jupyter.org/github/scikit-learn-contrib/hdbscan/blob/master/notebooks/Comparing%20Clustering%20Algorithms.ipynb (consulté le nov. 24, 2020).

[4] https://nbviewer.jupyter.org/github/scikit-learn-contrib/hdbscan/blob/master/notebooks/How%20HDBSCAN%20Works.ipynb (consulté le nov. 24, 2020).

[5] https://nbviewer.jupyter.org/github/scikit-learn-contrib/hdbscan/blob/master/notebooks/Benchmarking%20scalability%20of%20clustering%20implementations-v0.7.ipynb (consulté le nov. 24, 2020).

“Beaucoup de malades sont vaccinés”

Un premier argument de cet article, repris dans plusieurs médias, est que “la majorité des personnes hospitalisées pour des formes graves sont désormais des personnes vaccinées.” Ce n’est pas une statistique intéressante. Si tout le monde est vacciné, la proportion de personnes hospitalisées qui sont vaccinées est de 100%, et ce même s’il n’y a qu’une seule personne concernée. Peut-on pour autant conclure que le vaccin n’est pas efficace ? Non ! C’est une erreur classique appelée “base rate fallacy” dont on a déjà parlé ici.

En langage commun, on peut traduire cette proportion par la question “quelle est la probabilité d’être vacciné sachant qu’on est hospitalisé ?”, qui peut être écrite p(vacciné|hospitalisé). En vérité ce qui nous intéresse ce serait plutôt p(hospitalisé|vacciné), càd le risque d’être hospitalisé sachant qu’on est vacciné, et de le comparer à la probabilité d’être hospitalisé sachant qu’on est pas vacciné.

Nous allons appliquer la loi de bayes. Le risque a priori d’être hospitalisé à cause du covid peut être estimé à 6,8% si on suit les premières estimations en début d’épidémie, et de 8,5% si on divise le nombre total d’hospitalisations en France par le nombre total de cas détectés. Notons que la véritable valeur est probablement plus basse, puisqu’il y a des cas de covid asymptomatiques qui n’ont pas été détectés. Cependant, cette valeur p(hospitalisé) sera la même dans le calcul de p(hospitalisé|vacciné) et de p(hospitalisé|non vacciné), puisqu’on va faire un ratio pour comparer, elle se simplifie et n’impactera pas le résultat.

De plus, en toute rigueur, on devrait préciser dans les notations que les estimations se font sous l’hypothèse qu’on attrape la covid (on l’enlève par souci de simplification). Dans ce cas là, on doit estimer la probabilité d’être vacciné sous l’hypothèse d’avoir contracté la covid. On doit donc réappliquer une loi de bayes à l’intérieur de notre calcul. On a :

Admettons que la covid soit suffisamment virulente pour qu’on considère que la probabilité qu’on finisse par l’attraper soit de 100%. La probabilité a priori d’être vacciné est de 60%. Enfin, d’après l’étude sur le vaccin Pfizer, la probabilité de contracter la covid sachant que l’on est vacciné est de 95%. Pour d’autres vaccins ce serait moins. Admettons que ce soit 70%, pour essayer de prendre en compte que les vaccins sont moins efficaces avec les nouveaux variants. On a alors une probabilité d’être vacciné, sachant qu’on a la covid, de 42%, je vous épargne les détails de calcul (dans la suite des calculs cela correspond à p(vacciné), par soucis de simplification).

Calculons donc la probabilité d’ếtre hospitalisé sachant qu’on est vacciné, avec les données françaises.

Si on applique le même raisonnement pour calculer la probabilité d’être hospitalisé sachant qu’on n’est pas vacciné, on obtient:

Attention, encore une fois, cette estimation est faite en considérant une probabilité de 8,5% d’être hospitalisé si on contracte la covid, cette probabilité est discutable, mais elle ne change pas le ratio suivant:

En france, actuellement, on a 4 fois plus (12.4 / 3.0) de risques d’être hospitalisé si on n’est pas vacciné, dans l’hypothèse où l’on contracte la covid.

Remarque importante: il y a en plus au moins un biais supplémentaire dans ces données: on a donné le vaccin prioritairement aux personnes les plus vulnérables. Ainsi, on compare une population vaccinée qui est plus fragile (âge, comorbidités) à une population non-vaccinée plus résistante, ce qui peut avoir tendance à faire baisser les “résultats” du vaccin.

C’est pour cette raison qu’on fait des études expérimentales, où on prend deux groupes de personnes suffisamment grands. L’aléatoire et la taille des groupes permet de faire en sorte qu’ils soient comparables pour d’autres variables qui viendraient influencer les résultats (par exemple l’âge, qui augmente la mortalité).

Ces études existent, puisqu’elles sont nécessaires pour pouvoir attester, de manière objective, de l’efficacité et de la sûreté d’un vaccin. Par exemple, dans la publication relative au vaccin Pfizer, on a fait deux groupes aléatoires de plus de 21 000 personnes, un groupe auquel on a donné le vaccin, un autre où on a donné un placebo. On a ensuite comparé les nombres de personnes ayant contracté la covid dans chaque groupe (7 pour le premier, 162 pour l’autre), ce qui nous permet d’estimer (avec un test statistique) que le vaccin protège à 95% du covid, à l’heure de l’étude.

Pourquoi alors semble-t-on dire que le vaccin n’empêche pas d’attraper la covid ? Plusieurs hypothèses sont possibles, comme le fait que le virus ait muté, qu’il y a ce biais de donner un vaccin à une population plus vulnérable, qui fait baisser son score, entre autres. Je ne me risquerais pas à en dire plus, ce n’est pas mon domaine de compétence. En tous cas, retenons que les données actuelles nous donnent l’estimation suivante: on a 4 fois plus de risques d’être hospitalisé à cause du covid en France actuellement si l’on n’est pas vacciné que si on l’est.

Confondre causalité et corrélation

L’article cite deux chercheurs, qui sont aussi co-signataires: Emanuelle Darles et Vincent Pavant. Dans cette vidéo, Mr Pavant utilise un modèle (qui peut paraître complexe au premier abord, et même inadéquat au second) et l’adapte à une courbe d’évolution de la mortalité, dont il ne prend que la moitié pour ensuite créer de nouvelles données qui l’arrangent, afin de tenter de montrer la pertinence de son modèle. Il conclut ainsi que “le lien entre vaccination et mortalité est certain”. Ce raisonnement est faux. On ne peut pas prendre une courbe, placer la date de début de vaccination et dire “le nombre de mort augmente après le début de la vaccination, donc la vaccination tue des gens” (c’est finalement ce qu’il fait et ce que font les autres intervenants) En anglais ce phénomène s’appelle “spurious correlation”, et il y a un site qui les répertorie.

Sans rentrer dans les formalisations mathématiques rigoureuses, on dit que deux variables sont corrélées quand elles varient de la même manière.

Par exemple, chez les êtres humains la taille est assez bien corrélée à la masse: plus l’on est grand, plus on a tendance à être lourd, et inversement. La causalité elle, consiste à dire qu’une variable cause/influence une autre. Par exemple, la quantité d’alcool que j’ingère cause une augmentation de mon taux d’alcool dans le sang. Les recherches de causalités peuvent être des problématiques très difficiles, sur lesquelles travaillent de nombreux chercheurs.

Par exemple ici, on peut voir que la consommation de mozzarella est corrélée au nombre de doctorats en génie civil décernés aux Etats-unis.

Est ce qu’il y a un lien entre ces deux variables ? Probablement pas. Mais à cause de l’aléatoire de notre monde, on peut trouver des corrélations, par “chance”, sans qu’il y ait de causalité. De même, il peut y avoir corrélation entre deux variables sans que l’une soit la cause de l’autre, mais plutôt qu’il y ait un autre phénomène caché qui influence ces deux variables.

Par exemple, (repris du livre Prenez le temps d’y penser, B. Benamran), les gens qui se couchent avec leurs chaussures ont mal à la tête le lendemain. Est-ce que pour autant le fait de dormir avec ses chaussures cause le mal de tête ? Non ! Il y a une variable cachée qui est “les personnes qui boivent trop s’endorment avec leurs chaussures”. Ainsi, cette variable cachée a causé l’endormissement avec les chaussures, et le mal de tête.

Revenons à notre épidémie. On constate qu’à partir du moment où on vaccine, la mortalité augmente. Est ce qu’on peut conclure que le vaccin cause la mort ? Non. Très probablement, ce qui se passe c’est que l’épidémie repart vite, donc on vaccine pour éviter des morts du covid. Le vaccin permet d’éviter des morts, mais il y en a tout de même à cause de l’épidémie. Ici la variable cachée, qui cause la vaccination et l’augmentation du nombre de morts, c’est tout simplement l’épidémie. Notons qu’en toute rigueur, il faudrait valider cette hypothèse expérimentalement. Ce qui tombe “bien” (si tant est que nous puissions parler ainsi étant donné la situation), c’est que nous avons déjà ces données, puisque certains pays ont beaucoup vacciné, quand d’autres non (source):

Ici on a bien deux groupes aléatoires, de grandes tailles, ce qui nous permet d’avoir une bonne idée de l’influence du vaccin sur la mortalité. Dans celui vacciné on a très peu de décès, dans celui non-vacciné, on en a beaucoup plus. Ceci n’est pas une preuve en soi, si on veut être rigoureux, car il faudrait que l’experience se passe dans le même pays, avec le même climat, etc., pour être sûr qu’il n’y ait pas de facteur confondant (biais), mais c’est tout de même très encourageant.

Autre remarques diverses

• Dans l’article de Mr Mucchielli, il est assuré que la balance bénéfice-risque pour les jeunes est très mauvaise. Si on se réfère à la source qui est citée, on se rend compte qu’on compare les risques de la covid chez les jeunes par rapport au risque du vaccin dans la population générale. On compare donc des choses qui sont différentes, les conclusions sont donc fausses. Dans les rapports qu’ils citent, on a par exemple qu’un seul cas grave pour les 0-15 ans, et on voit que la médiane des décès pour les vaccinés est de 76,2 ans…
• On fait l’hypothèse que les morts après le vaccin sont liés au vaccin dans cet article. Dans les rapports du CRPV sur le moderna, il est pourtant bien écrit “Aussi ce rapport mensuel présente uniquement les effets indésirables pour lesquels le rôle du vaccin est confirmé ou suspecté”. Encore une fois, trouver la causalité est difficile. Dans les conclusions des rapports, il est clairement dit qu’il n’y a pas de certitude sur le fait que ce soit le vaccin qui cause les morts. Il faut être prudent sur ces affirmations. Si on donne une banane à manger à 100 000 personnes, il y aura probablement quelques dizaines de personnes qui auront des effets indésirables, et des morts. Doit-on en conclure que les bananes causent la mort ? Non ! Dans le cas présent, je ne suis pas compétent en pharmacologie pour pouvoir juger. Je m’en remet donc aux publications des experts qui concluent que non. Ce que je peux dire par contre, c’est que l’article au mieux se trompe, au pire manipule les données.
• L’article présente volontairement des pourcentages qui font peur. Par exemple pour pfizer, les données sont écrites en absolu, et on écrit subitement un pourcentage: 27.7%. Cette proportion reste en tête, si on lit un peu vite on se dit que les formes graves sont très courantes, alors qu’il s’agit seulement de la proportion d’effets graves parmi les indésirables. En fait, si on calcul le nombre de décès parmis toutes les injections sur pfizer, par exemple, on trouve 0.0018%.
• Si on compte tous les cas graves pour le vaccin, alors il convient de compter aussi tous les cas graves pour le covid (hospitalisation, covid long etc), sinon on ne compare pas la même chose. Ou alors on compare le nombre de morts, et dans ce cas les calculs sont beaucoup plus raisonnables.
• Aucune citation de toute la littérature scientifique qui ne va pas dans le sens du/des auteur(s). C’est assez perturbant quand on voit que l’article se dit de vouloir “observer froidement les données”, et dénonce une “idéologie de la vaccination intégrale”.
• Cet article n’est pas un article scientifique revu par les pairs. Les erreurs pointées ici (entre autres) n’auraient pas permis une telle publication dans un journal/une conférence serieux/sérieuse.

Conclusion

L’isolation de la causalité est un problème difficile, c’est une des raisons pour lesquelles des gens passent leur vie à faire de la recherche. Il y a plusieurs réflexes qu’il est bon d’avoir lorsqu’on nous présente des chiffres et conclusions toutes faites: qui parle ? Ces personnes s’expriment-elles dans leur domaine de compétence ? Avons-nous à faire à un article scientifique revu par les pairs ? Où a-t-il été publié ? A quoi correspond concrètement la proportion/la statistique qu’on nous présente ? Et surtout, il faut se méfier des corrélations, qui ne sont pas forcément des causalités. En particulier, quand on présente un graphique et qu’on en conclut “parce que ça se voit”, il faut bien réfléchir à ce qu’il y a derrière. Est ce que c’est une étude expérimentale où on prend deux groupes aléatoires de grandes tailles pour vraiment étudier l’impact d’une seule variable, ou sont-ce des données observationnelles (càd observations sans avoir défini un plan d’expérience au préalable, où on ne contrôle pas le processus de génération de données), qui peuvent donc comporter des biais ? Pour une explication visuelle et bien vulgarisée, voir ici.

On a finalement aussi estimé ici qu’une personne moyenne de la population française, si elle attrape la covid actuellement, a quatre fois plus de risques d’être hospitalisée si elle n’est pas vaccinée. Enfin, les données comparatives entre l’angleterre et la tunisie semblent bien confirmer que la vaccination protège des risques de décès dus au covid.

NB: Merci à Anes Bendimerad, Aurélie Gabriel et Nicolas Nativel pour leurs relectures et critiques.

Je ne suis pas épidémiologiste, mais doctorant en science des données. A la lecture de l’excellent article de Thomas Pueyo, j’ai voulu m’inspirer de son travail, avec un code ouvert, dans le cas de la France, en français, à la date du 14 mars 2020. Ce travail n’est PAS un article scientifique revu par les pairs, mais une tentative d’estimation faite en quelques heures. Qui plus est même si le modèle utilisé correspond très bien aux observations, il est possible qu’il soit un peu trop simpliste. A prendre en considération donc.

Loi exponentielle

On peut modéliser le phénomène de propagation du COVID-19 par une fonction exponentielle. L’article de Wikipedia sur la croissance exponentielle est bien fait: on peut prouver assez facilement qu’une croissance exponentielle peut s’écrire sous différentes formes: \(x(t) = x_0e^{kt} = x_0e^{t/\tau} = x_02^{t/T} = x_0(1+\frac{r}{100})^{t/p}\) avec x(t) le nombre de cas au temps t, x0 le nombre de cas à t=0, k le taux de croissance effectif, tau la période “e-folding”, r le taux de croissance intrinsèque pour une periode p, T la période de “doublage” (le delta temps qu’il faut pour que x(t) double).

Modéliser la propagation en France (au 14/03/20)

Je me base sur les données extraites du Wordlometer. Visualisons tout d’abord l’évolution du nombre de cas:

import numpy as np
import pandas as pd
import seaborn as sns
from scipy.optimize import curve_fit
import matplotlib.pyplot as plt
sns.set(rc={'figure.figsize':(11.7,8.27)})

data = pd.read_csv('covid_confirmed.csv')

# we extract only the timeserie for france
france_df = data[data['Province/State'] == 'France'].iloc[:, 4:]
france_df = france_df.T
france_df = france_df.reset_index()
france_df.rename(columns={france_df.columns[0]: "Time", france_df.columns[1]: "Cases Number" }, inplace = True)
france_df['Time'] = (pd.to_datetime(france_df['Time'].str.strip(), format='%m/%d/%y'))
france_df.head()

sns.lineplot(data=france_df, x='Time', y='Cases Number')

<matplotlib.axes._subplots.AxesSubplot at 0x240f0c9a4c8>

Maintenant, nous allons construire notre modèle de croissance exponentielle et choisir les paramètres pour qu’il corresponde le mieux possible aux données.

x_numpy = np.array(france_df['Time'])

# we transform date to int to fit the model
x_numpy = (x_numpy - x_numpy[0]).astype('timedelta64[D]').astype('int')
y_numpy = np.array(france_df['Cases Number'])

def exp_func(x, a, b):
    return a * np.exp(b * x) 

popt, pcov = curve_fit(exp_func, x_numpy, y_numpy, p0=(1, 1e-6))



residuals = y_numpy - exp_func(x_numpy, *popt)
ss_res = np.sum(residuals**2)

ss_tot = np.sum((y_numpy-np.mean(y_numpy))**2)
r_squared = 1 - (ss_res / ss_tot)

print(f"R² = {r_squared}")

plt.figure()
plt.plot(x_numpy, y_numpy, 'ko', label="Données originales")
label = "{:.3f} * exp({:.3f}*x)".format(*popt)
plt.plot(x_numpy, exp_func(x_numpy, *popt), 'b-', label=label)
plt.legend()
plt.show()

R² = 0.9976140854576636

Notre modèle nous donne donc x0 = 0.017 et k=0.241 Il est simple, et bien sûr criticable, mais semble pourtant bien correspondre à la réalité du moment, avec un R² de 0.997 (à 1 il correspondrait parfaitement à la réalité, il modèlise donc très bien les observations actuelles).

Precision: La croissance exponentielle ne sera pas infinie bien sûr. Elle sera soit limitée par les mesures que nous prendrons, soit lorsque l’ensemble de personnes non infectées et non-immunisées sera trop faible. On l’a vu en Chine, les mesures de confinement ont changé le modèle, stoppant la croissance exponentielle. D’ici quelques temps les mesures prises ici changeront la courbe à mesure qu’elles auront empéché la propagation.

D’après les équations du début, on peut facilement montrer que:

T correspond au temps qu’il faut pour que le nombre de cas double, il vaut ici:

k = popt[1]
print(f"T = {np.log(2) / k}")

T = 2.880887901598439

Le nombre de cas détectés double donc tous les 2.9 jours en France, pour l’instant.
Fixons p à 1 pour connaître le taux de croissance intrinsèque journalier r:

r = 100 * (np.exp(k) - 1)
print(f"r = {r}")

r = 27.201457983622014

Ceci signifie que chaque jour, le nombre de cas détectés augmente de 27%.

Regarder ailleurs pour mieux prévoir ici

On peut considérer que jusqu’à aujourd’hui (14/03/20) les mesures prises par le gouvernement ne sont pas encore effectives (à partir du 16/03/20 pour la fermeture des écoles universités). Il en est de même pour les recommandations du télétravail, puisque l’annonce du gouvernement a eu lieu jeudi soir: les employés des entreprises se sont réunis vendredi pour décider de la meilleure manière de s’adapter à la situation. On peut donc considérer raisonnablement que la courbe va continuer sur la même lancée les prochains jours.

Une latence pour l’impact des mesures prises

La période d’incubation est estimée à environ 5 jours, en se basant sur ces publications (section incubation period, je n’ai considéré que les données de publications avec relecture par les pairs). Ceci signifie que les gens ne commencent à avoir les symptômes qu’après 5 jours. Ainsi, toute mesure de confinement prise ne commencera à avoir un impact qu’après ce délai, au mieux: même en enfermant les gens chez eux, s’ils ont attrapé le virus celui-ci se développe et ils seront de toutes façons malades dans 5 jours environ. De plus les premiers symptômes n’envoient pas instantanément les malades dans les hôpitaux, c’est un phénomène plutôt continu, donc cette latence est en fait supérieure à 5 jours. Pour la Chine il fallut environ 11-12 jours après le shutdown de Wuhan (voir graphique 11 ici).

C’est cette latence qui “fait mal” en Italie notamment, où les mesures de confinement ont réellement été prises le 9/03: la propagation poursuit sa lancée, le nombre de cas augmente drastiquement, et avec lui le nombre de décès, en ayant l’impression d’être impuissants face à l’ampleur du phénomène. Les mesures de confinement ralentiront le phénomène, simplement il faut passer le cap de cette “latence”.

Prédire le nombre de cas détectés les prochains jours.

Etant donnée cette latence, le nombre d’infectés va probablement continuer d’une manière similaire. Ainsi, on va pouvoir donner une estimation grossière du nombre de cas en utilisant notre modèle. Faisons le sur 12 jours, c’est à dire la durée qui a été nécessaire en chine pour que les mesures aient un impact.

X_test = np.array(range(52,65))
y_pred = exp_func(X_test, *popt)

day_of_month = 14

for i, value in enumerate(y_pred):
    print(f"Le {day_of_month + i} mars on peut prédire un nombre de cas diagnostiqués d'environ {int(value)}.")

Le 14 mars on peut prédire un nombre de cas diagnostiqués d'environ 4597.
Le 15 mars on peut prédire un nombre de cas diagnostiqués d'environ 5848.
Le 16 mars on peut prédire un nombre de cas diagnostiqués d'environ 7439.
Le 17 mars on peut prédire un nombre de cas diagnostiqués d'environ 9463.
Le 18 mars on peut prédire un nombre de cas diagnostiqués d'environ 12037.
Le 19 mars on peut prédire un nombre de cas diagnostiqués d'environ 15311.
Le 20 mars on peut prédire un nombre de cas diagnostiqués d'environ 19476.
Le 21 mars on peut prédire un nombre de cas diagnostiqués d'environ 24774.
Le 22 mars on peut prédire un nombre de cas diagnostiqués d'environ 31513.
Le 23 mars on peut prédire un nombre de cas diagnostiqués d'environ 40085.
Le 24 mars on peut prédire un nombre de cas diagnostiqués d'environ 50989.
Le 25 mars on peut prédire un nombre de cas diagnostiqués d'environ 64859.
Le 26 mars on peut prédire un nombre de cas diagnostiqués d'environ 82501.

Estimer le nombre de cas rééls actuels

Bien évidemment étant donné le nombre limité de personnes que l’on peut diagnostiquer, et du fait que la majorité des personnes tombe malade sans forcement savoir qu’elles sont atteintes du COVID-19, le nombre de personne réellement malades est bien supérieur. On peut reprendre l’analyse de Thomas Pueyo avec les données actuelles, pour donner une estimation du nombre de cas actuels rééls dans la nature. Le délai moyen entre l’infection et la mort est en moyenne d’environ 17 jours (voir ici).

Dans de bonnes conditions de soins comme en France (pour le moment), on a une mortalité probablement d’au moins 2% (nombres de personnes décédés / nombre de personnes atteintes). “Au moins” car les personnes atteintes peuvent encore décéder avant d’être des cas “clos”. Ainsi, pour x décès aujourd’hui, on peut estimer à environ x * 100/2 = 4550 personnes malades il y a 17 jours. Aujourd’hui nous avons 4499 malades déclarés. Cette estimation du nombre de cas d’il y a 17 jours parait donc plausible au vu des données actuelles. Etant donné qu’il n’y a pas d’impact des mesures prises par le gouvernement entre il y a 17 jours et maintenant, on peut appliquer le taux de croissance de notre modèle pour estimer le nombre de malades aujourd’hui (on fait donc l’hypothèse que la proportion de personnes malades se faisant diagnostiquer est constante). On trouve ainsi qu’ajourd’hui nous avons comme estimation du nombre de cas actuels, puisqu’il y a actuellement 91 personnes décédées:

died = 91
x_17_before = died * 100 / 2

estimation_real_cases = int(x_17_before* (1 + float(r) / 100) ** 17)
print(f"Aujourd'hui nous avons donc environ {estimation_real_cases} nombre de cas.")

Aujourd'hui nous avons donc environ 271879 nombre de cas.

Le nombre de personnes actuellement atteintes par le virus dépend du taux de mortalité, mais cette estimation nous dit qu’elle se compte déjà probablement en centaines de millliers.

Notons que l’estimation de la mortalité peut grimper jusqu’à 4-5% dans le cas où les moyens présents pour les malades ne sont pas suffisants (voir Hubei).

Conclusion

Il ne faut pas prendre la situation à la légère. Limiter la propagation est une question de vie ou de mort pour les personnes fragiles. Empêcher la surcharge des hôpitaux est surement le plus important pour limiter le nombre de décès.

Conseils: Nettoyez vos téléphones. Une part très importante de la population utilise son téléphone de manière compulsive toute la journée. L’utiliser, se laver les mains puis le réutiliser amène à de la contamination: nettoyez vos téléphones ! Et restez chez vous, autant que possible.

Update du 15/03/20: On peut se mouiller un peu plus. Ce dimanche 15 mars, les élections municipales ont été maintenues. Qui plus est il semblerait que beaucoup de gens aient voulu “féter” le dernier soir d’ouverture des bars ce samedi. Il est donc raisonnable de penser qu’avant un ralentissement, dans environ 12-15 jours, il y aura un superpic de cas dû à ces deux évènements. Ceci sera problématique, puisque on aprochera probablement des 80k cas diagnostiqués, la population pourrait commencer à mal vivre l’isolement, et surtout à avoir une sensation d’inutilité des mesures, à cause de ce délai. Il faut que les gens comprennent ce phénomène de latence, pour mieux réagir.

What is Subgroup Discovery ?

Subgroup Discovery, Emerging Patterns, Contrast Set, or Discriminative Pattern Mining all refer to the same idea: finding patterns that are discriminative of a target class. In other words, the aim is to find predictive interpretable rules of a class. As an example, Herrera et al used Subgroup Discovery in the context of a pyschiatric emergency department. They found rules like:

• If Sex=Male and DAY=Monday -> Suicide
• If Sex=Female and (DAY=SUNDAY or DAY=MONDAY) and TIME=LATE_EVENING -> Suicide

Of course these rules are not correct 100% of the time, but they tell you that when a pattern appears, there are more chances that the class appears too.

This is interesting for two reasons:

• Understanding your data in a way that is interpretable by an expert.
• Using those patterns to improve classification or regression algorithms. Indeed, as they are discriminative of a target class, you can use them as features to improve classical supervised learning.

Subgroup discovery can then be used to improve your system, thanks to interpretability: knowing that people have more suicidal thoughts on Sunday and Monday, particulary at night, you can engage more psychology support workers during those periods of time in the department, for example.

Let’s try it on Mushroom

Mushroom is a famous dataset which contains characteristics of different species of mushrooms: its odor, color, habitat etc. More importantly, there is also the information if a mushroom is edible, or not.

This will be our target class: when using a subgroup discovery algorithm, we consider a dataset and a target class, and the algorithm returns a set of rules discriminative of this class. Here, we are looking for patterns discriminative of Poisonous mushrooms. In other words, we want to find the conjunction of features that are characteristics of poisonous mushrooms.

First, let’s install pysubgroup package, which is an implementation of several subgroup discovery algorithms, in Python:

pip install pysubgroup

import pysubgroup as ps
import pandas as pd

Let’s take a look at the dataset.

data = pd.read_csv("./mushroom.csv")
print(data.describe())

        EDIBLE CAP-SHAPE CAP-SURFACE CAP-COLOR BRUISES  ODOR GILL-ATTACHEMENT  \
count     8417      8416        8416      8416    8416  8416             8416   
unique       3         6           4        10       2     9                2   
top     EDIBLE    CONVEX       SCALY     BROWN      NO  NONE             FREE   
freq      4488      3796        3268      2320    5040  3808             8200   

       GILL-SPACING GILL-SIZE GILL-COLOR  ... STALK-SURFACE-BELOW-RING  \
count          8416      8416       8416  ...                     8416   
unique            2         2         12  ...                        4   
top           CLOSE     BROAD       BUFF  ...                   SMOOTH   
freq           6824      5880       1728  ...                     5076   

       STALK-COLOR-ABOVE-RING STALK-COLOR-BELOW-RING VEIL-TYPE VEIL-COLOR  \
count                    8416                   8416      8416       8416   
unique                      9                      9         1          4   
top                     WHITE                  WHITE   PARTIAL      WHITE   
freq                     4744                   4640      8416       8216   

       RING-NUMBER RING-TYPE SPORE-PRINT-COLOR POPULATION HABITAT  
count         8416      8416              8416       8416    8416  
unique           3         5                 9          6       7  
top            ONE   PENDANT             WHITE    SEVERAL   WOODS  
freq          7768      3968              2424       4064    3160  

[4 rows x 23 columns]

We now have to specify the target class: in our case, it’s the column ‘EDIBLE’, when it takes the value ‘POISONOUS’. Mind that we should remove this column from the data (the set of features), or otherwise it will be considered as a feature, resulting in rules like POISONOUS -> POISONOUS.

target = ps.BinaryTarget ('EDIBLE', 'POISONOUS')
searchspace = ps.create_selectors(data, ignore=['EDIBLE'])

Then we have to create a Subgroup Discovery Task. In particular, we have to specify three parameters:

• the number of rules we want to extract (result_set_size),
• the maximum size of the rule (depth),
• the quality measure. If you do not know what a quality measure is and which one is better for your task, you can take the Weighted Relative Accuracy (WRAcc), which is one of the most popular of the domain.

task = ps.SubgroupDiscoveryTask (data, target, searchspace, 
            result_set_size=5, depth=5, qf=ps.WRAccQF())

Finally, we have to choose an algorithm to mine the rules. By default we can use the popular beam search.

results = ps.BeamSearch().execute(task)

Finally, we print the rules we have got:

results.to_dataframe()

0.19389014936350082: <<T: EDIBLE=POISONOUS; D: BRUISES=NO AND GILL-SPACING=CLOSE AND VEIL-TYPE=PARTIAL AND VEIL-COLOR=WHITE>>
0.19389014936350082: <<T: EDIBLE=POISONOUS; D: BRUISES=NO AND GILL-SPACING=CLOSE AND VEIL-COLOR=WHITE>>
0.19236944009552903: <<T: EDIBLE=POISONOUS; D: BRUISES=NO AND GILL-SPACING=CLOSE AND GILL-ATTACHEMENT=FREE AND VEIL-COLOR=WHITE>>
0.19236944009552903: <<T: EDIBLE=POISONOUS; D: BRUISES=NO AND GILL-SPACING=CLOSE AND GILL-ATTACHEMENT=FREE>>
0.19236944009552903: <<T: EDIBLE=POISONOUS; D: BRUISES=NO AND GILL-SPACING=CLOSE AND VEIL-TYPE=PARTIAL AND GILL-ATTACHEMENT=FREE>>

It is important to know that the WRAcc takes its values in a range [-0.25;0.25] on a balanced dataset. Therefore, a value of 0.1938 is very good: this means that this pattern is highly discriminative of poisonous mushrooms.

Let’s take a look at the first example that we have got. We learn that if a mushroom has a close gill-spacing, a veil-type partial and white, and has no bruises, then very likely, it is a poisonous one.

This is perfectly interpretable for an expert. The following picture shows what are the gill-spacing (or Hymenium here) and the Veil.

Let’s take an example with the famous Amanita phalloides. As you can see on the picture below, this mushroom has no bruises (I guess ? I am not an expert in mushrooms actually :) ), a close gill-spacing, and a white and partial veil. The rule tells you it is probably poisonous, and it is: Amanita phalloides is one of the most toxic mushrooms !

That’s it, we have extracted useful knowledge from our dataset, and we can now use it to better understand our system.

Note: The documentation of pysubgroup is lacking, but hopefully it will improve in the future.

Note: There are also other ways to extract interpretable rules, for example training a decision tree and extracting the path taken in the tree can give a pattern explaining the prediction. Clustering can also group similar elements, and finding frequent pattern between them can create interpretable rules.

The advantage of subgroup discovery over those methods is that it has been made to give those rules, whereas in those other methods it is not the main purpose of the algorithm. Here, you have more control over what kind of rules you want to propose to the end-user, particulary because you can choose the Quality Measure you want to use. In this formalism you can also use exhaustive algorithm to list all possible rules, which is not the case in a decision tree, greedy by nature.

Dans la vie réelle, les applications informatiques durent dans le temps (on ne jette pas le code à la fin de la journée contrairement à un TP). De plus, les spécifications et les entrées du programme évoluent. A partir du moment où le code contient plus de 2 ou 3 fonctions, il va falloir faire attention aux “effets de bords”, c-à-d que la modification du programme pour répondre à cette nouvelle spécification ne détruise pas d’autres fonctionnalités du logiciel.

Solution

Le Test Driven Development (TDD) est un paradigme (“une façon de faire”) où on cherche à écrire les tests d’un code informatique avant d’écrire ledit code. Ainsi, lorsqu’on voudra changer le code, il suffira d’écrire de nouveaux tests pour tester les nouveaux cas, et relancer les anciens tests. On minimise les erreurs en se forçant à faire des fonctions courtes, qui répondent à une spécification précise dont on test les cas limites le plus possible. En général ça permet de faire du meilleur code, plus maintenable, plus concis, mieux testé.

Le cycle du TDD est le suivant:

1. Ecrire le test
2. Lancer les tests. Ca doit échouer
3. Ecrire le code
4. Lancer les tests. Ca doit fonctionner
5. Refactor. La modification du programme peut faire qu’il faille le “nettoyer” pour qu’il soit plus simple à maintenir à l’avenir.

Activité: FizzBuzz

Pour faire nos tests, nous utiliserons pytest. L’arborescence des fichiers est simple:
├── TDD_example
│ ├── fizzbuzz.py
│ └── test_fizzbuzz.py

Cycle numéro 1

Le programme doit fonctionner de la manière suivante:
Entrée: 1
Sortie: 1

Lancer le cycle TDD: Ecrire les tests, les lancer, écrire le code, relancer les test.

Solution:

# test_fizzbuzz.py
from fizzbuzz import fizzbuzz  
  
def test_process_number():  
    assert fizzbuzz(1) == 1  

# fizzbuzz.py
def fizzbuzz(number):  
    if number == 1:
        return 1  

Pour lancer les tests avec pytest c’est simple, en étant dans le répertoire:

pytest

On écrit le code minimal qui répond à la spécification. On lance les tests. Si tout fonctionne, on a fait un cycle de TDD.

Cycle numéro 2

Entrée: 1, 2 (1 ou 2)
Sortie: 1, 2

Solution:

# test_fizzbuzz.py
from fizzbuzz import fizzbuzz  
  
def test_process_number():  
    assert fizzbuzz(1) == 1
    assert fizzbuzz(2) == 2  

# fizzbuzz.py
def fizzbuzz(number):  
    return number  

On a modifié fizzbuzz, il répond à la nouvelle spécification, mais on vérifie aussi (et facilement) que les spécifications précédentes sont validées. On a la garantie qu’on n’a pas cassé le fonctionnement du programme testé.

Cycle numéro 3

Entrée: 1, 2,3
Sortie: 1, 2, fizz

Solution:

# test_fizzbuzz.py
from fizzbuzz import fizzbuzz  
  
def test_process_number():  
    assert fizzbuzz(1) == 1
    assert fizzbuzz(2) == 2
    assert fizzbuzz(3) == 'fizz'  

# fizzbuzz.py
def fizzbuzz(number):
    if number == 3:
        return 'fizz'  
    return number  

On a un nouveau cas, qu’on gère facilement avec un if.

Cycle numéro 4

Entrée: 1, 2, 3, 5
Sortie: 1, 2, fizz, buzz

Solution:

# test_fizzbuzz.py
from fizzbuzz import fizzbuzz  
  
def test_process_number():  
    assert fizzbuzz(1) == 1
    assert fizzbuzz(2) == 2
    assert fizzbuzz(3) == 'fizz'
    assert fizzbuzz(5) == 'buzz'

# fizzbuzz.py
def fizzbuzz(number):
    if number == 3:
        return 'fizz'
    if number == 5:
        return 'buzz'  
    return number  

Encore un nouveau cas, qu’on a géré avec un autre if.

Cycle numéro 5

Entrée: 1, 2, 3, 5, 6, 10
Sortie: 1, 2, fizz, buzz, fizz, buzz

Solution:

# test_fizzbuzz.py
from fizzbuzz import fizzbuzz  
  
def test_process_number():  
    assert fizzbuzz(1) == 1
    assert fizzbuzz(2) == 2
    assert fizzbuzz(3) == 'fizz'
    assert fizzbuzz(5) == 'buzz'
    assert fizzbuzz(6) == 'fizz'
    assert fizzbuzz(10) == 'buzz'

# fizzbuzz.py
def fizzbuzz(number):
    if number % 3 == 0:
        return 'fizz'
    if number % 5 == 0:
        return 'buzz'  
    return number  

Cette fois-ci on se rend compte que c’est les multiples de 3 qui doivent retourner “fizz” et les multiples de 5 qui doivent donner “buzz”.

Cycle numéro 6

Entrée: 1, 2, 3, 5, 6, 10, 15
Sortie: 1, 2, fizz, buzz, fizz, buzz, fizzbuzz

Solution:

# test_fizzbuzz.py
from fizzbuzz import fizzbuzz  
  
def test_process_number():  
    assert fizzbuzz(1) == 1
    assert fizzbuzz(2) == 2
    assert fizzbuzz(3) == 'fizz'
    assert fizzbuzz(5) == 'buzz'
    assert fizzbuzz(6) == 'fizz'
    assert fizzbuzz(10) == 'buzz'
    assert fizzbuzz(15) == 'fizzbuzz'

# fizzbuzz.py
def fizzbuzz(number):
    if number % 3 == 0 and number % 5 == 0:
        return 'fizzbuzz'  
    if number % 3 == 0:
        return 'fizz'
    if number % 5 == 0:
        return 'buzz'
    return number  

On a encore un nouveau cas: les nombres multiples de 3 et 5 doivent afficher ‘fizzbuzz’. On le gère dans ce nouveau cycle TDD

Les tests fonctionnent bien, on peut “refactor” le code pour avoir quelque chose de plus élégant. On ajoute une doc pour expliquer ce que fait la fonction, utile quand on voudra reprendre le code des mois/années plus tard ou pour expliquer rapidement à un autre développeur qui travaillerait sur le projet.

# fizzbuzz.py
def fizzbuzz(number):
    '''
    :param number: number
    :return: 'fizz' if number is multiple of 3, 'buzz' if number is multiple of 5, 'fizzbuzz' is multiple of both, or number in the default case.
    '''
    multiple_3 = number % 3 == 0
    multiple_5 = number % 5 == 0
    
    if multiple_3 and multiple_5:
        return 'fizzbuzz'  
    elif multiple_3:
        return 'fizz'
    elif multiple_5:
        return 'buzz'
    return number  

This question appeared when I read the SAX algorithm. It is used to convert a time series to a sequence of symbols. The trick is briefly explained in the paper, but the implementation requires a bit of thinking. Following schema is taken from the original paper, Experiencing SAX: a Novel Symbolic Representation of Time Series

The natural way would be to consider each slot to be the size of the following equation (n//w is the floor division) \(\frac{n}{w} = n // w + \frac{n \% w}{w}\). We start from index 0, we add n//w points, then we add a proportion of the next point, corresponding to (n%w)/w. For the second slot, we take the rest of the proportion of the previous point, we add n//w point, then the rest of the proportion of the last point so that the size of the slot is n/w. We keep doing this process until we reach the end of the series.
The issue with this strategy is that is quite difficult and inelegant to code.

There is a more elegant way. If we multiply n by w, we can consider that we repeat each point w times. What is the point of doing this ? We saw that the proportion of point we need to add to the current slot is a quantity that we will divide by w (it is (n%w)/w). Considering we repeat each point w times, we will be able to deal with a number of points that is an integer.

Now the slot does not have a size of n/w, but n. We sum each element of the slot, then we divide by n at the end: we will indeed get the mean of the slot. For example, the second slot in the picture above has a mean of (s[i] corresponds to the ith element of the serie):
\(\frac{\frac{2}{3}s[2] +\frac{2}{3}s[3]}{\frac{4}{3}}\)

Considering the new representation, the mean is:
\(\frac{2s[2] +2s[3]}{4}\)

which is the same.

Now the code:

def paa(s, w):
    res = [0] * w
    n = len(s)
    for i in  range(w * n):
        idx = i // n
        pos = i // w
        res[idx] += s[pos]
    res = [x / n for x in res]
    return res
    
print(paa([1, 2, 0, 4, 3, 5, 6, -2, 3  -4], 4))
# >>> [1.3333333333333333, 2.4444444444444446, 4.888888888888889, -0.6666666666666666]

The following plot shows what the PAA looks like:

NB: Note however that this method has the disadvantage of increasing a lot the number of iterations. If you consider a long timeseries, it may be too long. If it is the case, you can choose to simply consider slot to have size n // w. If w is not divisble by w, we will have w + 1 slot, the last one having less points (you need to be aware of that).