Journal Le 16, le nombre du démon

Sommaire

• 3615 My Life
• Un jeu de données
• Enfin du rust - csv et serde
• Des types
• Des Traits
• On rassemble tout ça.
• Les résultats
• Les questions en suspens
• Bon d'accord
• Conclusion

3615 My Life

Salut Journal,

je suis entouré de personnes formidables. Et toute cette formidabilité n'empêche pas quelques bizarreries. Par exemple, savais-tu que certains nombres apportent une pluie d'argent et de crêpes au nutella, et au contraire que d'autre, à leur simple évocation, apportent la famine et un PC sous windows 10 avec un processeur bas de gamme de 2009 et exclusivement des applis basées sur électron ?

Bref le démon guette. Surtout le nombre 16. Celui-là est terrible.

Ou pas.

Après tout, je peux vivre tranquillement en contact avec des personnes qui ont des croyances que je trouve étranges.

Hier matin, profitant de cette sortie de confinement pour me dorer la pilule - bien blanche d'informaticien -, je me retrouve dans une rue que je ne fréquente pas souvent. Et devant moi, elle est là, abandonnée, délabrée et presque inquiétante, la maison du numéro 16.

Quoi ? Du 16 ? Mon esprit taquin et joueur a vu une maison à l'abandon, a lu la plaque "16" et a formé la pensée suivante : "C'est normal, le 16 c'est le nombre du diable-vilain-pas-beau".

Hop hop hop. Serait-t'il possible que la présence dans mon entourage d'un culte numérologique ait déteint sur ma pensée ? Probablement. Il est temps de clarifier tout ça pour moi même (et pour rigoler).

Et pour ça, je vais écrire du rust parce que c'est mon culte du moment à moi.

Un jeu de données

Si le 16 est vraiment un nombre abominable (et que le 8 est merveilleux), je devrais pouvoir montrer des corrélations entre des évènements (heureux ou malheureux) et ces nombres.

Sans faire exprès, je suis tombé (aie) sur le fichier des personnes décédées, mis à disposition par data.gouv.fr.

En voilà donc une bonne idée ! Je vais lire ce fichier, et regarder si :

• Les gens meurent plus souvent un 16 qu'un autre jour
• Les gens qui sont nés un 16 ont une vie plus courte que les autres
• Les gens meurent plus souvent un jour où la date se réduit à un 16

Mais qu'est-ce que c'est que cette histoire de réduction ? Jeune padawan du culte numérologique, rentre et assied-toi, le grand Skippy va t'expliquer. Le 16 apparaît aussi en additionnant les chiffres qui composent les nombres.

C'est ainsi que si ta voiture a cette plaque d'immatriculation : DD 826 DD, alors je sais que tu conduis une toyota avensis verso de 2005, mais surtout que c'est la voiture du diable. Parce que 826, ça se réduit à 16 : 8 + 2 + 6 = 16.

Et ça, jeune padawan, c'est la loi de la matrice. Ça fait peur, hein ?

Dans le fond là-bas, je vous vois faire de l'ironie sur le niveau mathématique des lois de la matrice.

C'est vrai que sérieusement, à quoi ça sert de faire des études, de se fader des trucs comme le théorème de Heine, si tout se résume à des additions ? En même temps, c'est préférable, parce que les additions, j'ai presque compris, Heine, c'est pas gagné (du tout).

Sache aussi que ceci s'applique aux dates. Par exemple, le 16 mai 2020, c'est 1 + 6 + 0 + 7 + 2 + 0 = 16. Cette journée sera abominable, un 16 qui se réduit à un 16. La matrice toute entière en tremblera.

Tu noteras que les lois de la matrice sont très "eighties", parce que les années sont sur 2 digits… Peut-être que les designers de javascript étaient, eux aussi, adeptes du grand Skippy.

Si tu n'as pas encore refermé l'onglet en cliquant rageusement sur "moinsser", on continue. On va écrire du code pour revenir à un peu plus de rationalité.

Enfin du rust - csv et serde

La source de la donnée est au format csv. Il existe une crate pour lire (et écrire) du csv et elle s'appelle… csv ! (Incroyable…).

