Jeu 30 et 40 casino pb complexe

[floomc]

Bonjour à tous,

Je vous propose un pb concret de probabilités à travers un jeu casino qui se nomme le 30 et 40.
Je compte sur votre précieuse aide pour le résoudre. Celui-ci s'adresse, qu'à des amateurs confirmés voire experts en math

Le problème se déroule avec 6 jeux de 52 cartes classiques (sans les jokers)
Les mains pour être qualifiées doivent être égales ou supérieurs à 31 et < ou égale à 40 sachant que l'as vaut 1 et les figures valent 10 (les autres cartes gardant leur valeur faciale).

Le nombre minimum de cartes tirées pour être qualifié étant de 4 (3 cartes de valeur 10 et n'importe quelle autre carte) et maximum étant 28 (24 As, + 4 cartes "2")

Quelles sont les proba pour que la main se qualifie avec 4 cartes ? avec 5 cartes ? etc jusqu'à 28. La somme totale devant faire 1

Merci d'avance et n'hésitez pas si vous avez des questions

[Cauchy2010]

Bonjour à tous,
Je vous propose un pb concret de probabilités à travers un jeu casino qui se nomme le 30 et 40.
Je compte sur votre précieuse aide pour le résoudre. Celui-ci s'adresse, qu'à des amateurs confirmés voire experts en math
Le problème se déroule avec 6 jeux de 52 cartes classiques (sans les jokers)
Les mains pour être qualifiées doivent être égales ou supérieurs à 31 et < ou égale à 40 sachant que l'as vaut 1 et les figures valent 10 (les autres cartes gardant leur valeur faciale).
Le nombre minimum de cartes tirées pour être qualifié étant de 4 (3 cartes de valeur 10 et n'importe quelle autre carte) et maximum étant 28 (24 As, + 4 cartes "2")
Quelles sont les proba pour que la main se qualifie avec 4 cartes ? avec 5 cartes ? etc jusqu'à 28.
La somme totale devant faire 1
Merci d'avance et n'hésitez pas si vous avez des questions

Sûrement pas avec ce que tu décris ! Explique mieux les règle du jeu, sinon c'est un pb inutile. Merci !

[floomc]

Sûrement pas avec ce que tu décris ! Explique mieux les règle du jeu, sinon c'est un pb inutile. Merci !

Ok, je vais essayer d'expliquer le jeu de base mais il n'y en a pas réellement besoin pour résoudre ce problème.
Le jeu de base est le 30 et 40, qui est un jeu casino.

Le croupier tire deux rangées indépendantes de cartes l'une après l'autre devant lui et arrête de tirer lorsque la somme de chacune des rangées (matérialisée par la sommes des cartes) est supérieure ou égale à 31.
Comme je l'ai dit, l'as vaut 1 et les figures valent 10 (les autres cartes gardant leur valeur faciale).

Le joueur a le choix de parier sur quelle est la rangée qui va avoir le score le plus proche de 31 et sur la couleur de la 1ère carte tirée sur la rangée du haut ou du bas.

L'idée est de rajouter un pari supplémentaire qui consisterait à pronostiquer le nombre de cartes qui va composer la rangée du haut ou du bas mais pas les 2 en même temps. Afin de définir une table de paiements cohérente, j'ai besoin de connaitre les probabilités que ce nombre de cartes soit 4, soit 5, etc jusqu'à 28 étant le nombre de cartes maximum (si l'on joue avec 6 jeux de 52 cartes).

Bien entendu cette question étant un problème de probabilités la somme de toutes les combinaisons doit être égal à 1

[Cauchy2010]

Comme j'aime bien les énoncés clairs, voici : le trente et quarante

[Cauchy2010]

(...)
Bien entendu cette question étant un problème de probabilités la somme de toutes les combinaisons doit être égal à 1

C'est idiot comme remarque, car à chaque fois, le référentiel change !
Par exemple, pour la proba d'avoir 31 en 4 cartes, soit 3*10+1, on doit chercher toutes les combinaisons de 3 cartes parmi les 6*4*4 = 96 qui valent 10 et 1 carte parmi les 6*4 = 24 valant 1 ramené à toutes les combinaisons de 4 cartes choisies parmi les 6*52 = 316 cartes
Pour obtenir 32 en 5 cartes, soit 3*10+2*1, le référentiel est l'ensemble des 5-combinaisons parmi 312 cartes ... Und so weiter !!!

Au juste, tu veux quoi ? Qu'on bosse pour toi ou bien vérifier tes calculs par rapport aux nôtre ?

[Ben314]

Salut,
Perso, je trouve l'énoncé relativement clair (surtout par rapport à ce qu'on a d'habitude...), modulo un petit détail qui, je pense est plus ou moins sous entendu : On tire les cartes les unes après les autres dans le paquet de 312 cartes et, dés qu'on a un total de point dans l'intervalle [31,40] on arrête de tirer (i.e. on cherche pas la m... en tirant une carte de plus lorsqu'on a un total "faible" de 31 ou 32). Et la question, c'est de déterminer la loi de la v.a.r. X correspondant au nombre total de cartes tirées.

