Journal Le 16, le nombre du démon

Posté par  . Licence CC By‑SA.
49
15
mai
2020

Sommaire

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).

répartition jour de la mort -> nombre de morts

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

répartition nombre matrice -> nombre de morts

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) :

répartition nombre matrice sur l'intervalle considéré

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

répartition jour de la naissance -> durée de vie

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.
  • # Croix vé bâton

    Posté par  . Évalué à 10.

    Par exemple, le 16 mai 2020, c'est 1 + 6 + 0 + 7 + 2 + 0 = 16

    Hmmm, t'es sûr que tu parles pas du 16 juillet là ?

    • [^] # Re: Croix vé bâton

      Posté par  . Évalué à 5.

      Suffit de prendre l'année sur 4 et le résultat est le même : 1 + 6 + 0 + 5 + 2 + 0 + 2 + 0 = 16
      Magique on vous dit !

  • # 1 : état civil colonial

    Posté par  (site web personnel) . Évalué à 3.

    Dans de nombreuses colonies, le 1 et même le 1/1 a été choisi comme date de naissance arbitraire au moment de la mise en place de l’état civil. L’autre partie étant constituée par une année supputée. J’ai toujours entendu les gens se plaindre du fait que le numéro d’année serait supérieur au numéro réel. Vous avez peut-être mis en évidence une preuve de cela ? À moins d’un bogue quelconque bien sûr.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: 1 : état civil colonial

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 15 mai 2020 à 08:52.

      Je me réponds à moi-même : ce n'est pas ça. L'effet serait même le contraire, à moins de sous-estimer en moyenne les dates de naissance. Mais qui sait ?
      Confiné, on consomme moins de café…

      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: 1 : état civil colonial

      Posté par  . Évalué à 1.

      Il est aussi possible que le 1er du mois soit souvent choisis pour les enfant abandonnés dont la date de naissance n'est pas connue précisément. Cela peut aussi concerner certain émigrés qui ne connaissent pas précisément leur date de naissance.

    • [^] # Re: 1 : état civil colonial

      Posté par  (Mastodon) . Évalué à 3. Dernière modification le 15 mai 2020 à 15:30.

      Je ne sais pas ce qu'il en est de la France mais un ami à moi est prof dans une école qui prend en charge les mineurs qui ont ou dont les parents ont obtenus l'asile pour leur donner des bases pour après pouvoir prétendre à commencer un apprentissage.

      Normalement ils sont censés avoir moins de 18 ans mais dans les faits mon ami est certain que c'est faux car la plupart sont arrivés sans papier et paraissent parfois bien plus vieux que lui. Outre le fait que ça tord le cou aux idées des fachos comme quoi ce seraient tous des feignasses qui veulent vivre au crochet de notre société, la plupart ont du finalement du inventer leur date de naissance et en général ça ne va pas plus loin que le 1er janvier. De toute façon quand t'es illettré tu n'es souvent pas au courant de ta date de naissance réelle alors quand l'officier de l'office de l'immigration t'énumère des dates possibles et que tout ce que tu sais dire est le mot oui c'est vite plié.

      Il y a aussi les 1er janvier pour le plaisir. Ma copine est née le 31 à 23heures quelque chose et comme il n'y avait pas d'autre maman sur le point d'accoucher en même temps dans la même maternité les sages femmes ont accepté d'attendre pour la déclarer officiellement le 1er janvier à 0h.

      • [^] # Re: 1 : état civil colonial

        Posté par  . Évalué à 2.

        En fait, ton dernier exemple n'est pas nécessairement pour le plaisir. En France les enfants sont inscrits à l'école élémentaire à la rentrée scolaire de l'année civile au cours de laquelle ils atteignent l'âge de 6 ans. En pratique cela signifie que ta copine est probablement entrée à l'école primaire un an plus tard que si sa date de naissance avait été le 31/12. Elle était donc probablement la plus âgée de sa classe ce qui peut être considéré comme un avantage.

        • [^] # Re: 1 : état civil colonial

          Posté par  (Mastodon) . Évalué à 2. Dernière modification le 15 mai 2020 à 20:04.

          Ça c'est passé sur un autre continent. D'après elle, c'est juste que ça faisait plaisir à tout le monde. Je n'ai pas demandé à ses parents.

          Après on peut le voir aussi comme perdre 1 an comme si on avait redoublé, d'autant que l'avantage supposé n'est réel que dans les premières années qui, sans problème ou handicap particulier, sont assez faciles.

          • [^] # Re: 1 : état civil colonial

            Posté par  (site web personnel) . Évalué à 2.

            Pas si tu en crois les statistiques. Certaines catégories y prennent un retard qu’elles ne comblent jamais. L’échec entraînant l’échec. C’est très clair en matière de dates de naissance, mais d’autres facteurs jouent aussi.

            « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

            • [^] # Re: 1 : état civil colonial

              Posté par  (Mastodon) . Évalué à 2.

              Je pense qu'il y'a plus à chercher du côté de l'échec dans les jeunes annés des facteurs différents qui vont de la dyslexie, de l'illétrisme des parents ou de leur absence dans le soutien au devoirs pour différentes raisons.

              L'âge exacte de l'enfant doit arriver très loin dans les causes d'un échec.

              • [^] # Re: 1 : état civil colonial

                Posté par  . Évalué à 3. Dernière modification le 19 mai 2020 à 09:18.

                de l'illétrisme des parents ou de leur absence dans le soutien au devoirs pour différentes raisons.
                Ou de leurs carences éducatives, combien de parents prêtent leur téléphone portable à leurs enfants de 3, 2 voire 1 an pour "avoir la paix"…

  • # Bref.

    Posté par  . Évalué à 6.

    Bref. C'est l'histoire d'un gars qui avait visiblement trop de temps à perdre pendant le confinement qui, du coup, a sorti une théorie du complot digne des illuminati autour du nombre 16 en passant par les adresses, les âges de personnes mortes qu'ils ne connait même pas, tout ça saupoudré de poussière de rouille analytique pour nous embrouiller un peu plus. Gageons que les itérateurs nous mènerons dans une totale liberté cosmique vers un nouvel âge réminiscent.

    Bref, c'est vendredi.

    • [^] # Re: Bref.

      Posté par  . Évalué à 7.

      Moi je vois surtout un complot des rustaceans qui se fourvoyent dans l'écriture de plein de code pour faire ce que python + scikit + pandas aurait pondu en 4 lignes de code (j'exagère, mais bon, on est vendredi hein).

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: La réponse est 42

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      En fait, j'ai toujours appris que le nombre maléfique, le chiffre de la bête était le 666. Ce n'est sûrement pas un hasard s'il est totalement absent de ces graphiques. 42 est, peut-être, voire, sans doute, la réponse, mais sûrement pas à cette question.

      Bref.

      Excellent journal cela dit. Ou plutôt, devrais-je dire, journal dont la formidabilité est indiscutable et qui fait apparaître également que les 29 et 30 sont des jours moins courants dans l'année que les autres, bien qu'un peu plus que le 31 (comme c'est étrange).

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: La réponse est 42

        Posté par  . Évalué à 2.

        42 est, peut-être, voire, sans doute, la réponse,

        Je m'inscrit en faux, 42 c'est uniquement "la réponse à La grande question sur la vie, l'univers et le reste" ("The Ultimate Question of Life, the Universe and Everything") ! :D

        • [^] # Re: La réponse est 42

          Posté par  . Évalué à 10. Dernière modification le 15 mai 2020 à 11:24.

          Pas si vite ! Si on écrit 42 sous la forme d'une puissance (4²), on retombe sur le nombre en question.

          • [^] # Re: La réponse est 42

            Posté par  (Mastodon) . Évalué à 6.

            Mais oui !

            Et dire qu'il y en a encore pour nier l'évidence.

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: La réponse est 42

              Posté par  . Évalué à 10. Dernière modification le 15 mai 2020 à 12:22.

              Une autre évidence passée sous silence : 42 en base 10 est égal à 16 en base 36 !

    • [^] # Re: La réponse est 42

      Posté par  . Évalué à 2.

      D’ailleurs au moment ou j’écris ces lignes, le score de ce journal est justement de 42.
      un signe

  • # Méthode de calcul?

    Posté par  . Évalué à 5.

    Parce que 826, ça se réduit à 16 : 8 + 2 + 6 = 16.

    C'est un truc que je comprends pas. Je l'ai vu aussi chez les nombrologues, https://www.francovoyance.com/la-nombrologie/ ou https://www.google.com/search?q=nombrologie pour des infos là dessus.

    Prenons ton 826. 8+2+6 = 16 ==> 1+6 = 7
    Donc ça se réduit en 16 ou en 7?

    Et pourquoi je ferais pas 826 => 82+6 => 88 => 8+8 = 16

    LA MALEDICTION!!!!1!!111!!!

    ou alors 826 => 8+26 => 34 => 3+4 => 7 ??

    • [^] # Re: Méthode de calcul?

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Donc ça se réduit en 16 ou en 7?

      Oui. Sinon ça pourrait faire deux fois 7+1 ou deux fois 9-1, et là c'est tout simplement pas possible. Le nombre que l'on obtient quand on fait 7+1 ou 9-1 ne doit pas être prononcé. Pas compliqué.

      Donc 16 ne peut qu'être réduit à 7. C’est mathémat, enfin c'est comme ça, voilà.

      Pour en savoir plus sur ces histoires de nombre, je vous recommande de vous référer aux textes sacrés.

      Et en fait 42 = 6 de toute façon. Méditez cela jeunes (et moins jeunes) Padawans et scarabées de toutes les tailles.

      « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

  • # RGPD

    Posté par  . Évalué à 5.

    J'ai beaucoup aimé ce journal… Par contre je m'interroge sur sa conformité à la RGPD : est-ce vraiment permis de transmettre ainsi des informations personnelles comme la date de décès de personnes sans avoir recueilli leur consentement ?

    • [^] # Re: RGPD

      Posté par  . Évalué à 3.

      Si c'est une blague : Il faudrait leur demander :)

      Si c'est sérieux, il suffit de suivre le lien donné :

      Ne contenant pas de mentions relatives à la vie privée, il est communicable à toute personne qui en fait la demande et publiable en ligne en application des dispositions des articles L311-9 et L312-1-1 du code des relations entre le public et l’administration, sans occultation puisqu’il ne comporte pas de données personnelles.

      Il est vrai qu'on peut s'interroger sur cette absence "de mentions relatives à la vie privée" quand le contenu du fichier est le suivant :

      Contenu du fichier
      Chaque enregistrement est relatif à une personne décédée et comporte les zones suivantes :

      le nom de famille
      les prénoms
      le sexe
      la date de naissance
      le code du lieu de naissance
      la localité de naissance en clair (pour les personnes nées en France ou dans les DOM/TOM/COM)
      le libellé de pays de naissance en clair (pour les personnes nées à l'étranger)
      la date du décès
      le code du lieu de décès
      le numéro d'acte de décès

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: RGPD

          Posté par  . Évalué à 2.

          Effectivement, merci pour cette distinction que je n'avais pas su faire.

        • [^] # Re: RGPD

          Posté par  . Évalué à 5.

          en même temps un mort à t'il le droit à la vie privée ?

          Je pense que c'est un combats qui malheureusement nous dépasse, et qu'il faudrait qu'ils élisent des représentant pour faire valoir leur droit :D

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: RGPD

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          En outre, bien souvent, un certain nombre de ces données figure sur les mouvements funéraires dans l'espace public quand il y a lieu, quand ils n'ont pas été publiés sous une autre (obituaires sur internet par exemple, annonce dans la presse).

          Et rien n'interdit, de prendre en photo une pierre tombale et de la publier où on veut, sous réserve de la propriété intellectuelle (dans le cas d'un monument créé par un artiste par exemple).

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

      • [^] # Re: RGPD

        Posté par  . Évalué à 4.

        Mais de toute façon, l'état civil n'est pas une donnée publique par définition ? Je veux dire, quand on se marie par exemple, la loi IMPOSE la publication de l'information. Nom, prénom des deux conjoints, date du mariage, et j'en passe.

        Ce pour que "si quelqu'un souhaite s'y opposer pour une raison valable", il le puisse. Un peu sur le même principe que le permis de construire.

        La loi française actuelle est déjà assez "souple", on tend à oublier par exemple que la déclaration d'impôt de tout un chacun est consultable auprès des impôts, par n'importe qui pourvu que ce soit un contribuable dans le même département.

        • [^] # Re: RGPD

          Posté par  . Évalué à 2.

          Mais de toute façon, l'état civil n'est pas une donnée publique par définition ? Je veux dire, quand on se marie par exemple, la loi IMPOSE la publication de l'information. Nom, prénom des deux conjoints, date du mariage, et j'en passe.

          Je ne sais pas, il me semble que demander un extrait d'acte de naissance, par exemple, n'est permis que pour soi même.

      • [^] # Re: RGPD

        Posté par  . Évalué à 2. Dernière modification le 15 mai 2020 à 15:34.

        C'était avant tout une blague ;) Mais je me doutais bien que sur ce site, elle amènerait des commentaires intéressants.

        Par exemple, je ne savais pas que je pouvais consulter la déclaration d'impôts de mon voisin (mais pas de celui de ma mère). Au passage, il existe des pays (je connais au moins la Norvège) où les déclarations ou les avis d'impôts (je ne suis plus sûr duquel) de tout le monde sont en libre accès sur internet.

  • # Durée de vie cumulée

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 15 mai 2020 à 11:33.

    Pourquoi tracer la durée de vie cumulée ? La durée de vie moyenne me paraît plus adaptée. Ça devrait faire disparaitre les artifices des 1, 29, 30 et 31.

  • # D'après Noir François...

    Posté par  . Évalué à 2.

    Moi je croyais que si l'Homme c'était cinq, alors le Démon c'était six, donc Dieu c'était sept.

  • # Serde alors

    Posté par  (site web personnel) . Évalué à 4.

    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…).

    Je m’en vais de ce pas écrire un outil pour merialiser et demerialiser.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Serde alors

      Posté par  . Évalué à 2. Dernière modification le 18 mai 2020 à 09:18.

      Salut,

      Ne te donne pas cette peine, il y a déjà un mérieux concurent !

      Matricule 23415

      • [^] # Re: Serde alors

        Posté par  . Évalué à 2.

        Je me suis connecté pour juste pour pertinenter. C'est génial comme truc, par contre cette commande aurai dû s'appeler "merde" :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.