Forum de mathématiques - Bibm@th.net
Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#176 Re : Café mathématique » Combien y a-t-il réellement des fichiers possibles de n bits ? » 08-08-2016 10:30:03
Ben, tout dépend dans quelle base on se place. Les deux sont vrais.
#177 Re : Programmation » A propos de langage » 07-08-2016 21:50:48
Un peu plus d'une minute, trois valeurs à modifier et il est plus de 22H.
Question 1 As-tu prévenu que les données de départ étaient fausses ?
Question 2 Comme nt sais-tu que Yoshi est d'accord pour mes interventions ?
Le résultat
DEPART
0.143 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -0.143 = -0.286
-8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 9.000 = 17.000
-1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000
Ligne 1 S=-0.285714
Ligne 2 S=16.000000
Ligne 3 S=-2.000000
Ligne 4 S=16.000000
Ligne 5 S=-2.000000
Ligne 6 S=16.000000
Ligne 7 S=-2.000000
Ligne 8 S=16.000000
Ligne 9 S=-2.000000
Ligne 10 S=16.000000
Ligne 11 S=-2.000000
Ligne 12 S=16.000000
Ligne 13 S=-2.000000
Ligne 14 S=16.000000
Ligne 15 S=-2.000000
Ligne 16 S=16.000000
Ligne 17 S=-2.000000
Ligne 18 S=16.000000
Ligne 19 S=-2.000000
Ligne 20 S=17.000000
Bonne nuit.
[HS] Ta remarque concernant les entiers ou pas entiers prouve ta méconnaissance de la façon dont fonctionne une machine.[/HS]
#178 Re : Café mathématique » Combien y a-t-il réellement des fichiers possibles de n bits ? » 07-08-2016 21:35:25
Bonsoir,
Votre question est sans aucun intérêt. Sur un autre forum, des gens ont essayé de vous expliquer que vous posiez des questions qui n'ont aucun sens.
Je vous réponds en supposant que vous croyez, de bonne foi, que votre question est intéressante. Il n'en est rien. Ici on parle de math et c'est déjà très difficile.
#179 Re : Programmation » A propos de langage » 07-08-2016 21:19:20
Pas de souci, c'est pas sûr.
Les nombres que j'ai entrés sont des termes en flottant. Il n'y a pas d'entiers dans ce calcul, sauf les compteurs.
J'ai copié strictement ce que j'ai lu au message #24. S'il y a une erreur dis-le moi, j'en ai pour une minute pour rectifier.
Les nombres imprimés sont les solutions du système dont j'imprime les données. Les 20 dernières lignes ne sont qu'une vérification effectuée au retour du calcul.
J'aimerai bien avoir l'accord formel de Yoschi pour l'autorisation de jouer avec vous.
#180 Re : Programmation » A propos de langage » 07-08-2016 20:46:58
Bonsoir Léon,
Je n'avais pas compris que vous vouliez que je joue avec vous. Yoshi est-il d'accord.
J'ai cru comprendre que vous aviez des soucis avec la résolution de ce système que tu as proposé.
Voila ma solution.
DEPART
1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -1.000 = -2.000
-8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 0.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 0.000 7.000 = 16.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 -8.000 1.000 7.000 = -2.000
0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 9.000 = 17.000
-0.111111 1.888889 -0.111111 1.888889 -0.111111 1.888889 -0.111111 1.888889 -0.111111 1.888889 -0.111111 1.888889 -0.111111 1.888889 -0.111111 1.888889 -0.111111 1.888889 -0.111111 1.888889
Ligne 1 S=-2.000000
Ligne 2 S=16.000000
Ligne 3 S=-2.000000
Ligne 4 S=16.000000
Ligne 5 S=-2.000000
Ligne 6 S=16.000000
Ligne 7 S=-2.000000
Ligne 8 S=16.000000
Ligne 9 S=-2.000000
Ligne 10 S=16.000000
Ligne 11 S=-2.000000
Ligne 12 S=16.000000
Ligne 13 S=-2.000000
Ligne 14 S=16.000000
Ligne 15 S=-2.000000
Ligne 16 S=16.000000
Ligne 17 S=-2.000000
Ligne 18 S=16.000000
Ligne 19 S=-2.000000
Ligne 20 S=17.000000
#181 Re : Programmation » A propos de langage » 05-08-2016 18:43:20
Et tu as pu examiner librement les sources de ce prog ?
Soit on t'a permis de consulter les lignes de code C++ directement, soit tu as pu décompiler ce Prog C++ s'il l'était déjà et dans ce cas je me demande si tu étais dans la légalité. En outre, je croyais qu'il était impossible de décompiler proprement des prog C ou C++ présentés sous forme d'un .exe ?
Je ne me souviens plus des détails, ce genre de chose, j'essaye de l'oublier très vite.
Il y a pas mal de logiciels de ce type qui sont en Open-Source.
En plus ton dernier sous-entendu est parfaitement désagréable.
Tiens, j'ai un exemple très précis qui me revient à l'esprit. Léon le connait bien, lors d'une discussion à propos de résolution de système linéaire, tout à fait dans le présent contexte, il m'en a donné un à résoudre (contre-exemple classique dont il se souvient certainement) Matlab ou Syslab se plantait lamentablement,c'est à dire donnait un résultat aberrant. Avec ma petite fonction, j'ai sorti un résultat acceptable.
Ceci est un exemple court, simple, parfaitement cerné, reproductible etc.
Sauf que la dernière affirmation est certainement contestable.
Tout est contestable. Par ailleurs, OpenClassRooms n'est pas une référence je retiens.
#182 Re : Programmation » A propos de langage » 05-08-2016 17:51:01
"La programmation de bas niveau permet de différencier tout cela, pas celle de haut niveau."
Une simple réponse. Avec un certain étonnement, j'ai vu un programme écrit en C++ (ie haut niveau), où justement tous les éléments géométriques étaient du même type, c'est à dire d'aucun type. Ce logiciel était "énorme" (de mémoire plus de 100 Mo). C'est en repensant à cet exemple, que j'ai cité ce point.
Pour le reste, toi et Léon avez raison, sauf sur un point, ce n'est pas parce que je me donne un délai de réflexion de 15 jours que je ne fais rien d'autre pendant ce temps là.
#183 Re : Programmation » A propos de langage » 05-08-2016 14:00:07
J'essaye de distinguer deux choses qui me paraissent bien différentes
1- l'analyse
2- la programmation.
Il est vrai que dans de nombreux cas, c'est le même individu (maintenant) qui réalise les deux opérations.
Dans un grand nombre de cas, en phase de formation, le programme à réaliser consiste à calculer une belle formule. La phase "analyse" est réduite à sa plus simple expression et malheureusement très souvent complètement oubliée. Je dirais pour simplifier "on cherche à savoir comment faire avant de se poser la question : que doit-on faire ?".
Concernant ta dernière question. Je vais prendre un exemple.
Je dois gérer un grand nombre d'objets. C'est à dire que j'ai à réaliser plusieurs opérations sur ces objets, par exemple, lecture, écriture, modification, relations entre eux, suppression etc.
En gros, j'ai deux choix possibles, soit faire une organisation de liste chainée, tableau de hachage etc., soit utiliser les classes existantes crées pour gérer ce type de choses.
Dans le premier choix, je sais exactement ce que je veux faire (je me suis accordé 15 jours de réflexion), donc je pouvais développer mon truc avec une économie et une efficacité maximum. Dans le second choix, je savais que les outils prévus, qu'on appelle de haut niveau, pouvaient réaliser bien des choses dont je n'avais pas besoin. Cela aurait entrainé une perte d'efficacité.
Par contre, lorsque l'efficacité n'est pas la préoccupation principale, mais plutôt le souci de me ménager, alors j'utilise des fonctions dite "haut niveau".
Un autre exemple typique, la librairie Stream qui gère les flux. Lorsque j'ai eu ma première version de C++, j'ai tout de suite essayé cela. Cela ne m'a pas convaincu, en ce sens qu'il n'y avait rien de tellement nouveau, seulement une écriture différente. Alors j'ai laissé tomber ces classes générales. Par contre, j'ai utilisé les nouvelles possibilités, particulièrement new/delete. Mais j'utilise encore alloc/free dans certaines fonctions. J'ai eu l'occasion de faire des tests de rapidité entre des impressions (sorties) avec fprintf() et la librairie ostream, c'est sans appel.
Autre aspect du problème. Dans ce qui me concerne, j'ai trois types d'éléments, le point, la ligne et l'objet. Pour simplifier, un point, sauf s'il a un Z ou qu'il sert dans une définition d'un élément (ligne ou objet) est parfaitement inutile. Une ligne est définie par des points, dispose de caractéristiques type couleur, et c'est tout. Un objet peut être utilisé pour définir différentes choses, par exemple un texte, un bitmap ou je ne sais quoi. La programmation de bas niveau permet de différencier tout cela, pas celle de haut niveau.
Tout ceci n'est bien-sûr que mon avis personnel. Je l'explique, mais je sais bien qu'il y a des gens qui ne sont pas d'accord.
#184 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 05-08-2016 11:56:21
Bonjour Yoshi,
Oh, je n'ai ni a être content, ni mécontent. Mais comme tu fais référence à mes appréciations, j'ai calculé la répartition de tes deux simulations.
Celle du message #132
Nombre de valeurs = 20 valeur minimale =64.00 valeur maximale=87.00
Rapport Emq/Ema = 1.23 Théorique = 1.25
Nombre = 20 Moyenne = 77.75 emq=6.31 ep=4.20
Celle du message #143
Nombre de valeurs = 20 valeur minimale =72.00 valeur maximale=87.00
Rapport Emq/Ema = 1.31 Théorique = 1.25
Nombre = 20 Moyenne = 77.60 emq=3.78 ep=2.52
On peut estimer que dans le premier cas 95% des résultats seront supérieur à 77.75 - 2*6.31 = 65.13 .
Dans le second cas 95% des résultats seront supérieurs à 77.60 - 2*3.78 = 70.04 .
Bonne journée.
#185 Re : Programmation » A propos de langage » 04-08-2016 18:48:59
Bonsoir Yoshi,
j'ai l'impression qu'on ne parle pas vraiment de la même chose.
Un langage sert à traduire une logique qu'on appelle algorithme en code compréhensible pas la machine.
Les petits programmes qu'on appelle quelque fois "script" sont généralement des exercices, des modules de calcul d'une jolie formule mathématique, brefs, des trucs ponctuels, limités qui ne serviront, en gros, qu'à leur auteur.
Ce dont j'essaye de parler, ce sont des choses beaucoup plus énormes. Par exemple, j'ai un programme qui comporte une centaine de modules, chacun contient des dizaines de fonctions, tout ça est interdépendant et il faut que ça marche. Alors, plus le langage est de bas niveau, meilleur sera le résultat. Je sais bien que actuellement la seule préoccupation se compte en sous. Ce n'est pas la mienne.
#186 Re : Programmation » A propos de langage » 04-08-2016 14:20:22
Bonjour Yoshi.
En C/C++ il y a aussi la notion de variable locale. Il existe aussi des variables globales. Il ne faut utilise ce type de variable que si on a de bonnes raisons pour le faire.
Il faudra que tu m'expliques un jour la différence entre un tableau et une liste. Un programmeur pour manipuler un tableau, la machine en est incapable à cause de son organisation strictement linéaire et séquentielle, c'est pourquoi les langages prévoient une interface.
En C un tableau s'écrit Tab[25][3] en Fortran IV Tab(25, 3).
En C pour créer un tableau on doit connaitre sa dimension. Si on ne la connait pas au moment de la compilation, on devra réserver de la mémoire par la fonction alloc(). Bien sûr, puisqu'on l'a réservée pas programme à l'exécution, il faudra la libérer par programme à l'exécution quand on n'en a plus besoin. Les debogueurs prévoient un méthode pour vérifier qu'il n'y a pas de "fuite mémoire", mais je ne laisserai jamais la machine nettoyer la mémoire à ma place (cf ramasse-miette).
Donc, pour la séquence def_triplet, on pourrait faire comme ça :
int population[338688][3]; // population est déclaré dans le bloc actif et sera supprimé à la sortie.
int SumNumber=2016;
int rang=0;
for (int i=0; i < SumNumber/3; i++)
{
for (int j = i; j < (SumNumber-i)/2 ; j++)
{
population[rang][0] = i;
population[rang][1] = j;
population[rang][2] = SumNumber - i - j;
rang++;
}
}
A noter que tout peut être écrit sur une seule ligne, mais c'est tout à fait déconseillé.
Il n'y aurait pas lieu de faire une fonction pour cette opération, puisqu'elle n'est réalisée qu'une seule fois.
Mais je crois qu'il ne viendrait à l'idée de personne de créer un tableau de 300000 triplets seulement pour en tirer 100 au hasard.
On en revient donc à la question de base : comment décrire l'algorithme ? Moi, je ne sais pas.
Autre hypothèse, la longueur du tableau est inconnue, alors, il faudra utiliser une écriture de la sorte.
La déclaration de population sera du genre
int population[][3];
Pour chaque triplet
population[rang][3] = (int*)malloc(sizeof(int) * 3);
A la fin
for (int k = 0; i< RangMax; i++) // RangMax aura été fixé à la fin de l'écriture du tableau.
{
free (population[k]);
}
[HS] J'aimerais bien savoir ce que pense Camille23 du problème évoqué. [/HS]
[EDIT] j'ai eu des soucis avec un 'i' entre crochets.
#187 Re : Café mathématique » Le nombre non autorisée » 04-08-2016 12:04:09
Bonjour Freddy,
Bien-sûr Extrazolve a raison, on a eu une démonstration il y a pas très longtemps, à l'occasion d'un jeu : suite à un tirage parfaitement aléatoire et à deux issues possibles exclusives, on a bien vu que il y avait une stratégie pour deviner la solution.
#188 Re : Programmation » A propos de langage » 03-08-2016 22:01:19
Bonsoir Yoshi;
Je réponds à ton dernier paragraphe. A part un cours d'informatique générale, j'ai toujours eu à "produire", donc aucun droit à l'erreur.
Tu sais, un jour j'ai eu un tél, dans le cadre professionnel, de quelqu'un qui m'expliquait que l'outil de calcul qu"il utilisait était comme-ci comme-ça, il se trouve que cet outil, je l'avais mis au point et donc mis en exploitation 10 ans avant, dans la centrale informatique d'Evry (c'était vers les années 77-76). Désolé, ce n'est pas mon habitude de donner des références.
Demain, je transpose avec toutes les justifications nécessaire le programme Python don on parle en code C, peut-être un peu de C++.
Bonne soirée.
#189 Re : Café mathématique » Le nombre non autorisée » 03-08-2016 21:44:56
Bonsoir,
C'est marrant votre discussion. Etant donné l'orthographe, on peut se demander si c'est une façon de vous cacher, ou votre méconnaissance de la langue française. Je penche pour la première hypothèse.
Je dois reconnaitre que l'idée est intéressante pour provoquer des discussions, mais il ne faut tout de même pas prendre les gens pour des imbéciles.
Donc, en un mot, je dirais "bien-sûr vous avez raison. Problème résolu."
#190 Re : Programmation » A propos de langage » 03-08-2016 19:21:48
Oui, D'accord demain je fais une transpo. du programme dont il s'agit.
Intellectuellement, c'est vraiment intéressant.
PM, je ne suis pas programmeur, mais géomètre. L'informatique est un outil que j'ai appris à utiliser.
Sur mon site, il y a quelques infos, qui datent de plus de 10 ans, mais toujours vraies.
#191 Programmation » A propos de langage » 03-08-2016 18:04:23
- Dlzlogic
- Réponses : 33
Bonjour Yoshi.
Pour éviter de faire du hors-sujet, j'ai ouvert on nouveau sujet.
J'ai bien aimé les échanges provenant de "commentcamarche", en particulier ceci
Après en général apprendre la programmation ne consiste pas a apprendre les différent type de langage, mais surtout à apprendre l'algorithme: ce qui fait ton programme, c'est l'algorithme. Ton programme en lui même est un algorithme. Quelque soit le langage que tu utilisera, cela reviendra au même.
Il y a une infinité de manière de faire un même algorithme, donc a toi de trouver la plus approprié et la plus efficace et de la retranscrire dans le langage de ton choix.
Cela m'amène à la réponse suivante. "Qu'importe le langage, l'important est de faire ce que l'on veut ou doit faire".
Donc, en toute bonne foi et de bonne volonté, j'ai essayé de transposer le code Python dont on parle dans le langage que j'utilise habituellement, en l'occurrence C/C++. Pour transposer, il fallait comprendre, donc écrire l'algorithme (ie. la suite logique des instructions dans ma langue maternelle). Ben j'y suis pas arrivé. J'ai bloqué d'abord sur l'absence de définition des variables. Je sais, je suis de la vieille école mais j'aime bien savoir à qui j'ai affaire, ce que je traite etc. Je prends l'exemple suivant :
return [(i,j,SumNumber-i-j) for i in range(1, SumNumber//3 + 1) for j in range (i, (SumNumber-i)//2+1)]
/* Unique appel dans le programme */
population = get_triples()
Donc on peut en déduire que "population" est un tableau, puis que ailleurs on trouve "len(population)".
J'ai pas eu trop de mal à trouver la signification de range(int, int)
Ensuite, le tableau renvoyé est-il de dimension 1 ou 2 ? Que veut dire '//' (jamais vu ailleurs) etc.
Donc, j'ai été incapable d'écrire l'algorithme, à fortiori, incapable de transposer.
Par ailleurs, lorsque je lis des échanges entre programmeurs et que A dit "ça marche pas" B répond "quelle version as-tu ?" A dit "version 2" B répond "2b est mieux, rangen fait cela maintenant par défaut" etc. Alors, je me sauve en courant.
Par ailleurs, suite à des demandes insistantes, j'ai dit qui était l'auteur de l'avis sur Python ...
ET je n'ai jamais dit que c'était parole de vérité. C'est un avis.
Sur un plan plus général, je préfère les langages compilés pour un certain nombre de raisons. J'ai été un peu dérouté quand j'ai fait du PHP. Le manque de compilation supprimait un contrôle qui me parait important.
De toute façon la comparaison C vs Python est sans objet.
Bonne journée.
#192 Re : Café mathématique » Géométrie à la surface de la Terre » 03-08-2016 13:27:46
Bonjour,
Votre simulation est très jolie.
Pour le reste, oui, je compatis, c'est frustrant.
#193 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 03-08-2016 12:40:27
Bonjour Yassine,
Ne nous fâchons pas. Pour faire simple, je n'ai pas trouvé d'où venait le premier triplet (466,475,475) de la liste "solution", ni dans ton explication, ni dans le code.
D'autre part l'explication de Camille sur l'utilisation du terme de l'énoncé "hasard" me parait tout à fait convaincante, puisque j'ai fait la même approche. Mais encore une fois, ceci est un détail par rapport à la question "comment définir la stratégie de l'homme ?"
Donc ta stratégie consiste à éliminer des triplets "perdants" pour ne garder que les 100 meilleurs de ceux qui restent. C'est ce qui est écrit à la fin de ton PDF.
Après une lecture plus approfondie, et une ou deux pages plus loin, on trouve le message #81 qui donne le code ayant servi à construire la liste des 100 triplets gagnants. Il ne vient pas à l'esprit directement que ce code est antérieur qu code donné au message #43.
Bonne journée.
@ Tibo. Freddy a indiqué qu'il ne connaissait pas la solution. VRAI.
Par contre manifestement il connait l'auteur. D'ailleurs, je ne pense pas qu'il aurait proposé un exercice s'il ne peut pas donner la solution.
#194 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 02-08-2016 21:49:06
Bon, c'est tout de même assez marrant. Il y a eu pas mal d'échanges. j'ai fait une proposition de stratégie, complètement fausse, mais personne n'a rien dit.
Puis Yassine a produit une liste de triplets sans préciser la méthode de fabrication. Naturellement pour tout lecteur, cette liste a été copiée d'on ne sait où.
Bref quelque soit le bout d'où on le regarde l'exercice proposé par Freddy est résolu. Par contre, personnellement j'aimerais bien avoir la correction officielle.
Léon, je répondrai toujours de la manière la plus posée possible. Je sais très bien que ta seule préoccupation, concernant cette question, est de tenter de me faire dire quelque-chose qui pourrait être jugée comme incompatible avec la charte du présent forum.
Je te rappelle que concernant le présent exercice proposé par Freddy je n'ai pas à me justifier de quoi que ce soit. Il me semble que la seule chose que j'ai dite et qui puisse être à discuter est "Comment démontrer ?"
Concernant le côté strictement mathématique, il me semble que la différence de résultat entre 75% et 80% (environ) provient uniquement du fait de la façon de comprendre le terme de l'énoncé "au hasard". Je rappelle qu'un membre a insisté sur ce point. Cependant je tiens à ajouter que ce point précis est un détail mineur concernant l'élaboration de la stratégie de l'homme.
#195 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 02-08-2016 20:43:14
On se trompe de problème.
L'énonce de Freddy est très clair et précis.
La liste de Yassine est bonne, OK tout va bien.
J'ai produit ma propre méthode, problème résolu, passons à autre chose. J'insiste passons à autre-chose.
Pour répondre de façon précise à ta question précise, j'ai vérifié que la liste de Yassine, dont on ne connait pas vraiment l'origine, respecte les conditions de l'énoncé.
Par ailleurs, les simulations m'ont permis de vérifier que le gain de l'homme était supérieur à 80% pour un tirage aléatoire, alors que si on fait un tirage sélectif, par tranche, selon ta méthode qui ne correspond pas à l'énoncé, on est autour de 75%. C'est la seule raison pour laquelle j'ai parlé de simulation pour "vérification".
Pour simplifier, en respectant l'énoncé, on arrive à 80%, avec certains calculs on arrive à 75%. D'ailleurs un visiteur a bien mis le doigt sur le problème. Alors, la question est réglée, POINT.
Le seul point sur lequel je me permets d'insister : le corrigé officiel du rédacteur.
#196 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 02-08-2016 19:31:49
@ Léon, de mémoire, j'ai vérifié que tous les triplets étaient différents et ... je sais plus quoi.
Par contre, je ne sais pas comment elle a été faite. Si tu le sais, je veux bien que tu m'expliques.
#197 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 02-08-2016 19:13:38
Bon, donc tout va bien.
Cela resterait intéressant de voir la correction officielle de l'auteur de l'exercice.
En tout cas, merci à Freddy, c'était un truc vraiment bien.
#198 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 02-08-2016 18:52:58
@Léon,
Ca y est, c'est corrigé.
Mais, de mémoire, la vérification ne faisait pas partie de l'énoncé, et quand j'en ai parlé, on m'a regardé de travers.
Si tu veux une bonne liste, regarde celle de Yassine, je l'ai vérifiée, elle est bonne.
Pour mémoire, dans mon code, j'ai rétabli le tirage au hasard, aux erreurs près.
Comment démontrerais-tu que la moyenne est supérieure à 75 pour 100 parties ?
#199 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 02-08-2016 17:42:21
@Léon
Voilà, j'ai fait ta modif, ça donne ça.
Méthode Dlzlogic TgagneX = 2249 TgagneY = 7751
Méthode Dlzlogic TgagneX = 2322 TgagneY = 7678
Méthode Dlzlogic TgagneX = 2275 TgagneY = 7725
Méthode Dlzlogic TgagneX = 2296 TgagneY = 7704
Méthode Dlzlogic TgagneX = 2256 TgagneY = 7744
Méthode Dlzlogic TgagneX = 2190 TgagneY = 7810
Méthode Dlzlogic TgagneX = 2267 TgagneY = 7733
Méthode Dlzlogic TgagneX = 2307 TgagneY = 7693
Méthode Dlzlogic TgagneX = 2249 TgagneY = 7751
Donc, un peu plus de 75%
"La machine écrit sur une bande de papier trois nombres entiers positifs pas nécessairement distincts x1≤x2≤x3 tirés au hasard et dont la somme x1+x2+x3=2016 . "
Il est dit "au hasard", et il est ajouté que les nombres ne sont pas nécessairement distincts. Mais tout ça n'est qu'un détail.
On aurait très bien pu tirer 2 nombres sur 1 à 2014, et si la somme ne dépasse pas 2015, en déduire de 3è nombre, sinon on recommence.
#200 Re : Enigmes, casse-têtes, curiosités et autres bizarreries » Peut - on battre le hasard ? » 02-08-2016 17:24:11
@ Tibo,
Il me semble que c'est la première fois que je fais une citation sans donner de façon précise mes sources. De façon précise c'est à dire que je cite les auteurs et qu'ils ont une compétence incontestable en la matière.
Si tu as un exemple contraire, dis-le, j'essayerai de préciser et de justifier.
Contrairement à ce que tu sembles sous-entendre, s'il peut m'arriver de me tromper, je ne dis jamais sciemment des choses sans en être parfaitement sûr et d'être tout prêt à le prouver, ou à rectifier si je me suis trompé.