Algorithme pour résoudre inéquation?

[flashnext]

Bonjour !

Une secrétaire doit joindre des clients au téléphone. Sur cinq appels, elle réussit à joindre en général 3 clients. Combien d'appels doit-elle passer pour que la probabilité de joindre au moins un client soit supérieure à 0,999?

On pourrait passer par l'événement contraire, mais j'essaye de faire quelque chose de différent (pour que ça corresponde à plus de situations)...

On a p = 3/5. X est la variable aléatoire qui compte le nombre de clients joints.
On cherche n tel que la proba de réaliser au moins un succès soit supérieure à 0,999.

Je ne peux pas vous écrire ce que j'ai fait avec des lettres (trop de formules pénibles à mettre en texte), alors je vous l'ai scanné. La photo est disponible Ici

J'ai essayé d'utiliser un algorithme (codé en TI-82 Stats) pour résoudre l'inéquation (je ne voyais pas d'autre moyen). Mais il ne donne pas la solution, il doit y avoir des fautes... Je ne suis même pas sur que mon inéquation est juste.

Si vous voyez un meilleur moyen je suis preneur ! (compréhensible au niveau première)

Merci et bonne journée

[nodjim]

C'est tout de même plutôt maso de chercher une méthode compliquée quand la simple donne un résultat immédiat....

[flashnext]

C'est tout de même plutôt maso de chercher une méthode compliquée quand la simple donne un résultat immédiat....

Le goût du défi... :mur:

[paquito]

Ton algorithme,pas mal du tout d'ailleurs, ne peut pas marcher car tu cherches justement N; c'est un exo super classique où tu doit passer par l'événement contraire, soit p=3/5, tu cherche P(X>=1)>0,999,
ce qui revient à 1-P(X=0)>=0,999 <-> P(X=0)=<0,001 <-> q^n<=0,001 <-> ln(q^n)=<0,001 <->
nln(q)= n>=ln(0,001)/ln(2/5) (attention, 2/5<1 donc ln(2/5)<0) <-> n>=7,538....donc n>=8. Tu ne peux pas faire autrement, sauf en tatonant.

Sinon, au niveau programme, pour une loi B(n,p), il t'en faut un qui calcule P(I=
:Prompt N
:Prompt P
:1-P->Q
:0->S
:Prompt I
:Prompt J
:For(K,I,J)
:NcK.P^K.Q^(N-K)+S->S
:End
:Disp S

[flashnext]

Je vois, merci !

En fait, j'essayais de faire un algo qui donne le nombre de tirages associé à une probabilité plutôt que l'inverse.

Par exemple, on lui dit : "Je veux p probabilité de réaliser au moins k succès. Combien je dois faire de tirages?" plutôt que "J'ai n tirages et k succès. Quelle est ma probabilité de réaliser ces succès?"

[flashnext]

Cette aprèm j'ai réessayé de problème, et c'est bon j'ai compris pourquoi ça ne marchait pas..
Je vous poste ma solution, ceux que ça intéresse (et si vous avez une autre solution que la méthode de "gros Bourrin" qui consiste à écrire un algorithme qui teste toutes les possibilités, je vous écoute...).

L'algorithme en Ti-82 Stats ici : https://www.dropbox.com/s/01vuwqn9hp2pjb2/Photo%2023-03-2014%2016%2046%2036.png

On trouve 8, exactement comme avec la méthode "événement contraire"

[paquito]

[quote="flashnext"]Cette aprèm j'ai réessayé de problème, et c'est bon j'ai compris pourquoi ça ne marchait pas..
Je vous poste ma solution, ceux que ça intéresse (et si vous avez une autre solution que la méthode de "gros Bourrin" qui consiste à écrire un algorithme qui teste toutes les possibilités, je vous écoute...).

L'algorithme en Ti-82 Stats ici : [url]https://www.dropbox.com/s/01vuwqn9hp2pjb2/Photo%2023-03-2014%2016%2046%2036

Petit problème, tu fait varier n, donc tu fait intervenir plusieurs loi B(n; p), donc ce que tu as trouvé est dû au hasard; tu veux calculer Sigma(k=1 à N)(NcK.p^K;Q^(N-K)) et t'arrêter lorsque le résultat>0999; ça va être long et peut être incalculable si NcK>10^99.
Remplace 3/5 par 0,01 et q par 0,99, tu verras que ton programme ne passe plus (la solution est n=688). Donc, bravo pour ton programme, mais il vaut mieux passer par l'événement contraire qui ne dépend pas d'un programme, mais qui donne la solution en moins d'une minute.

[flashnext]

Cette aprèm j'ai réessayé de problème, et c'est bon j'ai compris pourquoi ça ne marchait pas..
Je vous poste ma solution, ceux que ça intéresse (et si vous avez une autre solution que la méthode de "gros Bourrin" qui consiste à écrire un algorithme qui teste toutes les possibilités, je vous écoute...).

L'algorithme en Ti-82 Stats ici : [url]https://www.dropbox.com/s/01vuwqn9hp2pjb2/Photo%2023-03-2014%2016%2046%2036

Petit problème, tu fait varier n, donc tu fait intervenir plusieurs loi B(n; p), donc ce que tu as trouvé est dû au hasard; tu veux calculer Sigma(k=1 à N)(NcK.p^K;Q^(N-K)) et t'arrêter lorsque le résultat>0999; ça va être long et peut être incalculable si NcK>10^99.
Remplace 3/5 par 0,01 et q par 0,99, tu verras que ton programme ne passe plus (la solution est n=688). Donc, bravo pour ton programme, mais il vaut mieux passer par l'événement contraire qui ne dépend pas d'un programme, mais qui donne la solution en moins d'une minute.

