info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Modulo tout retourné dans les clefs
9 views
Skip to first unread message
Jacques Mathon
Aug 27, 2021, 11:14:02 AM8/27/21
to
Le 27/08/2021 à 15:27, Benoit a écrit :
> Bonjour,
>
> La clef (les deux chiffres supplémentaires) du numéro de sécurité
> sociale en France est basée sur la division par 97. Le but est de
> s’assurer qu’il n’y a pas eu une erreur de saisie (une double erreur
> peut passer au travers).
>
> Quand on calcul un chiffre modulo un autre on obtient un nombre entier
> qui est le reste de la division. Pour la clef de sécu c’est
> 97 - (numéroSécu mod 97)
>
> — Pourquoi compliquer les choses ? Quel est l’intérêt de ne pas avoir un
> 00 mais un 97 ?
Je ne suis pas sûr d'avoir compris ta question.
Tu voudrais diviser par 0 ?
Le choix de 97 me semble être lié au fait qu'il est le plus grand nombre
premier inférieur à 100 ce qui permet d'avoir 97 valeurs différentes de
clés (qui s'écrit avec deux chiffres)
> Les clefs RIB sont identiques et les lettres remplacées par des chiffres
J'ai regardé plusieurs code RIB et je n'y ai pas trouvé de lettres
> allant de 1 à 9. Là, plusieurs lettres donnant le même chiffre une seule
> erreur de saisie peut ne pas être détectée :
> 1 2 3 4 5 6 7 8 9
> A B C D E F G H I
> J K L M N O P Q R
> S T U V W X Y Z
>
> 1. Un mathématicien saurait justifier ces choix ou ai-je loupé une
> marche ?
>
> 2. Pourquoi ne pas avoir pris un nombre premier de trois chiffres, voire
> 9973 ?
À cause de la taille de la clé, je suppose.
> Merci,
De rien
Amicalement
--
Jacques
> Bonjour,
>
> La clef (les deux chiffres supplémentaires) du numéro de sécurité
> sociale en France est basée sur la division par 97. Le but est de
> s’assurer qu’il n’y a pas eu une erreur de saisie (une double erreur
> peut passer au travers).
>
> Quand on calcul un chiffre modulo un autre on obtient un nombre entier
> qui est le reste de la division. Pour la clef de sécu c’est
> 97 - (numéroSécu mod 97)
>
> — Pourquoi compliquer les choses ? Quel est l’intérêt de ne pas avoir un
> 00 mais un 97 ?
Je ne suis pas sûr d'avoir compris ta question.
Tu voudrais diviser par 0 ?
Le choix de 97 me semble être lié au fait qu'il est le plus grand nombre
premier inférieur à 100 ce qui permet d'avoir 97 valeurs différentes de
clés (qui s'écrit avec deux chiffres)
> Les clefs RIB sont identiques et les lettres remplacées par des chiffres
J'ai regardé plusieurs code RIB et je n'y ai pas trouvé de lettres
> allant de 1 à 9. Là, plusieurs lettres donnant le même chiffre une seule
> erreur de saisie peut ne pas être détectée :
> 1 2 3 4 5 6 7 8 9
> A B C D E F G H I
> J K L M N O P Q R
> S T U V W X Y Z
>
> 1. Un mathématicien saurait justifier ces choix ou ai-je loupé une
> marche ?
>
> 2. Pourquoi ne pas avoir pris un nombre premier de trois chiffres, voire
> 9973 ?
À cause de la taille de la clé, je suppose.
> Merci,
De rien
Amicalement
--
Jacques
pehache
Aug 27, 2021, 12:40:41 PM8/27/21
to
Le 27/08/2021 à 17:39, Benoit a écrit :
> Ni vu ni connu, le 27 août 2021 à 17:13, Jacques Mathon osa écrire :
> l’espace 01-97 au lieu de 00-96.
Pourquoi pas... Ce n'est pas très important.
>
>> Le choix de 97 me semble être lié au fait qu'il est le plus grand nombre
>> premier inférieur à 100 ce qui permet d'avoir 97 valeurs différentes de
>> clés (qui s'écrit avec deux chiffres)
>
> Oui, mais pourquoi pas plus gros ? Quand ça a été mis en place le
> matériel ne savait pas le faire ? Ou trop compliqué et donc source
> d’erreurs ?
L'intérêt d'une clef de vérification est de rester courte, sinon ça
devient juste pénible quand il faut renseigner le numéro.
Un clef "modulo 97" détecte toutes les erreurs sur un chiffre unique, et
à priori 96 erreurs sur 97 si plus d'un chiffre erroné. On peut estimer
que c'est suffisant.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
> Ni vu ni connu, le 27 août 2021 à 17:13, Jacques Mathon osa écrire :
>
>> Le 27/08/2021 à 15:27, Benoit a écrit :
>>> Bonjour,
>>>
>>> La clef (les deux chiffres supplémentaires) du numéro de sécurité
>>> sociale en France est basée sur la division par 97. Le but est de
>>> s’assurer qu’il n’y a pas eu une erreur de saisie (une double erreur
>>> peut passer au travers).
>>>
>>> Quand on calcul un chiffre modulo un autre on obtient un nombre entier
>>> qui est le reste de la division. Pour la clef de sécu c’est
>>> 97 - (numéroSécu mod 97)
>>>
>>> — Pourquoi compliquer les choses ? Quel est l’intérêt de ne pas avoir un
>>> 00 mais un 97 ?
>>
>> Je ne suis pas sûr d'avoir compris ta question.
>> Tu voudrais diviser par 0 ?
>
> Non, avoir un résultat = 0 (donc une clef égale à 00). Ils ont choisi
>> Le 27/08/2021 à 15:27, Benoit a écrit :
>>> Bonjour,
>>>
>>> La clef (les deux chiffres supplémentaires) du numéro de sécurité
>>> sociale en France est basée sur la division par 97. Le but est de
>>> s’assurer qu’il n’y a pas eu une erreur de saisie (une double erreur
>>> peut passer au travers).
>>>
>>> Quand on calcul un chiffre modulo un autre on obtient un nombre entier
>>> qui est le reste de la division. Pour la clef de sécu c’est
>>> 97 - (numéroSécu mod 97)
>>>
>>> — Pourquoi compliquer les choses ? Quel est l’intérêt de ne pas avoir un
>>> 00 mais un 97 ?
>>
>> Je ne suis pas sûr d'avoir compris ta question.
>> Tu voudrais diviser par 0 ?
>
> l’espace 01-97 au lieu de 00-96.
Pourquoi pas... Ce n'est pas très important.
>
>> Le choix de 97 me semble être lié au fait qu'il est le plus grand nombre
>> premier inférieur à 100 ce qui permet d'avoir 97 valeurs différentes de
>> clés (qui s'écrit avec deux chiffres)
>
> matériel ne savait pas le faire ? Ou trop compliqué et donc source
> d’erreurs ?
L'intérêt d'une clef de vérification est de rester courte, sinon ça
devient juste pénible quand il faut renseigner le numéro.
Un clef "modulo 97" détecte toutes les erreurs sur un chiffre unique, et
à priori 96 erreurs sur 97 si plus d'un chiffre erroné. On peut estimer
que c'est suffisant.
--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
HB
Aug 27, 2021, 1:06:25 PM8/27/21
to
Le 27/08/2021 à 17:39, Benoit a écrit :
(...)
>
> Et donc la taille des calculs. Je n’arrive pas à trouver sur le net la
> date de création/invention de la clef. Ceci pourrait expliquer cela.
>
Le numéro sans clé date des années 40
mais il a progressivement évolué (entre autres pour inclure les femmes)
La clé de contrôle à deux chiffres fut ajoutée bien plus tard
(années 70) lors des débuts de l'informatisation des services...
d'où, _peut-être_, la modestie de sa taille.
Toutefois, il faudrait calculer la probabilité que
deux numéros (13 chiffres) distincts (et possibles !) aient
- seulement un ou deux chiffres distincts
et
- la même clé
pour savoir si ce procédé reste "assez sûr"...
Compte tenu des règles particulières progressivement ajoutées,
je ne pense pas que ce soit trivial "à la main" ;o)
Plus de détails là :
http://alturl.com/nrkd4
cordialement,
HB
Olivier Miakinen
Aug 27, 2021, 7:20:00 PM8/27/21
to
Bonjour,
Le 27/08/2021 à 15:27, Benoit a écrit :
>
> La clef (les deux chiffres supplémentaires) du numéro de sécurité
> sociale en France est basée sur la division par 97. Le but est de
> s’assurer qu’il n’y a pas eu une erreur de saisie (une double erreur
> peut passer au travers).
>
> Quand on calcul un chiffre modulo un autre on obtient un nombre entier
> qui est le reste de la division. Pour la clef de sécu c’est
> 97 - (numéroSécu mod 97)
>
> — Pourquoi compliquer les choses ? Quel est l’intérêt de ne pas avoir un
> 00 mais un 97 ?
Mon avis est qu'utiliser un grand nombre premier réduit le nombre de
doubles erreurs possibles. Par exemple, si on avait choisi de calculer
modulo 100 au lieu de modulo 97, toute erreur sur n'importe quel
chiffre sauf les deux derniers serait impossible à détecter. Si on
avait choisi modulo 99, un grand nombre d'erreurs portant sur deux
chiffres seulement seraient également impossibles à détecter (par
exemple ajouter 1 à un chiffre et retirer 1 au chiffre deux positions
plus loin). Avec modulo 97, il y a beaucoup moins de risques d'erreurs
portant sur seulement deux chiffres.
> [...]
trois ou quatre. Je pense que 97 (le plus grand nombre premier à
deux chiffres) est le meilleur compromis entre l'économie de place
et la sécurité.
--
Olivier Miakinen
Le 27/08/2021 à 15:27, Benoit a écrit :
>
> La clef (les deux chiffres supplémentaires) du numéro de sécurité
> sociale en France est basée sur la division par 97. Le but est de
> s’assurer qu’il n’y a pas eu une erreur de saisie (une double erreur
> peut passer au travers).
>
> Quand on calcul un chiffre modulo un autre on obtient un nombre entier
> qui est le reste de la division. Pour la clef de sécu c’est
> 97 - (numéroSécu mod 97)
>
> — Pourquoi compliquer les choses ? Quel est l’intérêt de ne pas avoir un
> 00 mais un 97 ?
doubles erreurs possibles. Par exemple, si on avait choisi de calculer
modulo 100 au lieu de modulo 97, toute erreur sur n'importe quel
chiffre sauf les deux derniers serait impossible à détecter. Si on
avait choisi modulo 99, un grand nombre d'erreurs portant sur deux
chiffres seulement seraient également impossibles à détecter (par
exemple ajouter 1 à un chiffre et retirer 1 au chiffre deux positions
plus loin). Avec modulo 97, il y a beaucoup moins de risques d'erreurs
portant sur seulement deux chiffres.
> [...]
>
> 2. Pourquoi ne pas avoir pris un nombre premier de trois chiffres, voire
> 9973 ?
Ça c'est pour n'avoir à ajouter que deux chiffres au code plutôt que
> 2. Pourquoi ne pas avoir pris un nombre premier de trois chiffres, voire
> 9973 ?
trois ou quatre. Je pense que 97 (le plus grand nombre premier à
deux chiffres) est le meilleur compromis entre l'économie de place
et la sécurité.
--
Olivier Miakinen
Olivier Miakinen
Aug 27, 2021, 7:23:13 PM8/27/21
to
Le 28/08/2021 à 01:20, je répondais à Benoît :
>
> ... des choses ...
Désolé, je n'avais pas vu que tu avais déjà eu de nombreuses réponses.
--
Olivier Miakinen
>
> ... des choses ...
Désolé, je n'avais pas vu que tu avais déjà eu de nombreuses réponses.
--
Olivier Miakinen
Olivier Miakinen
Sep 3, 2021, 1:53:57 PM9/3/21
to
Bonjour,
Afin de répondre correctement et sans à priori, j'ai fait un petit
programme en python pour évaluer l'efficacité des différents nombres
pris comme modulos. Pour ce programme j'ai fait quelques hypothèses
simplificatrices, qui peuvent avoir influé sur les résultats. Je suis
preneur de tous commentaires à ce propos.
Mais j'ai été surpris !
Le 28/08/2021 11:42, Benoit me répondait :
Deuxième surprise : le meilleur compromis n'est pas un nombre premier.
> À ce propos, si je passe le nombre premier de deux chiffres à trois,
> est-ce que je suis assurément dix fois plus sûr ?
Troisième surprise : non, ce n'est pas dix fois plus sûr.
Tout d'abord mes hypothèses simplificatrices. J'ai supposé que les 13
chiffres du code INSEE avaient tous la même probabilité, indépendamment
du fait que, par exemple, le premier chiffre est le plus souvent un 1
ou un 2, plus rarement un 3, 4, 7 ou 8, et jamais un autre chiffre.
Idem pour les 4e et 5e chiffres qui sont le plus souvent entre 01 et 12.
Par ailleurs j'ai supposé aussi pour simplifier que le code de vérification
était forcément correct, les erreurs possibles étant sur les 13 premiers
chiffres.
Cela étant posé, j'ai voulu déterminer les risques qu'une erreur sur un
ou deux chiffres passe inaperçue en comptant le nombre de paires de codes
qui donnent la même clé de contrôle lorsque les deux codes de la paire
ne diffèrent que d'un ou deux chiffres.
1er cas : un seul chiffre est erroné.
Ce cas est très facile à traiter. Si le modulo est un nombre premier, ou
même un nombre non premier mais non divisible par 2 ou 5, et qu'il est
plus grand que 10, alors modifier un seul chiffre revient à ajouter ou
retirer un nombre qui ne sera jamais un multiple de ce modulo. Dans ce
cas, la clé de contrôle suffira toujours à détecter l'erreur.
2e cas : deux chiffres sont erronés.
Voici un exemple d'erreur possible : ajouter 1 à un chiffre du code INSEE
(par exemple le passer de 1 à 2 ou de 5 à 6), et simultanément ajouter 7
au chiffre qui se trouve sept rangs plus loin (par exemple le passer de 0
à 7 ou de 2 à 9). Ceci est possible parce que 100007 est un multiple de
97 (c'est 1031 fois 97). Cette erreur peut concerner 8 paires de chiffres
d'un nombre de 13 chiffres. Par ailleurs, elle peut concerner 9 valeurs
du premier chiffre (de 0 à 8) et 3 valeurs de l'autre chiffre (de 0 à 2).
L'erreur associée au nombre 100007 doit donc être comptée 216 fois car
8×9×3 = 216.
Le plus petit multiple de 97 concerné est 97 lui-même (+100 -3) compté 693
fois. Le plus grand multiple de 97 est 5 999 999 999 991 (+6.10^12 -9)
compté 4 fois. Au total, pour 97, le nombre de paires de codes donannt la
même clé s'élève à 2798. Est-ce le meilleur nombre à deux chiffres ? Non !
Parmi tous les nombres à deux chiffres (en excluant les multiples de 2 ou
de 5), il en existe un et un seul qui fait mieux que 97, et il s'agit de
93, alors seulement 2167 paires de clés indiscernables.
Peut-on faire mieux avec une clé à trois chiffres ? Oui ! Est-ce que le plus
grand nombre premier de trois chiffres (997) fait dix fois mieux que 97 ?
Pas du tout ! Il ne fait même pas trois fois mieux : 1083. Est-ce qu'on peut
quand même faire beaucoup mieux ? Oui ! Jugez plutôt. 993 fait déjà bien mieux
avec 270. 991 et 989 font encore mieux avec 90 et 81. Mais 987 fait beaucoup
plus que ça, et même infiniment mieux, avec 0 !
Eh oui, si on calculait un code modulo 987 au lieu de modulo 97, aucune erreur
sur seulement 2 chiffres ne serait indétectable. Et 987 n'est pas le seul
nombre à trois chiffres qui le permette, le plus petit est 279.
Bon, mon message est déjà très long, mais si certains sont intéressés je peux
publier mon programme ainsi que montrer quelques résultats.
Cordialement,
--
Olivier Miakinen
Afin de répondre correctement et sans à priori, j'ai fait un petit
programme en python pour évaluer l'efficacité des différents nombres
pris comme modulos. Pour ce programme j'ai fait quelques hypothèses
simplificatrices, qui peuvent avoir influé sur les résultats. Je suis
preneur de tous commentaires à ce propos.
Mais j'ai été surpris !
Le 28/08/2021 11:42, Benoit me répondait :
>>
>>> 2. Pourquoi ne pas avoir pris un nombre premier de trois chiffres, voire
>>> 9973 ?
>>
>> Ça c'est pour n'avoir à ajouter que deux chiffres au code plutôt que
>> trois ou quatre. Je pense que 97 (le plus grand nombre premier à
>> deux chiffres) est le meilleur compromis entre l'économie de place
>> et la sécurité.
Première surprise : ce n'est pas le meilleur compromis.
>>> 2. Pourquoi ne pas avoir pris un nombre premier de trois chiffres, voire
>>> 9973 ?
>>
>> Ça c'est pour n'avoir à ajouter que deux chiffres au code plutôt que
>> trois ou quatre. Je pense que 97 (le plus grand nombre premier à
>> deux chiffres) est le meilleur compromis entre l'économie de place
>> et la sécurité.
Deuxième surprise : le meilleur compromis n'est pas un nombre premier.
> À ce propos, si je passe le nombre premier de deux chiffres à trois,
> est-ce que je suis assurément dix fois plus sûr ?
Troisième surprise : non, ce n'est pas dix fois plus sûr.
Tout d'abord mes hypothèses simplificatrices. J'ai supposé que les 13
chiffres du code INSEE avaient tous la même probabilité, indépendamment
du fait que, par exemple, le premier chiffre est le plus souvent un 1
ou un 2, plus rarement un 3, 4, 7 ou 8, et jamais un autre chiffre.
Idem pour les 4e et 5e chiffres qui sont le plus souvent entre 01 et 12.
Par ailleurs j'ai supposé aussi pour simplifier que le code de vérification
était forcément correct, les erreurs possibles étant sur les 13 premiers
chiffres.
Cela étant posé, j'ai voulu déterminer les risques qu'une erreur sur un
ou deux chiffres passe inaperçue en comptant le nombre de paires de codes
qui donnent la même clé de contrôle lorsque les deux codes de la paire
ne diffèrent que d'un ou deux chiffres.
1er cas : un seul chiffre est erroné.
Ce cas est très facile à traiter. Si le modulo est un nombre premier, ou
même un nombre non premier mais non divisible par 2 ou 5, et qu'il est
plus grand que 10, alors modifier un seul chiffre revient à ajouter ou
retirer un nombre qui ne sera jamais un multiple de ce modulo. Dans ce
cas, la clé de contrôle suffira toujours à détecter l'erreur.
2e cas : deux chiffres sont erronés.
Voici un exemple d'erreur possible : ajouter 1 à un chiffre du code INSEE
(par exemple le passer de 1 à 2 ou de 5 à 6), et simultanément ajouter 7
au chiffre qui se trouve sept rangs plus loin (par exemple le passer de 0
à 7 ou de 2 à 9). Ceci est possible parce que 100007 est un multiple de
97 (c'est 1031 fois 97). Cette erreur peut concerner 8 paires de chiffres
d'un nombre de 13 chiffres. Par ailleurs, elle peut concerner 9 valeurs
du premier chiffre (de 0 à 8) et 3 valeurs de l'autre chiffre (de 0 à 2).
L'erreur associée au nombre 100007 doit donc être comptée 216 fois car
8×9×3 = 216.
Le plus petit multiple de 97 concerné est 97 lui-même (+100 -3) compté 693
fois. Le plus grand multiple de 97 est 5 999 999 999 991 (+6.10^12 -9)
compté 4 fois. Au total, pour 97, le nombre de paires de codes donannt la
même clé s'élève à 2798. Est-ce le meilleur nombre à deux chiffres ? Non !
Parmi tous les nombres à deux chiffres (en excluant les multiples de 2 ou
de 5), il en existe un et un seul qui fait mieux que 97, et il s'agit de
93, alors seulement 2167 paires de clés indiscernables.
Peut-on faire mieux avec une clé à trois chiffres ? Oui ! Est-ce que le plus
grand nombre premier de trois chiffres (997) fait dix fois mieux que 97 ?
Pas du tout ! Il ne fait même pas trois fois mieux : 1083. Est-ce qu'on peut
quand même faire beaucoup mieux ? Oui ! Jugez plutôt. 993 fait déjà bien mieux
avec 270. 991 et 989 font encore mieux avec 90 et 81. Mais 987 fait beaucoup
plus que ça, et même infiniment mieux, avec 0 !
Eh oui, si on calculait un code modulo 987 au lieu de modulo 97, aucune erreur
sur seulement 2 chiffres ne serait indétectable. Et 987 n'est pas le seul
nombre à trois chiffres qui le permette, le plus petit est 279.
Bon, mon message est déjà très long, mais si certains sont intéressés je peux
publier mon programme ainsi que montrer quelques résultats.
Cordialement,
--
Olivier Miakinen
Olivier Miakinen
Sep 3, 2021, 1:59:06 PM9/3/21
to
[Supersedes pour corriger une erreur, j'espère que c'est la seule]
Bonjour,
Afin de répondre correctement et sans à priori, j'ai fait un petit
programme en python pour évaluer l'efficacité des différents nombres
pris comme modulos. Pour ce programme j'ai fait quelques hypothèses
simplificatrices, qui peuvent avoir influé sur les résultats. Je suis
preneur de tous commentaires à ce propos.
Mais j'ai été surpris !
Le 28/08/2021 11:42, Benoit me répondait :
>>
au chiffre qui se trouve cinq rangs plus loin (par exemple le passer de 0
Bonjour,
Afin de répondre correctement et sans à priori, j'ai fait un petit
programme en python pour évaluer l'efficacité des différents nombres
pris comme modulos. Pour ce programme j'ai fait quelques hypothèses
simplificatrices, qui peuvent avoir influé sur les résultats. Je suis
preneur de tous commentaires à ce propos.
Mais j'ai été surpris !
Le 28/08/2021 11:42, Benoit me répondait :
>>
>>> 2. Pourquoi ne pas avoir pris un nombre premier de trois chiffres, voire
>>> 9973 ?
>>
>> Ça c'est pour n'avoir à ajouter que deux chiffres au code plutôt que
>> trois ou quatre. Je pense que 97 (le plus grand nombre premier à
>> deux chiffres) est le meilleur compromis entre l'économie de place
>> et la sécurité.
>>> 9973 ?
>>
>> Ça c'est pour n'avoir à ajouter que deux chiffres au code plutôt que
>> trois ou quatre. Je pense que 97 (le plus grand nombre premier à
>> deux chiffres) est le meilleur compromis entre l'économie de place
>> et la sécurité.
Olivier Miakinen
Sep 3, 2021, 2:03:24 PM9/3/21
to
Le 03/09/2021 19:59, Olivier Miakinen a écrit :
> [Supersedes pour corriger une erreur, j'espère que c'est la seule]
J'en ai vu au moins une autre : le mot « alors » mis à la place du mot
> [Supersedes pour corriger une erreur, j'espère que c'est la seule]
« avec », mais je ne corrige plus, on va dire que c'est compréhensible
comme ça.
--
Olivier Miakinen
Olivier Miakinen
Sep 4, 2021, 2:34:44 AM9/4/21
to
Le 04/09/2021 01:46, Benoit a écrit :
>
>> 2e cas : deux chiffres sont erronés.
>>
>> Voici un exemple d'erreur possible : ajouter 1 à un chiffre du code INSEE
>> (par exemple le passer de 1 à 2 ou de 5 à 6), et simultanément ajouter 7
>> au chiffre qui se trouve cinq rangs plus loin (par exemple le passer de 0
>> à 7 ou de 2 à 9). Ceci est possible parce que 100007 est un multiple de
>> 97 (c'est 1031 fois 97). Cette erreur peut concerner 8 paires de chiffres
>> d'un nombre de 13 chiffres. Par ailleurs, elle peut concerner 9 valeurs
>> du premier chiffre (de 0 à 8) et 3 valeurs de l'autre chiffre (de 0 à 2).
>> L'erreur associée au nombre 100007 doit donc être comptée 216 fois car
>> 8×9×3 = 216.
>
> N’y a-t-il pas :
>
>> 2e cas : deux chiffres sont erronés.
>>
>> Voici un exemple d'erreur possible : ajouter 1 à un chiffre du code INSEE
>> (par exemple le passer de 1 à 2 ou de 5 à 6), et simultanément ajouter 7
>> au chiffre qui se trouve cinq rangs plus loin (par exemple le passer de 0
>> à 7 ou de 2 à 9). Ceci est possible parce que 100007 est un multiple de
>> 97 (c'est 1031 fois 97). Cette erreur peut concerner 8 paires de chiffres
>> d'un nombre de 13 chiffres. Par ailleurs, elle peut concerner 9 valeurs
>> du premier chiffre (de 0 à 8) et 3 valeurs de l'autre chiffre (de 0 à 2).
>> L'erreur associée au nombre 100007 doit donc être comptée 216 fois car
>> 8×9×3 = 216.
>
>
> — 3 007 : 97 x 31 ==> 10 x 7 x 3 = 210 erreurs
> — 7 000 005 : 97 x 72 165 ==> 7 x 3 x 5 = 105 erreurs
> - 50 000 008 : 97 x 515464 ==> 6 X 5 X 2 = 60 erreurs
Oui. Bien vu, et bien calculé. Outre 100 007, les nombres 3 007, 7 000 005
et 50 000 008 sont les seuls pour lesquels le changement de deux chiffres
*dans le même sens* est une erreur indétectable. Et tu as bien calculé le
nombre de possibilités pour chaque.
Mais il ne faut pas oublier que l'on peut aussi *augmenter* un chiffre tout
en *diminuant* un autre chiffre. Cela veut dire qu'en plus de chercher les
multiples de 97 de la forme (d1 × 10^n + d2) il faut aussi considérer ceux
de la forme (d1 × 10^n - d2).
Voir la liste (sortie de mon programme) en fin de cet article.
> 375 erreurs potentielles. Pas beaucoup, mais pour une fois c’est mieux
> d’avoir un 0 en maths :)
:-D
> Puis 60 000 000 000 007 mais 14 chiffres et je ne sais aller au-delà
> avec mon bon vieil Excel.
J'aurais pu aller plus loin avec Python, mais je me suis arrêté aux 13
chiffres du numéro de sécurité sociale.
> [...]
>
> Pour les numéros de cartes bancaires c’est la Formule de Luhn qui est
> utilisée, mais là je ne sais pas comment calculer pour le problème
> énoncé ci-dessus. Si le résultat doit être un multiple de 10 je ne vois
> pas comment cela peut être plus sûr.
>
> <https://fr.wikipedia.org/wiki/Formule_de_Luhn>
Merci, je vais aller lire ça.
Maintenant la sortie de mon programme pour le modulo 97 dans un code à
13 chiffres :
========================================
$ code_correcteur.py 97
97 ←11→ +1 -3
11×9×7 = 693
194 ←11→ +2 -6
11×8×4 = 352
291 ←11→ +3 -9
11×7×1 = 77
3007 ←10→ +3 +7
10×7×3 = 210
9991 ←9→ +1 -9
9×9×1 = 81
100007 ←8→ +1 +7
8×9×3 = 216
7000005 ←7→ +7 +5
7×3×5 = 105
50000008 ←6→ +5 +8
6×5×2 = 60
89999995 ←6→ +9 -5
6×1×5 = 30
599999999 ←5→ +6 -1
5×4×9 = 180
2999999995 ←4→ +3 -5
4×7×5 = 140
19999999999 ←3→ +2 -1
3×8×9 = 216
39999999998 ←3→ +4 -2
3×6×8 = 144
59999999997 ←3→ +6 -3
3×4×7 = 84
79999999996 ←3→ +8 -4
3×2×6 = 36
99999999995 ←2→ +1 -5
2×9×5 = 90
1999999999997 ←1→ +2 -3
1×8×7 = 56
3999999999994 ←1→ +4 -6
1×6×4 = 24
5999999999991 ←1→ +6 -9
1×4×1 = 4
Total pour 97 = 2798
========================================
Tant que j'y suis, le résultat pour 93 :
========================================
$ code_correcteur.py 93
93 ←11→ +1 -7
11×9×3 = 297
3999 ←10→ +4 -1
10×6×9 = 540
7998 ←10→ +8 -2
10×2×8 = 160
19995 ←9→ +2 -5
9×8×5 = 360
399993 ←8→ +4 -7
8×6×3 = 144
2999994 ←7→ +3 -6
7×7×4 = 196
79999995 ←6→ +8 -5
6×2×5 = 60
90000006 ←6→ +9 +6
6×1×4 = 24
499999992 ←5→ +5 -8
5×5×2 = 50
600000009 ←5→ +6 +9
5×4×1 = 20
5999999997 ←4→ +6 -3
4×4×7 = 112
69999999996 ←3→ +7 -4
3×3×6 = 54
499999999998 ←2→ +5 -2
2×5×8 = 80
999999999996 ←1→ +1 -4
1×9×6 = 54
1999999999992 ←1→ +2 -8
1×8×2 = 16
Total pour 93 = 2167
========================================
Et les résultats non détaillés (juste le total) pour tous les nombres à
deux chiffres qui sont premiers avec 10 :
========================================
$ code_correcteur.py 10 99
Total pour 11 = 15786
Total pour 13 = 17330
Total pour 17 = 15973
Total pour 19 = 14645
Total pour 21 = 13398
Total pour 23 = 11750
Total pour 27 = 12342
Total pour 29 = 8928
Total pour 31 = 8316
Total pour 33 = 13320
Total pour 37 = 10186
Total pour 39 = 7220
Total pour 41 = 7436
Total pour 43 = 5716
Total pour 47 = 5296
Total pour 49 = 5487
Total pour 51 = 5130
Total pour 53 = 4168
Total pour 57 = 4371
Total pour 59 = 4920
Total pour 61 = 3499
Total pour 63 = 4608
Total pour 67 = 4457
Total pour 69 = 3918
Total pour 71 = 3441
Total pour 73 = 5673
Total pour 77 = 7282
Total pour 79 = 2491
Total pour 81 = 3494
Total pour 83 = 2863
Total pour 87 = 3541
Total pour 89 = 2669
Total pour 91 = 6666
Total pour 93 = 2167
Total pour 97 = 2798
Total pour 99 = 10290
Meilleur total : 2167 pour 93
========================================
Cordialement,
--
Olivier Miakinen
Olivier Miakinen
Sep 4, 2021, 6:09:11 AM9/4/21
to
Le 04/09/2021 11:40, Benoit a écrit :
>>>
>>> N’y a-t-il pas :
>>>
>>> — 3 007 : 97 x 31 ==> 10 x 7 x 3 = 210 erreurs
>>> — 7 000 005 : 97 x 72 165 ==> 7 x 3 x 5 = 105 erreurs
>>> - 50 000 008 : 97 x 515464 ==> 6 X 5 X 2 = 60 erreurs
>>
>> Oui. Bien vu, et bien calculé. Outre 100 007, les nombres 3 007, 7 000 005
>> et 50 000 008 sont les seuls pour lesquels le changement de deux chiffres
>> *dans le même sens* est une erreur indétectable. Et tu as bien calculé le
>> nombre de possibilités pour chaque.
>>
>> Mais il ne faut pas oublier que l'on peut aussi *augmenter* un chiffre tout
>> en *diminuant* un autre chiffre. Cela veut dire qu'en plus de chercher les
>> multiples de 97 de la forme (d1 × 10^n + d2) il faut aussi considérer ceux
>> de la forme (d1 × 10^n - d2).
>
> Et pourquoi ne pourrait-on pas diminuer les deux ? Ou, plus simplement,
>>>
>>> N’y a-t-il pas :
>>>
>>> — 3 007 : 97 x 31 ==> 10 x 7 x 3 = 210 erreurs
>>> — 7 000 005 : 97 x 72 165 ==> 7 x 3 x 5 = 105 erreurs
>>> - 50 000 008 : 97 x 515464 ==> 6 X 5 X 2 = 60 erreurs
>>
>> Oui. Bien vu, et bien calculé. Outre 100 007, les nombres 3 007, 7 000 005
>> et 50 000 008 sont les seuls pour lesquels le changement de deux chiffres
>> *dans le même sens* est une erreur indétectable. Et tu as bien calculé le
>> nombre de possibilités pour chaque.
>>
>> Mais il ne faut pas oublier que l'on peut aussi *augmenter* un chiffre tout
>> en *diminuant* un autre chiffre. Cela veut dire qu'en plus de chercher les
>> multiples de 97 de la forme (d1 × 10^n + d2) il faut aussi considérer ceux
>> de la forme (d1 × 10^n - d2).
>
> faire les quatre possibilités ++, +-, -+ ou --.
On peut très bien le faire, ce qui te donnera exactement deux fois plus de
résultats puisque à chaque nombre que l'on peut augmenter correspond le
nombre que l'on peut diminuer. En choisissant le sens de modification
d'un des deux chiffres et en laissant libre le sens de l'autre chiffre
(donc ++ et +- mais pas -+ ni --) je compte les « paires de nombres
indiscernables » plutôt que les « nombres faisant partie d'une paire ».
> [...]
>
>> Et les résultats non détaillés (juste le total) pour tous les nombres à
>> deux chiffres qui sont premiers avec 10 :
>> ========================================
>> $ code_correcteur.py 10 99
>> […]
>> Et les résultats non détaillés (juste le total) pour tous les nombres à
>> deux chiffres qui sont premiers avec 10 :
>> ========================================
>> $ code_correcteur.py 10 99
>> Meilleur total : 2167 pour 93
>> ========================================
>
> Là je n’ai franchement pas les outils adéquats. Quoique réalisable, mais
>> ========================================
>
> long à mettre en place.
Mon programme python :
========================================================================
#!/usr/bin/env python3
import sys
def calcule_pour(modulo, verbose):
somme = 0
for n in range(2, 13):
mul = 10 ** n
# d1 est le premier chiffre, entre 1 et 9
for d1 in range (1, 10):
nombre = d1 * mul + 9
resid = nombre % modulo
if resid <= 18:
nombre = nombre - resid
# d2 est compris entre -9 et -1 ou entre 1 et 9
d2 = 9 - resid
positions = 13 - n
if verbose:
print(f"{nombre} ←{positions}→ {d1:+d} {d2:+d}")
# var1 et var2 sont les comptes de chiffres possibles
# à la position de d1 et d2
var1 = 10 - d1
var2 = 10 - abs(d2)
compte = positions * var1 * var2
if verbose:
print(f" {positions}×{var1}×{var2} = {compte}")
somme += compte
print("Total pour", modulo, "=", somme)
return somme
if len(sys.argv) == 2:
modulo = int(sys.argv[1])
calcule_pour(modulo, True)
if len(sys.argv) == 3:
min = -1
best = 0
first = int(sys.argv[1])
last = int(sys.argv[2])
for modulo in range(first,last+1):
if modulo % 2 != 0 and modulo % 5 != 0:
somme = calcule_pour(modulo, False)
if min < 0 or somme < min:
min = somme
best = modulo
print("Meilleur total :", min, "pour", best)
========================================================================
--
Olivier Miakinen
Olivier Miakinen
Sep 4, 2021, 7:10:32 AM9/4/21
to
Le 04/09/2021 01:46, Benoit a écrit :
>
> Pour les numéros de cartes bancaires c’est la Formule de Luhn qui est
> utilisée, mais là je ne sais pas comment calculer pour le problème
> énoncé ci-dessus. Si le résultat doit être un multiple de 10 je ne vois
> pas comment cela peut être plus sûr.
>
> <https://fr.wikipedia.org/wiki/Formule_de_Luhn>
Ok, j'ai vu, j'ai lu, j'ai comprenu. ;-)
>
> Pour les numéros de cartes bancaires c’est la Formule de Luhn qui est
> utilisée, mais là je ne sais pas comment calculer pour le problème
> énoncé ci-dessus. Si le résultat doit être un multiple de 10 je ne vois
> pas comment cela peut être plus sûr.
>
> <https://fr.wikipedia.org/wiki/Formule_de_Luhn>
Ce code est moins sûr que le modulo par 97.
En effet :
1) il détecte parfaitement la modification d'un seul chiffre, ce
que fait aussi le modulo 97
2) il détecte (presque) parfaitement l'échange de deux chiffres qui
se suivent, le « presque » étant qu'il ne détectera pas l'échange
de 09 en 90 ou réciproquement, alors que le modulo 97 détectera
tout échange de deux chiffres qui se suivent
Mais :
3) il ne détecte pas l'échange de deux chiffres qui sont tous deux à
un rang pair ou tous les deux à un rang impair, alors que le modulo
97 le détectera toujours (je n'en ai pas parlé mais dans ma liste
pour le nombre 97 il faudrait voir un « +1 -1 » quelque part pour
que ce ne soit pas détecté)
4) il y a une multitude d'autres cas dans lesquels deux chiffres sont
modifiés au lieu d'être simplement échangés, cas que cet algorithme
ne détecte pas alors qu'ils sont le plus souvent détectés par le
modulo 97
Cela dit ne lui jetons pas la pierre, il n'est pas étonnant qu'un code
correcteur à un seul chiffre soit moins performant qu'un à deux chiffres.
Cordialement,
--
Olivier Miakinen
Olivier Miakinen
Sep 4, 2021, 7:21:49 AM9/4/21
to
Une petite précision...
Le 04/09/2021 13:10, Olivier Miakinen a écrit :
>
> 3) il ne détecte pas l'échange de deux chiffres qui sont tous deux à
> un rang pair ou tous les deux à un rang impair, alors que le modulo
> 97 le détectera toujours (je n'en ai pas parlé mais dans ma liste
> pour le nombre 97 il faudrait voir un « +1 -1 » quelque part pour
> que ce ne soit pas détecté)
Le modulo 93 n'a pas non plus ce défaut quel que soit l'écart entre les
rangs des deux chiffres, mais d'autres modulos tels que 27 ou 37 l'ont.
En effet, 27 * 37 = 999, ce qui veut dire que l'échange de deux chiffres
dont les rangs sont séparés d'un multiple de 3 ne sera pas détecté.
--
Olivier Miakinen
Le 04/09/2021 13:10, Olivier Miakinen a écrit :
>
> 3) il ne détecte pas l'échange de deux chiffres qui sont tous deux à
> un rang pair ou tous les deux à un rang impair, alors que le modulo
> 97 le détectera toujours (je n'en ai pas parlé mais dans ma liste
> pour le nombre 97 il faudrait voir un « +1 -1 » quelque part pour
> que ce ne soit pas détecté)
rangs des deux chiffres, mais d'autres modulos tels que 27 ou 37 l'ont.
En effet, 27 * 37 = 999, ce qui veut dire que l'échange de deux chiffres
dont les rangs sont séparés d'un multiple de 3 ne sera pas détecté.
--
Olivier Miakinen
Olivier Miakinen
Sep 5, 2021, 5:47:30 AM9/5/21
to
Le 04/09/2021 12:09, j'écrivais :
J'ai fait une erreur ici, il faudrait commencer à 1 au lieu de 2.
Ce nombre désigne la distance entre les deux chiffres modifiés, mais
lorsque j'ai lancé mon programme pour la première fois j'ai cru qu'il
était bugué en comptant deux fois le nombre 97 :
===================
97 ←12→ +9 +7
12×1×3 = 36
En réalité il est normal que le 97 apparaisse deux fois : une fois pour
modifier deux chiffres côté à côte, par exemple 01←→98 ; une autre fois
pour deux chiffres séparés d'un troisième, par exemple 153←→250.
Au finale, cela ajoute 36 paires pour 97 et 84 paires pour 93, mais c'est
quand même 93 qui reste le meilleur choix de modulo.
--
Olivier Miakinen
>
> Mon programme python :
> ========================================================================
> #!/usr/bin/env python3
>
> import sys
>
> def calcule_pour(modulo, verbose):
> somme = 0
> for n in range(2, 13):
^^^
> Mon programme python :
> ========================================================================
> #!/usr/bin/env python3
>
> import sys
>
> def calcule_pour(modulo, verbose):
> somme = 0
> for n in range(2, 13):
J'ai fait une erreur ici, il faudrait commencer à 1 au lieu de 2.
Ce nombre désigne la distance entre les deux chiffres modifiés, mais
lorsque j'ai lancé mon programme pour la première fois j'ai cru qu'il
était bugué en comptant deux fois le nombre 97 :
===================
97 ←12→ +9 +7
12×1×3 = 36
97 ←11→ +1 -3
11×9×7 = 693
===================
11×9×7 = 693
En réalité il est normal que le 97 apparaisse deux fois : une fois pour
modifier deux chiffres côté à côte, par exemple 01←→98 ; une autre fois
pour deux chiffres séparés d'un troisième, par exemple 153←→250.
Au finale, cela ajoute 36 paires pour 97 et 84 paires pour 93, mais c'est
quand même 93 qui reste le meilleur choix de modulo.
--
Olivier Miakinen
Olivier Miakinen
Sep 7, 2021, 4:57:13 AM9/7/21
to
Le 06/09/2021 à 22:26, Benoit m'a répondu :
C'est ça.
De plus :
- à chaque nombre auquel tu peux ajouter un multiple de 97 correspond
un nombre auquel tu peux soustraire le même multiple de 97 (pour
donner le nombre de départ) ;
- à chaque nombre auquel tu peux soustraire un multiple de 97 correspond
un nombre auquel tu peux ajouter le même multiple de 97 (pour donner
le nombre de départ) ;
- ces nombres vont donc par paires, avec dans chaque paire :
- un nombre plus petit auquel tu peux ajouter un multiple de 97 ;
- un nombre plus grand duquel tu peux soustraire un multiple de 97.
Du coup, soit tu comptes individuellement tous les nombres, petits et
grands, soit tu comptes toutes les paires de nombres. J'ai fait le choix
de compter les paires.
>> En choisissant le sens de modification
>> d'un des deux chiffres et en laissant libre le sens de l'autre chiffre
>> (donc ++ et +- mais pas -+ ni --) je compte les « paires de nombres
>> indiscernables » plutôt que les « nombres faisant partie d'une paire ».
>> […]
>
> Il faut que je dorme là-dessus.
>
> J’ai dormi :)
>
> Voici ce que je trouve en prenant 3007. Je peux ajouter de 0 à 7 pour le
> 3 et 0 à 3 pour le 7 (21 cas). Je peux aussi sous-traire O->3 pour le 3
> et 0->7 pour le 7 (à nouveau 21 cas). J’en ai donc deux fois plus et ce
> ne sont pas 21 mais 42. On a donc pour 3007 :
> 10 x 7 x 3 x 2 = 420 erreurs et non 210.
Et donc, tu as choisi de compter les nombres individuellement plutôt que
les paires de nombres. Sans surprise tu obtiens un résultat double du
mien puisque dans chaque paire il y a deux nombres.
> Une remarque : les trois derniers chiffres du N° de S.C. ne peuvent être
> 000, donc un numéro terminant par 007 ne peut pas être dans la liste des
> résultats de l’addition et un numéro finissant par 007 ne peut être
> utilisé pour la soustraction. Cela fait donc 418 erreurs possibles.
>
> Non ?
Ça fait partie de mes hypothèses simplificatrices :
<news:sgtnp9$2n5o$1...@cabale.usenet-fr.net>
§
Si tu voulais vraiment tenir compte de la répartition possible des trois
derniers chiffres il faudrait faire une statistique sur la fréquence de
chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
plus fréquent que le nombre 999.
--
Olivier Miakinen
>
>> On peut très bien le faire, ce qui te donnera exactement deux fois plus de
>> résultats puisque à chaque nombre que l'on peut augmenter correspond le
>> nombre que l'on peut diminuer.
>
> Ok, je peux ajouter ou soustraire un multiple de 97.
>> On peut très bien le faire, ce qui te donnera exactement deux fois plus de
>> résultats puisque à chaque nombre que l'on peut augmenter correspond le
>> nombre que l'on peut diminuer.
>
C'est ça.
De plus :
- à chaque nombre auquel tu peux ajouter un multiple de 97 correspond
un nombre auquel tu peux soustraire le même multiple de 97 (pour
donner le nombre de départ) ;
- à chaque nombre auquel tu peux soustraire un multiple de 97 correspond
un nombre auquel tu peux ajouter le même multiple de 97 (pour donner
le nombre de départ) ;
- ces nombres vont donc par paires, avec dans chaque paire :
- un nombre plus petit auquel tu peux ajouter un multiple de 97 ;
- un nombre plus grand duquel tu peux soustraire un multiple de 97.
Du coup, soit tu comptes individuellement tous les nombres, petits et
grands, soit tu comptes toutes les paires de nombres. J'ai fait le choix
de compter les paires.
>> En choisissant le sens de modification
>> d'un des deux chiffres et en laissant libre le sens de l'autre chiffre
>> (donc ++ et +- mais pas -+ ni --) je compte les « paires de nombres
>> indiscernables » plutôt que les « nombres faisant partie d'une paire ».
>
> Il faut que je dorme là-dessus.
>
> J’ai dormi :)
>
> Voici ce que je trouve en prenant 3007. Je peux ajouter de 0 à 7 pour le
> 3 et 0 à 3 pour le 7 (21 cas). Je peux aussi sous-traire O->3 pour le 3
> et 0->7 pour le 7 (à nouveau 21 cas). J’en ai donc deux fois plus et ce
> ne sont pas 21 mais 42. On a donc pour 3007 :
> 10 x 7 x 3 x 2 = 420 erreurs et non 210.
Et donc, tu as choisi de compter les nombres individuellement plutôt que
les paires de nombres. Sans surprise tu obtiens un résultat double du
mien puisque dans chaque paire il y a deux nombres.
> Une remarque : les trois derniers chiffres du N° de S.C. ne peuvent être
> 000, donc un numéro terminant par 007 ne peut pas être dans la liste des
> résultats de l’addition et un numéro finissant par 007 ne peut être
> utilisé pour la soustraction. Cela fait donc 418 erreurs possibles.
>
> Non ?
Ça fait partie de mes hypothèses simplificatrices :
<news:sgtnp9$2n5o$1...@cabale.usenet-fr.net>
§
> Tout d'abord mes hypothèses simplificatrices. J'ai supposé que les 13
> chiffres du code INSEE avaient tous la même probabilité, indépendamment
> du fait que, par exemple, le premier chiffre est le plus souvent un 1
> ou un 2, plus rarement un 3, 4, 7 ou 8, et jamais un autre chiffre.
> Idem pour les 4e et 5e chiffres qui sont le plus souvent entre 01 et 12.
> Par ailleurs j'ai supposé aussi pour simplifier que le code de vérification
> était forcément correct, les erreurs possibles étant sur les 13 premiers
> chiffres.
§
> chiffres du code INSEE avaient tous la même probabilité, indépendamment
> du fait que, par exemple, le premier chiffre est le plus souvent un 1
> ou un 2, plus rarement un 3, 4, 7 ou 8, et jamais un autre chiffre.
> Idem pour les 4e et 5e chiffres qui sont le plus souvent entre 01 et 12.
> Par ailleurs j'ai supposé aussi pour simplifier que le code de vérification
> était forcément correct, les erreurs possibles étant sur les 13 premiers
> chiffres.
Si tu voulais vraiment tenir compte de la répartition possible des trois
derniers chiffres il faudrait faire une statistique sur la fréquence de
chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
plus fréquent que le nombre 999.
--
Olivier Miakinen
Jacques Mathon
Sep 7, 2021, 7:54:55 AM9/7/21
to
Le 07/09/2021 à 10:57, Olivier Miakinen a écrit :
> Le 06/09/2021 à 22:26, Benoit m'a répondu :
>>
[...]
> Le 06/09/2021 à 22:26, Benoit m'a répondu :
>>
>> Tout d'abord mes hypothèses simplificatrices. J'ai supposé que les 13
>> chiffres du code INSEE avaient tous la même probabilité, indépendamment
>> du fait que, par exemple, le premier chiffre est le plus souvent un 1
>> ou un 2, plus rarement un 3, 4, 7 ou 8, et jamais un autre chiffre.
>> Idem pour les 4e et 5e chiffres qui sont le plus souvent entre 01 et 12.
>> Par ailleurs j'ai supposé aussi pour simplifier que le code de vérification
>> était forcément correct, les erreurs possibles étant sur les 13 premiers
>> chiffres.
> §
>
> Si tu voulais vraiment tenir compte de la répartition possible des trois
> derniers chiffres il faudrait faire une statistique sur la fréquence de
> chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
> plus fréquent que le nombre 999.
Voir la loi de Benford
>> chiffres du code INSEE avaient tous la même probabilité, indépendamment
>> du fait que, par exemple, le premier chiffre est le plus souvent un 1
>> ou un 2, plus rarement un 3, 4, 7 ou 8, et jamais un autre chiffre.
>> Idem pour les 4e et 5e chiffres qui sont le plus souvent entre 01 et 12.
>> Par ailleurs j'ai supposé aussi pour simplifier que le code de vérification
>> était forcément correct, les erreurs possibles étant sur les 13 premiers
>> chiffres.
> §
>
> Si tu voulais vraiment tenir compte de la répartition possible des trois
> derniers chiffres il faudrait faire une statistique sur la fréquence de
> chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
> plus fréquent que le nombre 999.
https://fr.wikipedia.org/wiki/Loi_de_Benford
Amicalement
--
Jacques
Olivier Miakinen
Sep 7, 2021, 8:11:54 AM9/7/21
to
Le 07/09/2021 à 13:54, Jacques Mathon a écrit :
>>
>> Si tu voulais vraiment tenir compte de la répartition possible des trois
>> derniers chiffres il faudrait faire une statistique sur la fréquence de
>> chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
>> plus fréquent que le nombre 999.
>
> Voir la loi de Benford
> https://fr.wikipedia.org/wiki/Loi_de_Benford
Ah non, je suis désolé mais elle ne s'applique pas dans ce cas puisque
>>
>> Si tu voulais vraiment tenir compte de la répartition possible des trois
>> derniers chiffres il faudrait faire une statistique sur la fréquence de
>> chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
>> plus fréquent que le nombre 999.
>
> Voir la loi de Benford
> https://fr.wikipedia.org/wiki/Loi_de_Benford
les nombres ne couvrent pas uniformément plusieurs ordres de grandeur.
D'ailleurs dans la loi de Benford aucun nombre ne commence par un 0,
alors qu'au contraire il y en a beaucoup comme 11e chiffre du numéro
de sécurité sociale.
En outre, le problème ne concerne pas que ces 11e, 12e et 13e chiffres,
mais aussi comme je le disais le premier chiffre (qui peut être 1 ou 8
mais pas 6), les 4e et 5e chiffres (qui peuvent être 12, 42 ou 99 mais
pas 17 ou 45), et ainsi de suite.
<https://fr.wikipedia.org/wiki/Num%C3%A9ro_de_s%C3%A9curit%C3%A9_sociale_en_France>
--
Olivier Miakinen
Jacques Mathon
Sep 7, 2021, 11:50:41 AM9/7/21
to
Le 07/09/2021 à 14:11, Olivier Miakinen a écrit :
> Le 07/09/2021 à 13:54, Jacques Mathon a écrit :
>>>
>>> Si tu voulais vraiment tenir compte de la répartition possible des trois
>>> derniers chiffres il faudrait faire une statistique sur la fréquence de
>>> chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
>>> plus fréquent que le nombre 999.
>>
>> Voir la loi de Benford
>> https://fr.wikipedia.org/wiki/Loi_de_Benford
>
> Ah non, je suis désolé mais elle ne s'applique pas dans ce cas puisque
> les nombres ne couvrent pas uniformément plusieurs ordres de grandeur.
> D'ailleurs dans la loi de Benford aucun nombre ne commence par un 0,
> alors qu'au contraire il y en a beaucoup comme 11e chiffre du numéro
> de sécurité sociale.
Je faisais juste allusion à une loi qui, tenant compte d'un type de
> Le 07/09/2021 à 13:54, Jacques Mathon a écrit :
>>>
>>> Si tu voulais vraiment tenir compte de la répartition possible des trois
>>> derniers chiffres il faudrait faire une statistique sur la fréquence de
>>> chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
>>> plus fréquent que le nombre 999.
>>
>> Voir la loi de Benford
>> https://fr.wikipedia.org/wiki/Loi_de_Benford
>
> Ah non, je suis désolé mais elle ne s'applique pas dans ce cas puisque
> les nombres ne couvrent pas uniformément plusieurs ordres de grandeur.
> D'ailleurs dans la loi de Benford aucun nombre ne commence par un 0,
> alors qu'au contraire il y en a beaucoup comme 11e chiffre du numéro
> de sécurité sociale.
répartition permet d'avoir une idée de la fréquence d'apparition des
chiffres. Dans mon souvenir, elle permet (je n'ai pas vérifié) d'inférer
qu'un jeu de données est "bidonné".
En faisant une petite requête avec mon moteur de recherche, je tombe sur
un article de Jean-Paul Delahaye dans "Pour la science" qui, justement,
en parle.
http://cristal.univ-lille.fr/~jdelahay/pls/152.pdf
Sauf erreur de ma part, il conviendrait de l'ajuster pour tenir compte
de la présence des zéros non significatifs. Cela dit, je ne suis pas sûr
d'avoir compris ce que tu voulais dire par "couvrir uniformément
plusieurs ordres de grandeur". Dans mon souvenir les trois derniers
chiffres d'un numéro de SS correspondent à un numéro d'ordre.
> En outre, le problème ne concerne pas que ces 11e, 12e et 13e chiffres,
> mais aussi comme je le disais le premier chiffre (qui peut être 1 ou 8
> mais pas 6), les 4e et 5e chiffres (qui peuvent être 12, 42 ou 99 mais
> pas 17 ou 45), et ainsi de suite.
>
> <https://fr.wikipedia.org/wiki/Num%C3%A9ro_de_s%C3%A9curit%C3%A9_sociale_en_France>
Amicalement
--
Jacques
Olivier Miakinen
Sep 7, 2021, 5:09:42 PM9/7/21
to
Le 07/09/2021 17:50, Jacques Mathon a écrit :
>>>
>>> Voir la loi de Benford
>>> https://fr.wikipedia.org/wiki/Loi_de_Benford
>>
>> Ah non, je suis désolé mais elle ne s'applique pas dans ce cas puisque
>> les nombres ne couvrent pas uniformément plusieurs ordres de grandeur.
>> D'ailleurs dans la loi de Benford aucun nombre ne commence par un 0,
>> alors qu'au contraire il y en a beaucoup comme 11e chiffre du numéro
>> de sécurité sociale.
>
> Je faisais juste allusion à une loi qui, tenant compte d'un type de
> répartition permet d'avoir une idée de la fréquence d'apparition des
> chiffres. Dans mon souvenir, elle permet (je n'ai pas vérifié) d'inférer
> qu'un jeu de données est "bidonné".
> En faisant une petite requête avec mon moteur de recherche, je tombe sur
> un article de Jean-Paul Delahaye dans "Pour la science" qui, justement,
> en parle.
> http://cristal.univ-lille.fr/~jdelahay/pls/152.pdf
Aussi bien la page de Wikipédia que l'article de Delahaye me semblent
>>>
>>> Voir la loi de Benford
>>> https://fr.wikipedia.org/wiki/Loi_de_Benford
>>
>> Ah non, je suis désolé mais elle ne s'applique pas dans ce cas puisque
>> les nombres ne couvrent pas uniformément plusieurs ordres de grandeur.
>> D'ailleurs dans la loi de Benford aucun nombre ne commence par un 0,
>> alors qu'au contraire il y en a beaucoup comme 11e chiffre du numéro
>> de sécurité sociale.
>
> Je faisais juste allusion à une loi qui, tenant compte d'un type de
> répartition permet d'avoir une idée de la fréquence d'apparition des
> chiffres. Dans mon souvenir, elle permet (je n'ai pas vérifié) d'inférer
> qu'un jeu de données est "bidonné".
> En faisant une petite requête avec mon moteur de recherche, je tombe sur
> un article de Jean-Paul Delahaye dans "Pour la science" qui, justement,
> en parle.
> http://cristal.univ-lille.fr/~jdelahay/pls/152.pdf
assez explicites sur ce qu'est cette loi, et ses limites.
> Sauf erreur de ma part, il conviendrait de l'ajuster pour tenir compte
> de la présence des zéros non significatifs.
trois chiffres, qui est un index dont tous les nombres entre 1 et le
max de la période sont attribués.
> Cela dit, je ne suis pas sûr
> d'avoir compris ce que tu voulais dire par "couvrir uniformément
> plusieurs ordres de grandeur".
1) Le nombre d'habitants de toutes les communes françaises.
Ce nombre va de 1 (Rochefourchat dans la Drôme en 2009) jusqu'à
plus de 2 000 000 (Paris). Il couvre donc 7 ordres de grandeur, et
il ne fait aucun doute que ces nombres suivent la loi de Benford.
2) Le nombre d'habitants des communes du Val-de-Marne.
Ce nombre va de 2 604 (Périgny) à 92 531 (Vitry-sur-Seine). Il ne
couvre que deux ordres de grandeur, et bien qu'il s'agisse du même
genre de données que l'exemple précédent je suis prêt à parier
qu'ils ne suivent pas la loi de Benford.
Un autre exemple est donné dans les deux liens que tu as cités, et
concerne la taille des individus lorsqu'elle est exprimée dans le
système métrique.
Soit dit en passant, lorsqu'un ensemble de données suit la loi de
Benford, changer le système de mesure (par exemple tout diviser par
2,54 pour passer de centimètres en pouces) donne un autre ensemble de
données qui continue de suivre cette loi.
Cordialement,
--
Olivier Miakinen
Olivier Miakinen
Sep 7, 2021, 5:32:59 PM9/7/21
to
Le 07/09/2021 23:09, Olivier Miakinen a écrit :
>
> 2) Le nombre d'habitants des communes du Val-de-Marne.
> Ce nombre va de 2 604 (Périgny) à 92 531 (Vitry-sur-Seine). Il ne
> couvre que deux ordres de grandeur, et bien qu'il s'agisse du même
> genre de données que l'exemple précédent je suis prêt à parier
> qu'ils ne suivent pas la loi de Benford.
Vérifions :
>
> 2) Le nombre d'habitants des communes du Val-de-Marne.
> Ce nombre va de 2 604 (Périgny) à 92 531 (Vitry-sur-Seine). Il ne
> couvre que deux ordres de grandeur, et bien qu'il s'agisse du même
> genre de données que l'exemple précédent je suis prêt à parier
> qu'ils ne suivent pas la loi de Benford.
<https://www.bien-dans-ma-ville.fr/classement-ville-nb-habitant-val-de-marne/>
Il y a 47 villes, dont les nombres d'habitants (classés par 1er chiffre) sont :
10163
11905
14393
14574
15922
16594
16903
16967
18226
18859
19169
20102
20732
21516
22401
23272
25639
25640
2604
26264
27154
28511
28942
30433
30722
30736
31550
32626
33970
3640
43846
44410
4479
4709
4772
49461
53649
54915
5527
5631
56661
59572
75168
76508
90739
92531
9684
Voyons les statistiques :
1: 11 23%
2: 12 25%
3: 7 14%
4: 6 12%
5: 6 12%
6: 0 0%
7: 2 4%
8: 0 0%
9: 3 6%
Rien que pour les chiffres 1 et 2, avec 23% et 25% on est loin des 30% et 17% !
Surtout, on est très loin d'avoir près de deux fois plus de chiffres 1 que de
chiffres 2.
--
Olivier Miakinen
Jacques Mathon
Sep 8, 2021, 4:11:45 AM9/8/21
to
Le 07/09/2021 à 14:11, Olivier Miakinen a écrit :
> Le 07/09/2021 à 13:54, Jacques Mathon a écrit :
>>>
>>> Si tu voulais vraiment tenir compte de la répartition possible des trois
>>> derniers chiffres il faudrait faire une statistique sur la fréquence de
>>> chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
>>> plus fréquent que le nombre 999.
Nous sommes d'accord.
>>>
>>> Si tu voulais vraiment tenir compte de la répartition possible des trois
>>> derniers chiffres il faudrait faire une statistique sur la fréquence de
>>> chaque possibilité, étant entendu que le nombre 001 doit être *beaucoup*
>>> plus fréquent que le nombre 999.
>> Voir la loi de Benford
>> https://fr.wikipedia.org/wiki/Loi_de_Benford
comme un "exemple" de répartition non uniforme.
> Ah non, je suis désolé mais elle ne s'applique pas dans ce cas puisque
> les nombres ne couvrent pas uniformément plusieurs ordres de grandeur.
Amicalement
--
Jacques
0 new messages