Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.sys.mac.programmation > #1457 > unrolled thread

Re: Pour se réveiller

Back to article view | Back to fr.comp.sys.mac.programmation

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Pour se réveiller pehache <pehache.7@gmail.com> - 2016-06-06 08:45 +0200
    Re: Pour se réveiller josephb@nowhere.invalid (Joseph-B) - 2016-06-06 09:17 +0200
      Re: Pour se réveiller michel.vauquois@invalid.orage.fr (M.V.) - 2016-06-07 15:38 +0200
        Re: Pour se réveiller josephb@nowhere.invalid (Joseph-B) - 2016-06-07 16:10 +0200
          Re: Pour se réveiller michel.vauquois@invalid.orage.fr (M.V.) - 2016-06-07 16:21 +0200
        Re: Pour se réveiller pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) - 2016-06-07 17:44 +0200
          Re: Pour se réveiller michel.vauquois@invalid.orage.fr (M.V.) - 2016-06-07 18:08 +0200
            Re: Pour se réveiller pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) - 2016-06-08 09:32 +0200
    Re: Pour se réveiller olivier.marti@ensta.org (Olivier Marti) - 2016-06-06 11:02 +0200
    Re: Pour se réveiller pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) - 2016-06-07 11:38 +0200

#1457 — Re: Pour se réveiller

Le 05/06/2016 à 15:52, Joseph-B a écrit :
> FU2 to fr.comp.sys.mac.programmation
> Bonjour à tous,
>
> Une pensée pour les sinistrés qui ont d'autres chats à fouetter que de
> traîner sur Usenet.
> Pour les autres habitués de focomosX, un petit casse-tête pour essayer
> de réveiller les neurones engourdis.
> Bon, je sais c'est de la programmation, d'où le suivi sur
> fr.comp.sys.mac.programmation
>
> Voilà le défi
> Quelques mois de ça, il y a avait eu une enfilade assez nourrie à propos
> du tirage du Loto.
> Une des questions en rapport étant : la fonction aléatoire ("Random")
> fournie par Applescript en standard, l'est-elle suffisamment, ou va-t-on
> trouver certains nombres sortir significativement plus souvent que
> d'autres ?
>
> Pour tirer ça au clair, une seule manière : faire un très grand nombre
> de tirages, disons 100 000, voire un million, plusieurs fois, et
> comparer les occurences de chaque nombre sorti.

Il faudrait vraiment un très gros défaut dans le générateur pour que les 
occurrences de chaque nombre devient de l'équiprobabilité. De plus tu 
vas forcément trouver des déviations statistiques, qu'il va falloir 
analyser pour savoir si elles sont normales ou pas.

Un défaut plus courant et plus difficile à mettre en évidence dans les 
générateurs de nombres aléatoire ce sont les séquences prédictibles :
- par exemple 2 est suivi d'un 20, alors le générateur sort plus souvent 
un 15 qu'autre chose en suivant.
- ou bien si un nombre quelconque sort au tirage N, alors il a plus de 
chances de ressortir qu'un autre au tirage N+P




-- 
"Je suis co-auteur de ARAnyM. Mais je ne vais pas m'en vanter plus
que cela, car lorsque l'on est contributeur dans le logiciel libre,
le but n'est pas de satisfaire son égo." (FLC)

[toc] | [next] | [standalone]

#1460

pehache <pehache.7@gmail.com> a écrit,

> Un défaut plus courant et plus difficile à mettre en évidence dans les
> générateurs de nombres aléatoire ce sont les séquences prédictibles :
> - par exemple 2 est suivi d'un 20, alors le générateur sort plus souvent
> un 15 qu'autre chose en suivant.
> - ou bien si un nombre quelconque sort au tirage N, alors il a plus de
> chances de ressortir qu'un autre au tirage N+P

Là on entre dans une analyse fine qui dépasse largement le cadre de ce
petit jeu.
De plus il faut avoir la répartition "physique" des nombres dans la
liste, un simple décompte des occurences ne suffit plus. Ça devient du
lourd !
-- 
J. B.

[toc] | [prev] | [next] | [standalone]

#1466

Joseph-B <josephb@nowhere.invalid> wrote:

> Là on entre dans une analyse fine qui dépasse largement le cadre de ce
> petit jeu.
> De plus il faut avoir la répartition "physique" des nombres dans la
> liste, un simple décompte des occurences ne suffit plus. Ça devient du
> lourd !

J'ai fait la chose suivante pour des tirages de nombres de 1 à
10.

À chaque tirage, la liste des 10 nombres est "brassée"
aléatoirement et le tirage se fait dans cette liste "brassée" et
non plus simplement par :
++++++++++
set tempNb to random number from 1 to 10
++++++++++

Ceci pour tenter d'éviter ce que PAD a nommé "le risque de
répétition de séquences, pas la répartition globale."
Cf.
<news:1moh0w5.os8s9c4ys2l0N%pdorange@pas-de-pub-merci.mac.com>

J'obtiens par exemple:
Nombre de tirages : 10000
Le nombre 1 a été tiré 989 fois.
Le nombre 2 a été tiré 987 fois.
Le nombre 3 a été tiré 1015 fois.
Le nombre 4 a été tiré 1018 fois.
Le nombre 5 a été tiré 1010 fois.
Le nombre 6 a été tiré 965 fois.
Le nombre 7 a été tiré 1018 fois.
Le nombre 8 a été tiré 997 fois.
Le nombre 9 a été tiré 1053 fois.
Le nombre 10 a été tiré 948 fois.

et pour seulement 1 000 tirages :
Nombre de tirages : 1000
Le nombre 1 a été tiré 106 fois.
Le nombre 2 a été tiré 98 fois.
Le nombre 3 a été tiré 108 fois.
Le nombre 4 a été tiré 98 fois.
Le nombre 5 a été tiré 99 fois.
Le nombre 6 a été tiré 93 fois.
Le nombre 7 a été tiré 84 fois.
Le nombre 8 a été tiré 107 fois.
Le nombre 9 a été tiré 115 fois.
Le nombre 10 a été tiré 92 fois.

Avec la commande simple de tirage aléatoire, j'obtiens :
Nombre de tirages : 1000
Le nombre 1 a été tiré 57 fois.
Le nombre 2 a été tiré 100 fois.
Le nombre 3 a été tiré 86 fois.
Le nombre 4 a été tiré 134 fois.
Le nombre 5 a été tiré 97 fois.
Le nombre 6 a été tiré 133 fois.
Le nombre 7 a été tiré 115 fois.
Le nombre 8 a été tiré 111 fois.
Le nombre 9 a été tiré 108 fois.
Le nombre 10 a été tiré 59 fois.

et c'est systématique : les nombres 1 et 10 sont très peu
tirés...
-- 
Michel Vauquois
<http://michelvauquois.free-h.fr>

[toc] | [prev] | [next] | [standalone]

#1467

M.V. estime devoir nous faire part de ceci :

> et c'est systématique : les nombres 1 et 10 sont très peu
> tirés...

De mon côté, j'avais remarqué (comme mentionné par pehache) qu'avec la
fonction "random" de base, un nombre qui vient de sortir a une  plus
grande probabilité de ressortir au coup suivant. Même si au long cours
ça n'impacte pas la répartition moyenne, sur des petites séries ça peut
être un biais non négligeable.

Il faut donc augmenter le facteur d'aléa si on veut être un peu plus
rigoureux.
-- 
J. B.
Voici l'aimant dimensionnel dont il est temps d'améliorer la
multi-turbulence alvéolée sans oublier de pournifier le conduit dirigé.

[toc] | [prev] | [next] | [standalone]

#1468

Re-bonjour,

Joseph-B, complètement torché, nous apprend :

> De mon côté, j'avais remarqué (comme mentionné par pehache) qu'avec la
> fonction "random" de base, un nombre qui vient de sortir a une  plus
> grande probabilité de ressortir au coup suivant. Même si au long cours
> ça n'impacte pas la répartition moyenne, sur des petites séries ça peut
> être un biais non négligeable.