[Ben314]

Comme le calcul théoriqueme semble bien c... et que j'ai l'impression que c'est les résultats qui t'intéressent, j'ai fait un bout de programme en C pour faire des simulation et, en simulant 200 000 000 de tirages, je trouve la même chose que ton tableau à "un poil de c." près.
En fait, le calcul théorique serait bien plus simple si on considérait qu'il s'agit d'une succession de tirage avec remise (i.e. tu note la valeur de la carte tirée puis tu la remet dans le paquet que tu remélange) et, vu que le nobre de carte de chaque type est grand, cela donnerai des résultat quasi corrects pour les tirages non-exceptionnels.

P.S. La formule "théorique" donné dans le thread que tu cite est évidement exacte (c'est une traduction quasi immédiate de l'énoncé), mais le nombre de terme de la somme est énoooooorme donc je ne suis pas du tout sûr que la formule, telle qu'elle (i.e. sans quelques simplifications mathématiques préalable) soit d'une grande utilité, mais je me trompe peut-être : ma vision "intuitive" de ce qui est raisonnablement calculable avec un ordi. date d'il y a... un certain temps...

[Cauchy2010]

Salut,

mes résultats numériques :

nombre moyen de cartes tirées : un poil supérieur à 5, mode = 5 ;écart-type à peine supérieur à 1.
Intervalle : entre 4 et 13, au-delà, mieux vaaut jour au loto :ptdr:

résultats à rapporter à 10 millions :
#(4 cartes) : 3.209.705
#(5 cartes) : 3.687.765
#(6 cartes) : 2.096.181
#(7 cartes) : 756.994
#(8 cartes) : 199.326
#(9 cartes) : 41.858
#(10 cartes) : 7.093
#(11 cartes) : 1.042
#(12cartes) : 133
#(13 cartes) : 15

Tu vois, quand c'est clair, tout devient facile ! :lol3:

La prochaine fois, annonce la couleur et dis nous que tu nous challenges avec d'autres équipes, ce sera plus honnête de ta part. :salut:

[Ben314]

Tes résultats me semble bizare : moi je trouve ça :
N=200 000 000 = Nb de simulations
4 -> 0.2607763500 (Nb cartes -> proba)
5 -> 0.3670838700
6 -> 0.2396139800
7 -> 0.0968967550
8 -> 0.0280452000
9 -> 0.0062637400
10 -> 0.0011287750
11 -> 0.0001679550
12 -> 0.0000209050
13 -> 0.0000022650
14 -> 0.0000001900
15 -> 0.0000000150
Ce qui est extrêmement proche de ce qu'a foomc et assez éloigné de ce que tu trouve (principalement pour 4 cartes).
Perso, les simulation, je les fait comme ça :
[PHP]int simu(void)
{ int C[11],nC,S,R,i,N;
C[1]=C[2]=C[3]=C[4]=C[5]=C[6]=C[7]=C[8]=C[9]=24; C[10]=4*24;
nC=13*24; S=0; N=0;
do
{ R=(rand() % nC); i=0; do{i++; R-=C[i];} while(R>=0);
S+=i; N++; C[i]--; nC--;
}
while(S<31);
return N;
}[/PHP]

[Cauchy2010]

Es tu sûr que ton générateur aléatoire est capable de générer 200 millions de chemins distincts ?
Tous les générateurs sont limités, le seul le plus apte à éviter de boucler sur lui même tous les 10.000 tirages est le Mersenne twister.
Comme tu sais, il est très difficile de reproduire le hasard.

Quant à mon code, il est assez simple. Je code sous SAS.
je tire un nombre, nommé aléa, compris entre 0 et 1, au hasard, selon une loi uniforme.
Je partitionne selon que aléa est compris entre (k-1)/14 et k/14, pour k compris entre 1 et 13. Bien entendu, si supérieur à 13/14, j'en tiens aussi compte.
Pour chaque cas, je calcule somme=somme+min(k, 10) et je compte le nombre de cartes tirées. Quand la somme est comprise entre 31 et 40, je redémarre une boucle de simulation. J'en fais 10 millions.
A la fin, je fais une analyse statistique du nombre de cartes tirées.
Bien entendu, quand je refais une nouvelle simulation de 10 millions de cas, le résultat en nombre fluctue un peu, mais en % sur deux décimales, il est assez stable.