Non, le programme fonctionne. Je sais qu'il est limité par la puissance de la calculatrice, et qu'il y a plus simple avec l'événement contraire, mais ça faisait beaucoup moins travailler mes méninges... :bad:

Et le but était justement de trouver un algorithme qui fait intervenir plusieurs loi B(n ; p), en fait qui les teste toutes jusqu'à ce qu'il en trouve une qui remplisse la condition P>0,999.

J'essayais plus de m'entraîner aux algorithmes que de trouver une solution simple :id:

Merci de vos réponses

[paquito]

Non, le programme fonctionne. Je sais qu'il est limité par la puissance de la calculatrice, et qu'il y a plus simple avec l'événement contraire, mais ça faisait beaucoup moins travailler mes méninges... :bad:

Et le but était justement de trouver un algorithme qui fait intervenir plusieurs loi B(n ; p), en fait qui les teste toutes jusqu'à ce qu'il en trouve une qui remplisse la condition P>0,999.

J'essayais plus de m'entraîner aux algorithmes que de trouver une solution simple :id:

Merci de vos réponses

Ton algorithme fonctionne, mais ce n'est pas du tout la meilleure façon de répondre au problème posé;
Tu peux faire d'autres algorithmes utiles, comme calculer une somme de termes définis par une relation de récurrence, mais pour le problème présent, ton algorithme est inutile puisqu'il y a une solution bien plus simple; Soit par exemple: U0=1 et U(n+1) =0,5Un +1; fais moi un programme qui calcule Somme de K=0 à N des Uk. ca pourra être plus utile!

[flashnext]

Ton algorithme fonctionne, mais ce n'est pas du tout la meilleure façon de répondre au problème posé;
Tu peux faire d'autres algorithmes utiles, comme calculer une somme de termes définis par une relation de récurrence, mais pour le problème présent, ton algorithme est inutile puisqu'il y a une solution bien plus simple; Soit par exemple: U0=1 et U(n+1) =0,5Un +1; fais moi un programme qui calcule Somme de K=0 à N des Uk. ca pourra être plus utile!

Ahah ouais ! Je ferais ça dès que j'aurais du temps, merci

[fatal_error]

hello,

juste pour pousser l'idée de la recherche du N jusqu'au bout quelques idées :
au lieu de faire N+1->N

on peut tenter de faire une dichotomie:
N+10->N
puis si on a toujours PG on sauvegarde le N tq PN puis...si on a toujours P... etc, puis dès qu'on a trouvé le N ou ya P>=0.999
N->D
après on peut chercher entre G et D.
Pour ca on peut regarder (G+D)/2 (au milieu de l'intervalle quoi) et ajuster l'intervalle petit à petit...


Une deuxième remarque :


et on peut sortir 2/5^k de sigma
et 1.5^k ca doit se calculer un peu mieux.
D'ailleur on peut faire mieux :
dans la boucle for :

Code: Tout sélectionner

1->R
For(K,1,N)
 R*1.5->R
 P + (K,N)*R ->P
End
P*(2/5)^N ->P


au passage, la somme devrait pas plutot commencer à 0 et pas à 1?

[paquito]

hello,

juste pour pousser l'idée de la recherche du N jusqu'au bout quelques idées :
au lieu de faire N+1->N

on peut tenter de faire une dichotomie:
N+10->N
puis si on a toujours PG on sauvegarde le N tq PN puis...si on a toujours P... etc, puis dès qu'on a trouvé le N ou ya P>=0.999
N->D
après on peut chercher entre G et D.
Pour ca on peut regarder (G+D)/2 (au milieu de l'intervalle quoi) et ajuster l'intervalle petit à petit...


Une deuxième remarque :


et on peut sortir 2/5^k de sigma
et 1.5^k ca doit se calculer un peu mieux.
D'ailleur on peut faire mieux :
dans la boucle for :

Code: Tout sélectionner

1->R
For(K,1,N)
 R*1.5->R
 P + (K,N)*R ->P
End
P*(2/5)^N ->P


au passage, la somme devrait pas plutot commencer à 0 et pas à 1?

Un produit doit être initialiser par 1(R), mais effectivement la somme (P) doit être initialisée par 0.

[flashnext]

hello,

juste pour pousser l'idée de la recherche du N jusqu'au bout quelques idées :
au lieu de faire N+1->N

on peut tenter de faire une dichotomie:
N+10->N
puis si on a toujours PG on sauvegarde le N tq PN puis...si on a toujours P... etc, puis dès qu'on a trouvé le N ou ya P>=0.999
N->D
après on peut chercher entre G et D.
Pour ca on peut regarder (G+D)/2 (au milieu de l'intervalle quoi) et ajuster l'intervalle petit à petit...


Une deuxième remarque :


et on peut sortir 2/5^k de sigma
et 1.5^k ca doit se calculer un peu mieux.
D'ailleur on peut faire mieux :
dans la boucle for :

Code: Tout sélectionner

1->R
For(K,1,N)
 R*1.5->R
 P + (K,N)*R ->P
End
P*(2/5)^N ->P


au passage, la somme devrait pas plutot commencer à 0 et pas à 1?

Ah oui, bonne idée de faire N+10--> N !

Par contre, d'après le sujet, la secrétaire doit tomber sur au moins un client... Donc la somme commence à 1. Si tu la commences à 0, P sera toujours égal à 1, puisque tu as toujours 100% de chances que 0 personne ou plus décrochent (0 étant le minimum possible).