Je l'utilise volontiers avec serde parce que c'est facile et élégant. (Mais rien ne t'oblige, Skippy ne s'est pas prononcé la-dessus)

Serde, ça vient de ser-ialize et de-serialize, en gros, ça aide à transformer une structure rust en mémoire dans une autre représentation (du json, du toml, du csv…).

On rajoute les 2 dans Cargo.toml :

csv = "1.1.3"
serde = { version = "1.0.110", features = ["derive"] }

Astuce, lance un :

$ cargo build

pendant que tu fais le reste, comme ça, ça télécharge/compile/etc… pendant que tu codes le reste. (C'est ça le fearless concurrency de rust !)

Le fichier de données a un header de ce type :

$ head -n 1 insee_deces.csv
nom,prenom,sexe,date_naissance,code_lieu_naissance,lieu_naissance,pays_naissance,date_deces,code_lieu_deces,numero_acte_deces

Alors on peut écrire :

use serde::Deserialize;

#[derive(Debug, Deserialize)]
struct Record {
    nom: String,
    prenom: String,
    sexe: String,
    date_naissance: String,
    code_lieu_naissance: String,
    lieu_naissance: String,
    pays_naissance: String,
    date_deces: String,
    code_lieu_deces: String,
    numero_acte_deces: String,
}

Je vois 3 choses :

• Le mélange du français et de l'anglais dans le code, ça me donne un peu envie de vomir
• Le nom des champs de la structure correspondent aux entêtes. C'est magique ! Si jamais les entêtes étaient bien plus bizarre, il aurait été possible de les renommer pour découpler les champs de la structure et les entêtes.
• Tous les champs sont des chaines de caractères. On voit ça au paragraphe d'après.

Et maintenant, on lit le fichier :

use std::error::Error;
use csv;

fn main() -> Result<(), Box<dyn Error>> {
    let mut rdr = csv::Reader::from_reader(io::stdin());
    for result in rdr.deserialize() {
        let record: Record = result?;
        println!("{:?}", record);
    }
    Ok(())
}
}

On lance :

$ head -n 10 insee_deces.csv | cargo run
Record { nom: "LANGLET", prenom: "ANTOINETTE GERMAINE", sexe: "2", date_naissance: "1903-11-11", code_lieu_naissance: "02383", lieu_naissance: "HOMBLIERES", pays_naissance: "", date_deces: "1983-04-11", code_lieu_deces: "02691", numero_acte_deces: "369" }
...

Et ça marche ! Skippy va être fier ! \o/

Des types