J'ai prévu dans mon pgm de regarder les cartes utilisées pour obtenir le résultat, mais ce n'est pas très intéressant.

[Ben314]

Je suis en tout cas suffisamment sûr de mon générateur pour savoir qu'un erreur aussi grande que celle qui sépare tes valeurs des mienne ne peut pas être due a un problème de générateur mais est forcément liée a un algorithme déficient.

Par exemple, ton "...selon que aléa est compris entre (k-1)/14 et k/14, pour k compris entre 1 et 13...", ne marche que pour la première carte tirée vu qu'à partir de la deuxième, comme il n'y a pas remise, les différentes "hauteurs" de cartes ne sont plus équiprobable mais dépende des cartes déjà tirés.
Mais vu le contexte (on en tire pas des tonnes), ça ne suffit pas a expliquer le trés gros écart qu'il y a entre tes valeurs et les miennes (pour 4 cartes) donc il y a (au moins) un deuxième bug quelque part.

[Cauchy2010]

J'ai regardé tes résultats et ceux du lien HTML. Résultats curieux, en effet.
Je vais regarder ça demain.

[Cauchy2010]

(...)
Par exemple, ton "...selon que aléa est compris entre (k-1)/14 et k/14, pour k compris entre 1 et 13...", ne marche que pour la première carte tirée vu qu'à partir de la deuxième, comme il n'y a pas remise, les différentes "hauteurs" de cartes ne sont plus équiprobable mais dépendent des cartes déjà tirées.

Exact ! Mieux, c'est suffisant pour générer l'écart. Comme quoi, faut pas confondre vitesse et précipitation.
Quand je pense qu'il y a à peine quelques semaines, je m'étais attaqué à la résolution d'une généralisation du paradoxe de W. Penney soumise sur un site où il y a des problèmes plutôt velus, avec bcp de joueur, des cartes et des tirages sans remise, sans me faire piéger, ...
Bon, c'est décidé, passé 18 H, faut que je pense à ne plus rien engager de sérieux :ptdr:

[Cauchy2010]

Mon code SAS :

[PHP]
data prob (keep = somme nbre sum );somme=0;nbre=0;sum=0;sump=0;
array carte(14);
do a = 1 to 10000000;
do j=1 to 14; carte(j)=24;end;
sum=312;sump=0;
do p = 1 to 312;
nbre=nbre+1;
alea=ranuni(-1);
do k = 1 to 13;
sump=sump+carte(k);
if alea <= sump/sum then do ;
somme=somme+min(k,10);carte(k)=carte(k)-1;sum=sum-1;sump=0;goto suite;end;
end;
somme=somme+10;carte(14)=carte(14)-1;sum=sum-1;sump=0;
suite : if 31 <= somme <= 40 then do; output;goto suiteb;end;
end;
suiteb : nbre=0; somme=0;
end;
run;
[/PHP]

[Ben314]

Je te fait confiance à 100%, surtout si maintenant tu trouve à peu prés la même chose que floomc et moi, mais ça me "trou le c..." que, contrairement a ce que j'ai affirmé dans mon dernier post, il y ait autant de différence entre le cas "avec remise" et le cas "sans remise" : on passe quand même de 26% a 32% pour 4 cartes et je comprend pas d'où vient un si gros écart : des carte de valeur 1 à 9, il y en a 6x4=24 de chaque "hauteur" et des cartes de valeur 10 il y en a 6x16=96 or la plupart du temps, on tire moins de 10 cartes : bizarre...

[Cauchy2010]

Tu comprends mieux pourquoi je me pose depuis tant d'années de vraies questions sur les générateurs aléatoires ...
Ma question "existentielle" est : comment générer du hasard vraiment hasardeux ?
Dans le cas d'espèce, on peut vérifier par le calcul, mais sinon ?!?
J'ai pas mal lu sur le sujet, le doute est constant. Aucune garantie, malgré des mètres linéaires de tests sur le sujet.

[Ben314]

Il me semble bien avoir lu a plusieurs endroits que, du point de vue théorique, un vrai "générateur aléatoire", on peut démontrer que ça ne peut pas exister, donc forcément, tout générateur va avoir des "faiblesses" et évidement les faiblesses de l'un ne seront pas les mêmes que celles d'un autre donc, comme toujours, il n'y aura aucun "classement" possible avec un "meilleurs" et des "moins bons" : tout dépendra de l'utilisation...

[Cauchy2010]