Apparemment, le nombre de nombres joue également un rôle important.
Toujours avec 10 nombres :
Nombre de tirages : 10000
Le nombre 1 a été tiré 560 fois.
Le nombre 2 a été tiré 1098 fois.
Le nombre 3 a été tiré 1090 fois.
Le nombre 4 a été tiré 1131 fois.
Le nombre 5 a été tiré 1119 fois.
Le nombre 6 a été tiré 1168 fois.
Le nombre 7 a été tiré 1105 fois.
Le nombre 8 a été tiré 1033 fois.
Le nombre 9 a été tiré 1117 fois.
Le nombre 10 a été tiré 579 fois.

On n'avait pas remarqué ces "aberrations" avec 50 nombres... ou alors,
mon script a un bémol !


Amicalement.
-- 
Michel Vauquois - <http://michelvauquois.free-h.fr>
Faut-il spiro-fracasser le proto-conduit ou bien moribaffer le tunnel ?
Comment savoir !

[toc] | [prev] | [next] | [standalone]

#1469

M.V. <michel.vauquois@invalid.orage.fr> wrote:

> Ceci pour tenter d'éviter ce que PAD a nommé "le risque de
> répétition de séquences, pas la répartition globale."

Tu ne peux éviter ce biais, qui est inérant aux méthodes
pseudo-aléatoire. Et il n'y a que ce type de méthode qui est accessible
aux ordinateurs. 
Leur nature numérique précise, les rend incapable de générer par
eux-même de l'aléatoire.

Les développeurs et mathématiciens penchent sur ces problèmes depuis la
nuit des temps (enfin le début d' l'informatique quoi).
Les solutions mises en œuvre vont un peu dans le sens que tu testes,
ajouter de la complexité afin de réduire le risque, mais ce n'est qu'un
risque réduit pas une disparition du risque.
Par exemple souvent (c'est le cas en C par exemple) les codes
pseudo-aléatoire permettent de lancer la séquence avec un clé (ou seed)
et on peut chosiir cette clé en se basant sur la date et l'heure. Mais
avec la même clé on obtiendra la même séquence "aléatoire" (sic)...

Pour avoir un véritable aléatoire, il faudrait se baser (comme
référence) sur un évènement aléatoire, par exemple la valeur du champ
magnétique du lieu et au moment de l'utilisation de la fonction, ou
d'autres évènements suffisamment chaotique pour servir de marqueur
aléatoire. Mais ça ne peut qu'être un évènement externe à l'ordinateur
qui lui par construction doit être précis et est justement conçu pour
éviter les évènements interne aléatoire.

A noter que dans la très grand majorité des cas, le pseudo-aléatoire
suffit et heureusement.

-- 
Pierre-Alain Dorange               Moof <http://clarus.chez-alice.fr/>

Ce message est sous licence Creative Commons "by-nc-sa-2.0"
<http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>

[toc] | [prev] | [next] | [standalone]

#1470

Bonsoir,

Pierre-Alain Dorange, n'écoutant que son courage, a osé écrire ce qui
suit :

> A noter que dans la très grand majorité des cas, le pseudo-aléatoire
> suffit et heureusement.

Oui... et en procédant comme je l'ai indiqué, j'augmente la probabilité
d'obtenir un résultat aléatoire !

Allez à toire, allez à toire, allez... ;-)

Cordialement
-- 
Michel Vauquois - <http://michelvauquois.free-h.fr>
Voici l'anti-schisme linéaire dont il est temps d'optimiser le
thermo-tube phasé sans oublier d'annuler l'anti-nacelle
gravitationnelle.

[toc] | [prev] | [next] | [standalone]

#1473

M.V. <michel.vauquois@invalid.orage.fr> wrote:

> Allez à toire, allez à toire, allez... ;-)

Allez à Thouars !

-- 
Pierre-Alain Dorange               Moof <http://clarus.chez-alice.fr/>

Ce message est sous licence Creative Commons "by-nc-sa-2.0"
<http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>

[toc] | [prev] | [next] | [standalone]

#1461

pehache <pehache.7@gmail.com> wrote:

> Le 05/06/2016 à 15:52, Joseph-B a écrit :
> > FU2 to fr.comp.sys.mac.programmation
> > Bonjour à tous,
> >
> > Une pensée pour les sinistrés qui ont d'autres chats à fouetter que de
> > traîner sur Usenet.
> > Pour les autres habitués de focomosX, un petit casse-tête pour essayer
> > de réveiller les neurones engourdis.
> > Bon, je sais c'est de la programmation, d'où le suivi sur
> > fr.comp.sys.mac.programmation
> >
> > Voilà le défi
> > Quelques mois de ça, il y a avait eu une enfilade assez nourrie à propos
> > du tirage du Loto.
> > Une des questions en rapport étant : la fonction aléatoire ("Random")
> > fournie par Applescript en standard, l'est-elle suffisamment, ou va-t-on
> > trouver certains nombres sortir significativement plus souvent que
> > d'autres ?
> >
> > Pour tirer ça au clair, une seule manière : faire un très grand nombre
> > de tirages, disons 100 000, voire un million, plusieurs fois, et
> > comparer les occurences de chaque nombre sorti.
> 
> Il faudrait vraiment un très gros défaut dans le générateur pour que les
> occurrences de chaque nombre devient de l'équiprobabilité. De plus tu
> vas forcément trouver des déviations statistiques, qu'il va falloir 
> analyser pour savoir si elles sont normales ou pas.
> 
> Un défaut plus courant et plus difficile à mettre en évidence dans les
> générateurs de nombres aléatoire ce sont les séquences prédictibles :
> - par exemple 2 est suivi d'un 20, alors le générateur sort plus souvent
> un 15 qu'autre chose en suivant.
> - ou bien si un nombre quelconque sort au tirage N, alors il a plus de
> chances de ressortir qu'un autre au tirage N+P

En fait le défaut des générateurs classiques à base de modulo est que
les nombres se retrouvent dans un nombre de plans limités quand on les
utilisent pour générer des n-uplets.

Le premier n-uplet est constitués des n premiers nombres tirés, puis le
second avec les suivant, etc ...  Si n est grand, les nombres sont mals
répartis : ils se regroupent dans un nombre limités d'hypers plans
(dimensions n-1) au lieu d'être répartis de façon homogène dans l'espace
de dimension n.

Il faut des dimensions n assez grandes et tirer un très grand nombre de
n-uplet pour que ça pose un problème. Mais ça a amené à créer des
générateurs plus subtils pour certains problèmes de physique qui ont
besoin d'un très grand nombre de valeurs aléatoires.

Voir Marsaglia G (1968) Random numbers fall mainly in the planes. PNAS
61:25–28.

Je n'ai pas l'article sous la main, mais il me semble qu'avec un
générateur en 32 bits et n > 4 ou 5, il faut commencer à se méfier.

Avec un générateur 64 bits pour des valeurs uniques, tu peux tirer 100
000 nombres sans voir le problème.

Olivier

[toc] | [prev] | [next] | [standalone]

#1464

pehache <pehache.7@gmail.com> wrote:

> Il faudrait vraiment un très gros défaut dans le générateur pour que les
> occurrences de chaque nombre devient de l'équiprobabilité. De plus tu
> vas forcément trouver des déviations statistiques, qu'il va falloir 
> analyser pour savoir si elles sont normales ou pas.
> 
> Un défaut plus courant et plus difficile à mettre en évidence dans les
> générateurs de nombres aléatoire ce sont les séquences prédictibles :
> - par exemple 2 est suivi d'un 20, alors le générateur sort plus souvent
> un 15 qu'autre chose en suivant.
> - ou bien si un nombre quelconque sort au tirage N, alors il a plus de
> chances de ressortir qu'un autre au tirage N+P

Comme cela avait était dis dans l'enfilade initiale, c'est en effet le
biais des générateurs pseudo-aléatoire généré par des système numérique
précis.
Un ordinateur n'est guère adapté a généré du vrai aléatoire (par sa
nature préxise).

Et c'est en effet le risque d répétition de séquence qui est a craindre,
pas la répartition globale.
-- 
Pierre-Alain Dorange               Moof <http://clarus.chez-alice.fr/>

Ce message est sous licence Creative Commons "by-nc-sa-2.0"
<http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>

[toc] | [prev] | [standalone]

Back to top | Article view | fr.comp.sys.mac.programmation

csiph-web