Le type de sexe est en fait un entier, avec 1 pour les hommes et 2 pour les femmes.
(Comme les numéros de sécurité sociale, j'imagine…). J'en ai pas besoin pour mon problème de grand Skippy, mais c'est mon journal, je fais ce que je veux.

Alors je fais un enum pour représenter le sexe :

#[derive(Debug)]
enum Sex {
    Male,
    Female,
}

Je dérive Debug parce que c'est le Trait qui permet de println!("{:?}", ...).
Bref, ça offre la possibilité d'afficher pour le debug.

Dans la structure Record, je vais changer :

sexe: String,

en :

sexe: Sex,

et forcément le compilateur n'est pas content :

error[E0277]: the trait bound `Sex: _IMPL_DESERIALIZE_FOR_Record::_serde::Deserialize<'_>` is not satisfied
  --> src/main.rs:36:5
   |
36 |     sexe: Sex,
   |     ^^^^ the trait `_IMPL_DESERIALIZE_FOR_Record::_serde::Deserialize<'_>` is not implemented for `Sex`
   |
   = note: required by `_IMPL_DESERIALIZE_FOR_Record::_serde::de::SeqAccess::next_element`

J'ai beau vouer un culte à rust et à son écosystème, la première fois, ça m'a fait peur.
Et puis avec le temps, j'arrive à déchiffrer que bref, il n'arrivera pas à désérialiser Sex, parce que serde ne sait pas comment faire. (en gros…).

Pour aider serde, on utilise l'attribut deserialize_with de cette façon :

#[serde(deserialize_with = "deserialize_sex")]
sexe: Sex,

Et deserialize_sex c'est une fonction qui va prendre un Deserializer en entrée et sortir un Sex (ou une erreur). Elle ressemble à ça :

use serde::{Deserialize, Deserializer};
fn deserialize_sex<'de, D>(de: D) -> Result<Sex, D::Error>
where
    D: Deserializer<'de>,
{
    // on lit un u32
    let raw_sex = u32::deserialize(de)?;
    match raw_sex {
        // une femme
        2 => Ok(Sex::Female),
        // un homme
        1 => Ok(Sex::Male),
        // c'est une erreur (pour l'administration...)
        _ => {
            return Err(de::Error::invalid_value(
                de::Unexpected::Unsigned(raw_sex.into()),
                &"1 or 2",
            ))
        }
    }
}

Je relance :

$ head -n 10 insee_deces.csv | cargo run
Record { nom: "LANGLET", prenom: "ANTOINETTE GERMAINE", sexe: Female, date_naissance: "1903-11-11", code_lieu_naissance: "02383", lieu_naissance: "HOMBLIERES", pays_naissance: "", date_deces: "1983-04-11", code_lieu_deces: "02691", numero_acte_deces: "369" }
...

Et j’apprends qu'Antoinette Germaine était une femme !

Toutes ces histoires de sexe, sans aucune vanne pourrie. Je vieillis. Skippy c'est le projet de la maturité.

En fait, ce qui m'intéressait, c'était surtout les dates. Mais je suis passé par le sexe, parce que c'est un exemple bien plus intéressant.

Effectivement, la désérialisation (coucou l'académie française !) des dates est un problème résolu par la crate chrono.

Un :

chrono = { version = "0.4.11", features = ["serde"] }

dans Cargo.toml et :

use chrono::NaiveDate;

struct Record {
    ...
    date_naissance: NaiveDate,
    ...
    date_deces: NaiveDate,
    ...
}

Et c'est tout :

$ head -n 10 insee_deces.csv | cargo run
Record { nom: "LANGLET", prenom: "ANTOINETTE GERMAINE", sexe: Female, date_naissance: 1903-11-11, code_lieu_naissance: "02383", lieu_naissance: "HOMBLIERES", pays_naissance: "", date_deces: 1983-04-11, code_lieu_deces: "02691", numero_acte_deces: "369" }
...

Antoinette est toujours une femme, avant elle était née à une String, maintenant elle est née à une NaiveDate. C'est plus clair, non ?

Des Traits

Pour calculer la réduction d'un nombre, j'ai besoin de séparer un nombre en chiffres. Genre 123 => [1, 2, 3].

Bien sûr, on peut écrire une fonction tristoune de ce type :

fn split_in_digits(i: u32) -> Vec<u32> {
    ...
}

Mais ce serait plus classe de faire un Trait de cette façon :

pub trait SplitInDigit {
    fn split_in_digits(&self) -> Vec<u32>;
}

Ça permettrait de faire :

123.split_in_digits()

Je trouve ça beau et en plus dans les itérateurs, le code se lit plus facilement grâce à un Trait. (Un exemple un peu plus bas… Si ça c'est pas du Cliffhanger de milieu de saison…).

Alors on l'implémente de cette façon :

impl SplitInDigit for u32 {
    fn split_in_digits(&self) -> Vec<u32> {
        let mut i = *self;
        let mut digits = vec![];
        while i > 0 {
            let digit = i - (i / 10) * 10;
            i = i / 10;
            digits.insert(0, digit);
        }
        digits
    }
}

Comme je n'écris jamais ce genre de code correctement la première fois, je fais un test :

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn split_in_digit_u32() {
        let i: u32 = 12345;
        assert_eq!(i.split_in_digits(), vec![1, 2, 3, 4, 5]);
    }
}

$ cargo test
...
test tests::split_in_digit_u32 ... ok
...

C'est un peu moche, mais ça marche. Alors, pressé d'en savoir plus sur Skippy, je continue.

Je me fais aussi un Trait pour calculer le nombre de la matrice-magique-de-Skippy :

pub trait ComputeMatriceNumber {
    fn matrice(&self) -> u32;
}

Et je l'implémente pour les dates :

use chrono::{Datelike, NaiveDate};

impl ComputeMatriceNumber for NaiveDate {
    fn matrice(&self) -> u32 {
        self.year().split_in_digits().iter().skip(2)
        .chain(self.month().split_in_digits().iter())
        .chain(self.day().split_in_digits().iter())
        .sum()
    }
}

C'est basé sur Iterator et ça calcule l'algorithme de Skippy.

Note ici que le split_in_digits est tellement bien plus élégamment placé après self.year() qu'un split_in_digits(self.year()). Si tu n'es pas d'accord, c'est que tu n'as aucun goût. (humour…)

self.year().split_in_digits().iter().skip(2)

Ce bout de code divise l'année en chiffres avec split_in_digits : 2020 => [2, 0, 2, 0].

Le transforme en itérateur : iter() et oublie les 2 premiers chiffres (en hommage à javascript Skippy).

À ce moment-là, c'est probablement temps de noter que split_in_digits aurait mieux fait de retourner un itérateur plutôt qu'un vecteur. Bref, je note un TODO et si Skippy est sympa, je le traiterai.

.chain(self.month().split_in_digits().iter())

Le chain, c'est comme en python, ça chaine des itérateurs entre eux. Avec le mois, on le divise en chiffres, et on les colle à ceux de l'année.

Et on fait pareil avec le jour.

Puis on additionne tout ça : sum().

On rassemble tout ça.

Loué soit le grand Skippy, c'est bientôt fini.

On déclare 3 HashMap qui contiendront nos statistiques :

// Le jour de la mort -> le nombre de mort
let mut death_day_to_count: HashMap<u32, u32> = HashMap::new();
// Le nombre magique de la date de la mort -> le nombre de mort
let mut death_matrice_to_count: HashMap<u32, u32> = HashMap::new();
// Le jour de naissance -> la durée de vie (tout cumulé)
let mut birth_day_to_life_duration: HashMap<u32, u64> = HashMap::new();

Et on traite les enregistrements :

Pour le jour de la mort :

let count = death_day_to_count.entry(record.date_deces.day()).or_insert(0);
*count += 1;

L'api de HashMap est quand même sympa, elle nous donne un moyen entry d'éviter un :

if not x in map:
    map[x] = 0
map[x] += 1

Un peu comme un defaultdict avec un peu plus de finesse (un défaut modifiable, clé par clé).

On fait pareil pour le nombre de la matrice :

let count = death_matrice_to_count.entry(record.date_deces.matrice()).or_insert(0);
*count += 1;

Et enfin la date de naissance vs la durée de vie :

let duration = record.date_deces - record.date_naissance;
// Un moyen sûr, précis et parfait de calculer une année
// Désolé Skippy, mais je fatigue
let duration_in_year = duration.num_days() as u64 / 365;
let count = birth_day_to_life_duration.entry(record.date_naissance.day()).or_insert(0);
*count += duration_in_year;

À la fin de la boucle, on affiche tout ça… en csv! Ben oui, pourquoi pas ? Au point où on en est.

Afficher les stats pour death_day_to_count se fait facilement :

let mut wtr = csv::WriterBuilder::new().from_writer(io::stdout());
wtr.serialize(("Death day", "count"))?;
for (day, count) in &death_day_to_count {
    wtr.serialize((day, count))?;
}

Et on peut enfin lancer le processing de la vrai question. 16 ou 42 ?

$ cargo run < insee_deces.csv

Les résultats

Les résultats sont malheureusement assez décevants pour tous les adeptes du grand Skippy. Quelle tristesse.

La répartition jour de la mort -> nombre de morts, ne permet pas de mettre en évidence un effet du 16. Tout juste, on peut se rendre compte que le 31 n'est pas le jour le plus fréquent de l'année. (C'est une découverte que je dois à Skippy).

La répartition des nombres magiques-de-la-matrice-à-Skippy fait apparaître une belle gaussienne :

Qui n'est pas très différente de la répartition des nombres magiques-de-la-matrice-à-Skippy sur les dates de l'intervalle considéré (1970 -> 2020) :

La répartition jour de naissance -> durée de vie (cumulée) est, elle, amusante :

Le 31 est toujours le jour le moins fréquent de l'année (merci Skippy) et naître un 1 serait donc le jour le plus favorable pour vivre longtemps.

Ou bien, j'imagine que le 1er du mois a été assez utilisé pour enregistrer les actes de naissances. (Même si t'étais né un 10…)

Les questions en suspens

C'est la fin et split_in_digits ne renvoie toujours pas un itérateur, c'est honteux.

Sur le fond, la théorie de la matrice de Skippy n'est pas évidente à démontrer.
Je ne vois que 2 explications logiques possibles :

• La matrice est en confinement depuis 1970 parce qu'elle avait peur du coronavirus
• Les dates et les chiffres sont truqués par les chinois du FBI pour nous cacher la réalité de la matrice

Skippy me fait remarquer qu'il y aussi des gens dans des situations très douloureuses dans le fichier.

Par exemple, la pauvre Luton Aurore est née le 1985-05-09 et est morte le 1985-05-08.
Elle a donc vécue -1 jour, ce qui est peu pour s'émouvoir de la beauté de la vie et
fait des overflow débiles sur les calculs de dates.

Bon d'accord

Skippy a appelé et si je lui fais pas un itérateur, il va être 16 fois plus triste.
Et ça, ça me bouleverse. Alors on fait vite fait un itérateur.

D'abord on modifie le Trait :

trait SplitInDigit {
    fn split_in_digits(&self) -> IterSplitInDigit;
}

IterSplitInDigit, ce sera la structure qui implémentera Iterator. Elle est définie comme ça :

struct IterSplitInDigit {
    // La valeur courante
    value: u32,
    // La puissance de 10 courante donc si value = 123, power = 2
    // C'est une explication particulièrement claire et pédagogique
    power: i32,
}

impl IterSplitInDigit {
    fn new(value: u32) -> Self {
        // Pour construire l'itérateur on calcule la puissance de 10 tel que
        // 10 ** power soit la puissance de 10 juste en dessous de value
        // 123 -> 100 donc power = 2
        // J'ai fait un peu plus d'efforts sur ce commentaire-ci...
        let power = (value as f64).log10() as i32;
        IterSplitInDigit {
            value: value,
            power: power,
        }
    }
}

impl Iterator for IterSplitInDigit {
    // Je vais renvoyer des u32
    type Item = u32;

    fn next(&mut self) -> Option<Self::Item> {
        if self.value == 0 {
            // Y a plus rien à faire, tout est épuisé
            None
        } else {
            // La puissance de 10 juste en dessous de value
            let f = 10u32.pow(self.power as u32);
            // Le digit le plus significatif
            let digit = self.value / f;
            // Pour la prochaine itération, ce sera tout propre
            self.value -= digit * f;
            self.power -= 1;
            // On retourne le digit
            Some(digit)
        }
    }
}

On peut donc modifier l'utilisation (note tous les iter() qui disparaissent) :

self.year().split_in_digits().skip(2)
.chain(self.month().split_in_digits())
.chain(self.day().split_in_digits())
.sum()

Et le test qui ne passe plus :

let mut i: u32 = 12345;
assert_eq!(i.split_in_digits().collect::<Vec<u32>>(), vec![1, 2, 3, 4, 5]);

Note l'utilisation de ::<Vec<u32>>() que rust appelle un turbofish. Ça permet de spécifier à collect() dans quel type de collection il va transformer l'itérateur.

Plus généralement, ça indique le type de retour d'une fonction générique. Comme
pour parser une chaîne de caractères dans un entier :

// Indique que parse renvoie un u32.
"16".parse::<u32>()
// Il aurait pu renvoyer un u8 aussi !
"16".parse::<u8>()

Conclusion

Ce journal présente ses plus plates excuses :

• aux personnes agées de 16 ans, 79 ans, 88 ans, 97 ans et 169 ans
• aux habitants d'un 16, 16 bis ou 16 ter
• ainsi qu'aux habitants de ce beau département qu'est la Charente.