Pour rebondir sur ta remarque précédente, la sur-représentation des cartes de valeur 10 explique pourquoi on en tire finalement si peu.
Comme c'est un jeu de casino, c'est peu étonnant, il faut que ça aille vite.

[LeJeu]

mais ça me "trou le c..." que, contrairement a ce que j'ai affirmé dans mon dernier post, il y ait autant de différence entre le cas "avec remise" et le cas "sans remise" : on passe quand même de 26% a 32% pour 4 cartes et je comprend pas d'où vient un si gros écart : des carte de valeur 1 à 9, il y en a 6x4=24 de chaque "hauteur" et des cartes de valeur 10 il y en a 6x16=96 or la plupart du temps, on tire moins de 10 cartes : bizarre...

Bonsoir,

J'ai lu ce post en vacances, et j'attendais d'être connecté correctement pour répondrre...

Comme tu le dis Ben "A un poil près " avec remise et sans remise, ca devrait être la même chose
je trouve pour 4 cartes
sans remise : 0.26081
avec remise : 0.26210

Et donc, je suis assez d'accord que la qualité du générateur de nombre aléatoire à bon dos ... l'algo est quand même en première ligne dans l'histoire

A propos d'algo, je ne suis pas si sûr qu'une Monte Carlo soit si bien que ça dans cette situation, au final c'est couteux et pas si précis que ça ..
Couteux, car comme on voit dans le code de Ben , on peut tenter les 200 millions voir le milliard de lancer, mais le résultat tarde franchement à sortir ...

J'ai choisi de mon coté une méthode un peu différente, c'est à dire de compter franco tous les cas possibles
Évidemment si on part sur un 312*312..... c'est vite terrible
je suis donc parti sur un algo pour les 4 cartes en 10*10*10*10, en dénombrant correctement les cas favorables

J'ai fait ca en récursif , mais pour illustrer je vous donne un fragment de code 'simpliste' pour illustrer :

Code: Tout sélectionner


   int nb= 13*24;

   C[1]=C[2]=C[3]=C[4]=C[5]=C[6]=C[7]=C[8]=C[9]=24; C[10]=4*24;

   for (i=1;i=31)
               {
                  produit  = C[i]--;
                  produit *= C[j]--;
                  produit *= C[k]--;
                  produit *= C[l]--;
                  somme +=  produit;
                  C[i]++,C[j]++,C[k]++,C[l]++;
               };
   proba =   somme;
   proba /= nb--;
   proba /= nb--;
   proba /= nb--;
   proba /= nb--;


ce truc tourne en rien de temps ( instantanné) et donne comme résultat
2 424 218 400 / 312 * 311 * 310 * 309 = 0.26081

Le code pour le "avec remise" est bien sûr encore plus simple

Code: Tout sélectionner

   
   for (i=1;i=31)
               {
                  produit  = C[i] * C[j] * C[k] * C[l] ;
                  somme +=  produit;
               };

   proba =  somme;
   proba /= nb;
   proba /= nb;
   proba /= nb;
   proba /= nb;



pour un résultat de 0.26210

En fait je m'attendais que la version récursive s'effondre assez rapidement en augmentant la profondeur , mais non pas du tout !!!

Pas du tout, car on le voit dans les post précédents, il y a de moins en mioins de solutions... et on ne tombe pas du tout dans un trip exponentiel !

En fait c'est la précision des nombres qui pose problème ... on tombe très vite sur le maximum d'un integer ( 0xFFFFFFF ) soit environ 4 millliads

Et donc il faut envisager un calcul en " huge integer"
dans notre cas , je compte les paquets de 1 milliard

Code: Tout sélectionner

   if ( somme > MD)
      {somme-=MD;retenue++;}


Simple et efficace ...

Sinon, messieurs, sans polémique aucune ..
votre code est quand même chaud cacao
Ben s'est entrainé sur un 8080 128 octets de mémoire vive.. ca se se voit
Cauchy2010 , je ne connais pas ton langage, mais les goto me piquent les yeux ...


Ps - Ben , l'expression que tu cherchais est "à l'épaisseur du trait près" :-)

Ps - évitez d'effacer les posts, ceux qui donnaient peut-être du code un peu buggé, ca rend compliquée la lecture

[Cauchy2010]

C'est le code utilisé pour utiliser un puissant logiciel de calcul appelé SAS, d'origine US.
l'INSEE, les assureurs et mutualistes, les grandes banques et autres institutions mondiales s'en servent car il permet de traiter des fichiers très lourds.
En termes de calculs numériques, il est aussi très puissant, mais son code est un peu vieillot et fait pas mal réfléchir.
Par contre, je suis certain de mes résultats et j'ai toujours un gros doute sur les générateurs aléatoires.