Ppignol

Bienvenue sur Wikipédia, Ppignol !
Wikipédia est un projet international de rédaction collective d'encyclopédie développé actuellement dans plus de 250 langues différentes.
	Si vous désirez vous investir dans ce projet passionnant, vous êtes le bienvenu. Tous les contributeurs de Wikipédia vous invitent à corriger et développer les articles existants et à participer aux projets thématiques. N'ayez aucune crainte d'abîmer l'encyclopédie : toutes les modifications sont suivies par des contributeurs plus expérimentés qui pourront corriger vos éventuelles erreurs. Ne vous offensez pas de ces interventions, ni des messages destinés à vous aider à comprendre le projet et ses règles. Suivez leurs conseils et n'hésitez pas à demander calmement plus d'explications.
	Lorsque vous contribuez, gardez à l'esprit que Wikipédia est un projet d'encyclopédie universelle, il faut donc veiller à respecter un point de vue neutre et vérifiable. De plus, le contenu doit rester conforme à notre licence d'utilisation libre (GFDL). Les utilisateurs travaillent en harmonie et privilégient la discussion aussi courtoise que possible pour régler les oppositions, aussi, prenez le temps de vous habituer. N'essayez pas d'en faire trop au début : Wikipédia est un dédale où il est facile de s'égarer ! Un efficace « Service de Parrainage Actif » peut vous mettre en contact avec des anciens prêts à vous guider dans vos débuts. Pensez à vous présenter également sur votre page d'utilisateur, ce qui nous permettra de connaître vos centres d'intérêt et de mieux vous guider vers les divers projets thématiques. Bien qu'il s'agisse d'un travail de rédaction complexe, résultant de l'action de plusieurs dizaines de milliers de contributeurs francophones du monde entier, sa philosophie peut être résumée en quelques mots : « N'hésitez pas à l'améliorer ! ».
	Au cours d'une discussion, n'oubliez pas de signer vos messages, à l'aide de quatre tildes (~~~~) ou du bouton présent en haut de la fenêtre de modification ; il est par contre interdit de signer lorsque vous modifiez des articles mais l'historique permet de retrouver toutes vos contributions.

Pages utiles

• Tout l'indispensable, à lire absolument,

Pour poursuivre, vous pouvez trouver des éclaircissements à partir des pages :

• Aide:Sommaire, plus complet, pour plus tard…
• Aide:Syntaxe, des conventions d'écriture à connaître,
• Aide:Poser une question, si vous vous sentez perdu.

Vous pourrez ajouter par la suite d'autres pages d'aide ou les informations dont vous pensez avoir besoin dans votre espace utilisateur.

Bonnes contributions ! Stef48 14 mai 2008 à 09:59 (CEST)

Petite ébauche de développement objet en ANSI C

J'ai créé ce projet pour pouvoir développer en Objets en ANSI/ISO C (K&R C) http://sourceforge.net/projects/oooac/

respect des règles de Wikipédia

/* Comme cela ne marche pas en français, j'essaye de communiquer avec vous dans un autre langage */

wikipedia.UsePdDAsForum (Ppignol);

JCB.Warn (Ppignol);

PPignol.Ignore (JCB);

if (! wikipedia.respect_des_regles (Ppignol)) {

   Ppignol.WillBeBlockedBy (administrator);

}

Ppignol.AlertLevelIncrement ();

--Jean-Christophe BENOIST (d) 6 juin 2009 à 00:54 (CEST)

Je ne comprend pas bien, c'est du java ou du c++ ? Non, parce que si c'est du c++ je préfère les pointeurs parce-que ça évite les buffer overflow.

Au fait, je ne comprend pas pourquoi vous utilisez un framework français et un autre anglais...

Cordialement

Ppignol (d) 10 juin 2009 à 11:48 (CEST)

Une page de discutions est un forum, elle à été créée pour délester la page d'article de toute discutions sans pour autant vouloir interdire le débat.Ppignol (d) 11 juin 2009 à 16:27 (CEST)

Oui, mais elle est là pour débattre des modifications/améliorations à apporter à l'article, pas pour débattre "autour du sujet" sans but précis. Pour cela, il y a les pages de discussion utilisateur (où je vois un débat ci-dessous, et c'est très bien !). Pour l'instant, je n'ai toujours pas la moindre idée (et Jamian non plus, je viens de le voir) des modifications ou amélioration que vous voulez apporter à l'article, et globalement "ou vous voulez en venir" pour l'article. Vous ne faites pour le moment que apporter votre opinion et étude personnelle sur le sujet, très discutable, et ne correspondant à ma connaissance à aucun travail connu (et reconnu) sur ce sujet. Je vous rappelle que les travaux inédits ne sont pas acceptés sur Wikipédia. --Jean-Christophe BENOIST (d) 11 juin 2009 à 17:03 (CEST)

J'ai un but précis : vous faire enlever les deux passages qui parlent plus ou moins explicitement de boucles infinies dans l'article. Si vous avez des difficultés pour retrouver les passages en question c'est que vous n'êtes pas développeur (ce que je peux comprendre, personne n'est parfait... ;D ) alors arrêtez de vouloir me donner des cours sur un sujet que vous ne maitrisez pas complètement.--Ppignol (d) 19 juin 2009 à 00:25 (CEST)

Ah ! Enfin. Voilà qui est clair. Ce que vous entendez faire supprimer est la manière standard de présenter et de prouver ce problème, que l'on trouve dans une infinité de sources. Si vous connaissez une preuve qui ne fait pas intervenir de boucle infinie (et bien entendu vérifiable dans une source convaincante), cette modification sera bienvenue dans l'article. D'une manière générale, toute modification de l'article devra être dûment sourcée afin de rendre injustifié tout soupçon de travaux individuels. Je vous suggère également la lecture de Portail:Sciences/Charte_du_contributeur_en_science_sur_Wikipédia, et particulièrement l'article 3. --Jean-Christophe BENOIST (d) 19 juin 2009 à 00:40 (CEST)

Le problème c'est que la "manière standard" prend le problème à l'envers. Le but du jeu n'est pas de savoir si un ramasse-miette peut optimiser un code avec une boucle infinie, on l'a vu ce n'est pas dans ses attributions puisque une boucle infinie est un bug et qu'un ramasse-miettes n'a pas à optimiser les bug. Je pense que le cas du castor affairé est révélateur. La complexité de ces traitements induit une explosion combinatoire qui rend difficile voir impossible de déterminer à l'avance quand l'algorithme vas s'arrêter (et de fait si il s'arrête) au delà d'une certaine combinaison de données d'entrées/traitements et par là même déterminer si l'algorithme répond aux spécifications du castor affairé. En fait théoriquement le programme à été écrit de manière à ce qu'il puisse s'arrêter un jour. Cependant sur un jeu de données d'entrées/traitements opérants, il n'est pas forcément possible de déterminer précisément en combien d'étapes le programme arrêtera son traitement. Je suis pas sûr d'être très clair mais pour faire simple c'est comme un automate cellulaire. C'est un automate qui peut s'arrêter, cependant avec un jeu de règles différent on peut influer sur la durée et la complexité des résultats (on peut même arriver à rendre les constructions de l'automate intelligentes (voir machine de Turing en automate cellulaire sur google (anglais))). On peut aussi rendre le traitement infini car on peut faire en sorte que la construction de données d'entrée fasse en sorte que le traitement ne s'arrête jamais. Cependant dans le cadre du jeu du castor affairé l'article 4 de la règle stipule expressément que les instructions de l'automate avec le jeu de donnée fournis doivent obligatoirement s'arrêter. Cela est paradoxal par rapport au but du jeu qui demande de réaliser le maximum de transitions possible avant de s'arrêter. Voila pourquoi il est impossible de décider du problème de l'arrêt. L'explosion combinatoire ne permet pas de déterminer précisément dans tous les cas en combien d'étape un programme vas s'arrêter à la seule lecture de son code et avec un jeu de données d'entrée fourni. Il n'a jamais été question de savoir si la variable X doit être ramassé avant tel ou tel traitement par le ramasse-miettes. Cela induit aussi qu'il ne sera jamais possible de prouver qu'un algorithme ne contient pas de bug, par contre rien n'interdit de dire qu'une construction algorithmique donnée (ex: while(true);) n'aboutira pas obligatoirement à un bug(comprenez par là "if(code == "while(true);"){throw exception(string("'while(true);' est un bug."));}). Rien n'interdit non plus de chercher à éviter les comportements risqués, j'entend par là une préparation méticuleuse du travail de conception avec le méthodes fiables qui ont fait leurs preuves. Une certitude qui viens de mon experience est qu'une base de donnée conçue grâce à la méthode MERISE sera plus robuste qu'une base développée grâce à UML (ou tout autre méthode de conception). De même un logiciel sera plus robuste et plus facile à maintenir si l'on respecte à la lettre, la théorie objet et qu'on le conçoit sous UML que si on le concevait sous MERISE (ou tout autre méthode de conception). Cependant ces méthodes ne permettent pas de garantir une erreur de compréhension ou un mal entendu de la par de la personne qui vas spécifier et/ou écrire le programme. Encore une fois ce n'est pas dans les prérogatives de ces méthodes. --Ppignol (d) 20 juin 2009 à 01:09 (CEST)

Le problème de l'arrêt a pour but de montrer qu'il n'existe pas d'algorithme pour déterminer si un programme s'arrête ou non. Ou, pour reprendre votre propre terminologie, pour déterminer si un programme appartient au domaine de définition de la machine de Turing employée, ou encore, si l'on veut, pour déterminer si un programme est buggué ou non. La "manière standard" est de supposer que cet algorithme existe (HALT, supposé non buggué = qui s'arrête toujours) et d'exhiber un programme (volontairement buggué) TROUBLE qui aboutit à une contradiction sur le fonctionnement de HALT, ce qui établit que HALT ne peut exister, CQFD.
Il est parfaitement autorisé de donner à HALT des programmes buggués (puisque son but est de déterminer si un programme est buggué ou non), donc je ne vois pas pourquoi vous vous scandalisez de voir une boucle infinie dans TROUBLE.
Je vous accorde que la démonstration serait encore plus impressionnante si TROUBLE n'était pas trivialement bugguée, mais elle ne serait ni plus vraie ni plus fausse.
En ce qui concerne maintenant le ramasse-miette (sur lequel vous passez beaucoup de temps de discussion), je suis quelque peu de votre côté, et je trouve que ce n'est pas une très bonne illustration du problème de l'arrêt. Le ramasse-miette est un problème d'informatique pratique, et - tout comme il peut exister en pratique d'excellents compresseurs assez universels (zip etc..), alors que on peut démontrer qu'ils n'existent pas en théorie - on peut estimer qu'il pourrait exister de bon algorithmes de ramasse-miette en pratique (sur des programmes bien analysés, non buggués, etc..) même s'ils n'existent pas en théorie. J'ai l'impression qu'une grande partie de la discussion tourne autour de cela. Mais cela ne remet nullement en cause ni la validité, ni l'intérêt, du résultat théorique initial.
Donc : il ne faut pas trop se concentrer sur le problème pratique du ramasse-miette. Le sujet de l'article est le problème de l'arrêt, non le ramasse-miette, et ce sujet n'est remis en cause par aucune des considérations que vous avez émises. --Jean-Christophe BENOIST (d) 20 juin 2009 à 12:37 (CEST)

Le problème est que le cas de la boucle infinie est trop trivial. Ne pas oublier que le problème de l'arrêt se pose dans le cadre de l'"analyse statistique de programmes" or il est évident qu'un programme qui contient une boucle infinie (type "while(true);") est par définition buggé et que ce problème est détectable. Or le but de l'analyse statistique des programmes est de montrer si oui ou non un programme est "statistiquement" buggé en ne faisant que lire son code. Comme le cas est flagrant l'analyse répondra que le programme à une probabilité de plantage de 33% (rapport aux 100% / 3 chemins de codes possibles) du coup le programme est buggé et donc on peut détecter ce problème avec un programme qui ne ferais que lire le code sans chercher à tester un jeu de valeurs. Cela implique que l'exemple est un contre exemple vu qu'il est possible de le détecter en lisant simplement le code. Donc le cas du castor affairé (ou un automate célulaire) me parait plus démonstratif car il est impossible de savoir à la seule lecture du code sans exécuter un jeu de données si le programme s'arrête ou non car cela vas dépendre du jeu de données fournis. et la on peut vraiement dire CQFD.

En ce qui concerne la théorie je n'ai rien à redire par contre pour le ramasse miette c'est une application concrète de la théorie et tout ce qui est hors champs de la théorie ne peut lui être appliqué c'est tout. Enfin regardez l'autre discution en bas j'en ai suffisamment parlé, je crois. :) --Ppignol (d) 20 juin 2009 à 14:30 (CEST)

Je ne suis pas sûr du tout que, dans le cas du castor affairé, il ne soit pas possible de déterminer - par analyse statistique ou en examinant humainement le programme - que le programme va finir par s'arrêter. Ce n'est pas parce que on ne peut pas calculer après combien d'étapes un programme va s'arrêter que on ne peut pas voir que le programme va s'arrêter. Je dirais même que, étant donné la règle 4 du castor, on DOIT voir et démontrer que le programme va s'arrêter. Il est donc tout à fait plausible que HALT arrive à déterminer à tous les coups qu'un programme "castor affairé" va s'arrêter (même s'il ne dira jamais après combien d'étapes). De toutes manières, si vous voulez inscrire dans l'article que l'approche "castor affairé" est plus pertinente pour traiter le problème de l'arrêt, alors il faut - encore une fois - une source, que j'attends toujours de votre part. De manière générale, toutes ces discussions seraient plus instructives et plus productives si nous nous référions à des ouvrages connus. --Jean-Christophe BENOIST (d) 20 juin 2009 à 16:45 (CEST)

Si je devais dénombrer tous les livres de ma bibliothèque et tous les sites qui me servent de références j'en aurais pour 6 mois à tous les écrire. De plus en ce qui concerne le "castor affairé" et l'"analyse statistique des programmes", je me sert, entre autre, de Wikipédia.

Une analyse humaine n'est pas un moyen valable de vérifier.

Le castor affairé doit s'arrêter (règle 4) certes mais une analyse d'un code (sans jeu de donnée) ne permet pas de dire quel comportement aura l'automate et donc ne permet pas de connaitre en combien de temps il s'arrête et par extension si il vas s'arrêter puisque justement le comportement de l'automate va varier en fonction de ses données d'entrées et c'est en cela que le théorème de l'arrêt prend tout son sens. De plus étant donné qu'il y à une infinité d'algorithme de castor affairé (tous meilleur les uns que les autres), il est impossible de déterminer le meilleur castor affairé(l'infini n'étant pas accessible : dès qu'un meilleur castor est découvert, un autre castor encore meilleur est découvert).--Ppignol (d) 20 juin 2009 à 21:46 (CEST)

De l'utilité du problème de l'arrêt, du théorème de Rice et de l'indécidabilité

Je vais essayer de faire simple : -Vous vous mettez en tête de concevoir un algorithme qui permettrait de déterminer si un programme est buggé par rapport à une spécification quelconque. Un tel algo prendrait en entrée ledit programme et ladite spécification. -De deux choses l'une : soit vous vous foutez complètement de ce que disent ces articles, et vous perdez temps et argent à vainement essayer de mettre au point cet algorithme génial, paradis pour tout ceux qui veulent certifier leur programme à moindre coût ; soit vous vous penchez sur la théorie et vous apercevez que c'est impossible dans le cas général, et vous passez à autre chose.

Il en va de même pour TOUS les problèmes entrant dans le champ d'application du théoème de Rice (et je parle bien de PROBLÈME ! pas d'algorithme, étant donné que s'il existe un algorithme capable de répondre à un problème, il en existe alors une infinité). Ce théorème précise donc qu'il est totalement illusoire de vouloir créer un garbage-collector parfait, un détecteur de fuites mémoire idéal, etc.

Vous faites la confusion classique entre un problème (associant un ensemble de paramètres à une question. Par exemple : (Graphe G, Sommet A, Sommet B) -> "Quel est le chemin le plus court reliant A à B dans G ?" ) et un algorithme (pour faire simple, suite d'instructions permettant de résoudre un problème donné. Par exemple, l'algorithme de dijkstra permet de répondre au problème cité précédemment).

Vous faites aussi la confusion entre un algorithme (dont les instructions et branchements le constituant ont une sémantique bien définie, indépendante de toute implémentation sur un matériel donné. Il s'agit en fait ni plus ni moins qu'un mode opératoire pour calculer une fonction.) et l'exécution d'un morceau de code sur une machine : partant par exemple d'un algorithme écrit en C, il faut se poser plusieurs questions : -L'algorithme résout-il bien le problème voulu ? (travail en amont, on va considérer que oui) -Le code assembleur généré par mon compilateur correspond-il bien exactement à la sémantique de mon programme en C ? (gcc n'est pas formellement certifié pour aucune des architectures qu'il utilise. Je pense que c'est la même chose pour les compilos Intel ou Microsoft. en tout cas, je n'ai pas vu passer le papier le prouvant). -mon processeur se comporte-t-il bien toujours exactement conformément à sa spécification ?

Si une seule des réponses n'est pas un OUI formel, il est strictement inutile de se baser sur cette implémentation pour prouver quoi que ce soit concernant l'algorithme. D'où l'utilité de ne pas descendre à ces niveaux, et de formaliser correctement un algorithme. La notion de "bug" est ensuite une simple propriété à définir...

Jamian (d) 10 juin 2009 à 15:29 (CEST)

1) Je ne me met pas en tête "de concevoir un algorithme qui permettrait de déterminer si un programme est buggé". Je ne fait qu'affirmer qu'un programme qui boucle indéfiniment sans possibilité d'arrêt est bugé donc hors domaine de définition de l'application des machines de Turing et inutile pour l'homme.

2) "Il en va de même pour TOUS les problèmes entrant dans le champ d'application du théoème de Rice". J'affirme qu'un problème qui entre dans le champ d'application du théorème de Rice est hors domaine de définition d'une machine de Turing. Machine qui ne peut décider les applications du théorème de Rice.

3) "s'il existe un algorithme capable de répondre à un problème, il en existe alors une infinité". Certes mais j'affirme qu'un seul est optimal pour un ensemble de contraintes données.

4) "Ce théorème précise donc qu'il est totalement illusoire de vouloir créer un garbage-collector parfait, un détecteur de fuites mémoire idéal". J'affirme qu'un garbage-collector parfait / un détecteur de fuites mémoire idéal existe si et seulement si il répond à tous ses cas d'utilisations de manière optimale sur le domaine de définition d'une machine de Turing. Les cas de boucles infinies ne faisant pas partie du domaine de définition des machines de Turing elles ne font pas parties du domaine de définition des garbage-collector / détecteur de fuites mémoire. On ne peut donc pas leurs demander de décider un problème indécidable sur le domaine de définition(voir aussi point 9).

5)"-L'algorithme résout-il bien le problème voulu ? (travail en amont, on va considérer que oui)". Il ne faut pas considérer mais être sûr. Je suis sûr de mes applications car je modélise mes applications via des techniques qui mettent en évidence les défaut de conceptions s'il y en à. De plus je ne sort pas du domaine de définition des machines de Turing.

6)"-Le code assembleur généré par mon compilateur correspond-il bien exactement à la sémantique de mon programme en C ? (gcc n'est pas formellement certifié pour aucune des architectures qu'il utilise. Je pense que c'est la même chose pour les compilos Intel ou Microsoft. en tout cas, je n'ai pas vu passer le papier le prouvant).". Effectivement aucun compilateur n'est certifié car tous les compilateurs font des optimisations plus ou moins arbitraires. Ceci implique l'impossibilité de certifier un compilateur pour créer un logiciel. De plus les systèmes d'exploitations comportent des bug qu'il faut corriger pendant cette phase, cela implique des modifications de codes... . Mais ce n'est pas ce sur quoi je conteste.

7)"-mon processeur se comporte-t-il bien toujours exactement conformément à sa spécification ?". Si ce n'est pas le cas c'est une erreur humaine corrigible. Cela veut dire que le constructeur n'a pas respecté ses propres spécifications. Mais ce n'est pas ce sur quoi je conteste.

8)"Si une seule des réponses n'est pas un OUI formel, il est strictement inutile de se baser sur cette implémentation pour prouver quoi que ce soit concernant l'algorithme. D'où l'utilité de ne pas descendre à ces niveaux, et de formaliser correctement un algorithme.". L'utilité de descendre à ces niveaux est de prouver la théorie et donc de confirmer son substrat soit le domaine de définition de la théorie. Sans domaines de définitions, il n'y à pas de théorie. Si on en reste à la théorie, il faut supposer que les machines de Turing sont idéales(donc non bugées contrairement aux processeurs). Il n'en reste pas moins que les applications du théorème de Rice, donc les algorithmes qui traduisent le théorème sur les machines de Turing sont hors domaines de définitions, par conséquent non décidables et donc non définissables sur les machines de Turing. Si on essais de faire le contraire cela revient à dire que la fonction f(x)=x/(x-1) à une valeur définie pour x = 1 ce qui est faux car à x = 1 la fonction est non définie (ensemble vide).

9)"La notion de "bug" est ensuite une simple propriété à définir..." : Je définis la notion de "bug" comme étant toute application du théorème de Rice et tout problème indécidable sur une machine de Turing car ils sont hors domaine de définitions. La thèse de Church-Turing défend cette position en définissant comme hors domaine de définition pour les machines de Turing tout ce qui n'est pas mathématiquement décidable. Le théorème de Rice en fait autant en disant que toute propriété non triviale est indécidable sur une machine de Turing. Par conséquent il n'y à pas lieux de calculer ces problèmes dans des compilateurs, ramasses miettes ou détecteurs de fuites mémoires qui traitent, eux, des problèmes décidables par les machines de Turing puisque que ce sont des applications fonctionnant sur et pour les machines de Turing et dans le domaine de définition des machines de Turing.

Cordialement.

Ppignol (d) 11 juin 2009 à 13:46 (CEST)

1) et 2) J'énonçais ceci comme étant une supposition. On peut reformuler en "Si quelqu'un veut faire un garbage-collector parfait, alors il a intérêt à lire cet article, car c'est impossible". Le "domaine de définition des machines de Turing" ne peut contenir des problèmes, mais des algorithmes. L'ensemble des problèmes que vous tentez de définir est l'ensemble des problèmes décidables, tout simplement. Et par définition, il n'existe pas d'algorithme (au sens des machines de Turing) pour résoudre de tels problèmes, ce qui, si je comprends bien, correspond à ce que vous voulez dire (même si vous le dites de manière non formelle).

3) Même pas : d'une part, ça dépend de la notion d'optimalité (en temps ? en mémoire ?), d'autre part, si on considère par exemple les algorithmes de tri, un simple tri à bulles sera plus rapide sur des petites instances, alors qu'un tri en O(n*log(n)) est bien entendu plus rapide sur des instances plus importantes. De plus, il y a plusieurs algorithmes de tri en O(n*(log(n)) (tri par fusion, quicksort, etc.). Notez bien qu'un algorithme qui analyserais l'instance avant d'appliquer le bon tri ne serait pas "optimal", du fait de l'overhead causé par l'analyse, justement. Notez bien d'ailleurs que si votre "ensemble de contraintes donné" réduit à un ensemble fini votre ensemble d'instances, alors l'"algorithme optimal" ne résout pas un problème, mais se contente de rechercher la réponse dnas un dictionnaire d'instances.

4) Ben, oui, encre une fois, c'est exactement ce qui est dit : il n'existe pas d'algorithme pour. Conclusion : avant de se lancer dans l'élaboration d'un algorithme complet pour résoudre un problème, il faut regarder si toutefois le problème est décidable. En cela, le théorème de Rice est très puissant, car la caractérisation qu'il donne est très facile à vérifier.

5) C'est pour ça que je disais considérer que cette question avait déjà été répondue par un travail en amont : c'ets la seule question à laquelle il est possible de répondre oui de manière formelle.

6) sur ce point, il existe des compilateurs certifiés en C, en B et en ADA. (l'armée, les constructeurs aériens, et la RATP pour la ligne 14 en sont entre-autres très friands) Mais ceci nous éloigne du sujet...

7) Vous en mettez beaucoup sur l'erreur humaine. Pas mal d'éléments incontrôlables peuvent affecter l'exécution d'un proc (reste des composants du PC, émissions radioélectriques, etc.) Enfin, ceci nous éloigne aussi du sujet...

8) Non, il n'est pas nécessaire de descendre à des niveaux physiques pour prouver une théorie : si vous pondez un algorithme polynomial pour résoudre tel problème, vous n'avez pas besoin de l'exécuter pour savoir qu'il est polynomial. Si votre algo a telle ou telle propriété, il est inutile de passer par l'implémentation pour tenter de prouver cette propriété : cela relève de la déduction mathématique. D'ailleurs, cela nous ramène au théorème de Rice : celui-ci vous ôte toute garantie de réussir à prouver quoi que ce soit d'intéressant sur votre algorithme. Vous pouvez toujours essayer : si vous y parvenez, tant mieux, si vous ramez, rien ne vous dit que vous y arriverez un jour, car justement, toute propriété "intéressante" est indécidable.

9) en clair, vous définissez le bug comme un couple (algorithme, valeurs d'entrée) qui n'a pas d'image par la machine de Turing universelle. On peut utiliser cette définition, encore fallait-il le dire. Pour le reste, c'est exactement ce que l'article sur le théorème de rice, et celui sur le problème de l'arrêt dit...

Jamian (d) 11 juin 2009 à 16:53 (CEST)

A) (1 et 2) : Si quelqu'un veut faire un garbage collector parfait il ne prendra pas pour base le problème de l'arrêt car il est indécidable. Un garbage collector a pour fonction d'étudier que des algorithme et seulement des algorithmes traduisant les problèmes décidables. Par concéquent un algorithme traduisant un problème indécidable n'est pas un cas qu'il doit traiter.

B) (3) : L'optimisation des tris sont la fonction du développeur non celle du compilateur il n'a donc pas à se soucier de cette optimisation. Normalement c'est au développeur d'estimer la taille moyenne en production du jeu de données et de choisir le tri approprié par rapport aux contraintes de mémoire et de rapidité. Alors quand à l'analyse des instances du jeu de données... . Ce que je désignais par "ensemble de contraintes données" est l'architecture matérielle (jeux d'instructions, quantité de mémoire disponible, vitesse d'exécution du processeur et besoins de l'application en ressources et bien sûr spécifications définies dans un domaine décidable).

C) (4) : Désolé mais les problèmes indécidables n'étant pas dans les cas d'utilisation de l'algorithme de compilation, de l'algorithme du ramasse-miettes ou de l'algorithme de recherche de fuites de mémoires, les optimisations complètes de ces algorithmes sont atteignables.

• Les uses cases d'un compilateur dictent qu'il doit signaler tout traitement qui ne retourne pas (anti-boucles infinies).
• Les uses cases d'un ramasse miettes dictent qu'il doit considérer toute variable comme utilisés jusque au dernier acces (les cas de boucles infinie n'existant pas car sensé avoir été éliminé à la compilation).
• Les uses cases d'un détecteur de fuites dictent que si un pointeur, affecté par la création d'un espace en tas, est modifié ou détruit avant que le tas n'ait été détruit alors il doit le signaler au développeur.

Là où intervient le théorème de Rice c'est pour dire qu'il ne faut pas chercher à mettre dans les cas d'utilisations de ces algorithmes les cas indécidables. En bref il ne faut pas chercher à faire répondre "peut-être" à une machine qui ne sait dire que "oui" ou "non". Donc les algorithmes sont déjà parfaits si ils répondent au spécifications que je vient d'énoncer ce qui est aussi très facile à vérifier. En pseudo C++ : if(Problème_Indécidable_Incriminé = problème_indécidable(Code)){ throw exception("problème indécidable incriminé(boucles infinies, inter-blocage, etc...) : " + Problème_Indécidable_Incriminé)} else {return (bool)RésultatTraitementDuCode(Code) }

D) (5) : Si l'on peut répondre oui de manière formelle alors le pseudo algorithme de dessus ne n'executera jamais le "throw". Donc il n'y à jamais de problèmes indécidables soumis aux compilateurs applicables aux machines de Turing, Donc il n'y à pas besoins d'optimiser puisque le traitement est déjà parfait.

E) (7) : La plupart des bug sont dû à une erreur humaine, ou une erreur de spécification qui est par définition humaine.

F) (8) : Prouvez alors que la définition de 1 + 1 = 2 ou que celle de 1 - 1 = 0 (en système décimal bien sûr, pas en binaire), c'est un axiome improuvable car arbitrairement définit par l'homme correspondant à son contexte de travail et hors domaine de définition des mathématiques.

G) (9) a) : Oui tout à fait vous avez enfin compris. Un bug est le contraire d'un problème utile à l'homme soit un problème décidable et que les machines de Turing ne résolvent que les problèmes utiles à l'homme, alors tout problème indécidable est inutile à l'homme donc inexistant sur des machines de Turing. De fait on à pas besoins de les calculer.

H) (9) b) : C'est exactement ce que dit le théorème de Rice mais pas ce que dit le problème de l'arrêt puisque le couple (algorithme, valeurs d'entrée) exposé (notamment l'algorithme dans ce cas) est indécidable donc hors domaine de définition des machines de Turing et par conséquent inapproprié comme exemple.

Cordialement.

Ppignol (d) 12 juin 2009 à 02:34 (CEST)

ps: ravi de voir que j'arrive à me faire comprendre. Je commençait à désespérer.

A) Non, vous prenez le problème à l'envers : ce que dit le théorème de Rice, c'est que si un garbage collector parfait existait, alors il serait possible de résoudre le problème de l'arrêt (et donc de déterminer si un algorithme est "acceptable"). Qu'un garbage-collector n'ait pas à traiter un algorithme résolvant un problème indécidable est immédiat : un tel algorithme n'existe par définition tout simplement pas.

Pour reformuler, même sans l'intervention de paramètres inconnus (intervention de l'utilisateur, etc.), il est impossible de prédire avec certitude dans tous les cas si telle ou telle zone mémoire peut être libérée à un instant t sans risquer un segfault ultérieurement ou non.

B) C'est au développeur de choisir, et alors ? il n'en reste pas moins qu'il existe plusieurs tris optimaux (dans le cas général), et sans doute aussi si on réduit à un ensemble d'instances données, et ce même si on se cantonne à une architecture donnée.

C) "les uses cases d'un compilateur dicte qu'il doit signaler tout traitement qui ne retourne pas" -> si il existait un compilateur capable de répondre à cette règle, alors le problème de l'arrêt serait résolu, d'où contradiction (et c'est une application directe du théorème de Rice, étant donné que ça revient à détecter la propriété que vous avez appelé "bug", et qui est non-triviale). Il ne peut donc exister aucun compilateur répondant à cette règle (bien que certains cas triviaux puissent être détectés, comme un while(true) sans break à l'intérieur). Idem pour le problème du ramasse-miettes : Si vous pouvez détecter dans tous les cas le dernier accès à la mémoire d'une variable, alors vous savez résoudre le problème de l'arrêt, d'où contradiction.

Il y a un problème sur le sens des mots que vous utilisez : un problème peut être indécidable, un algorithme peut ne pas terminer. Ce sont deux notions bien distinctes : dans le premier cas, c'est un problème qui ne possède aucun algorithme y répondant dans tous les cas, dans le second cas, c'est un algorithme dont la fonction qu'il calcule (pris au sens général : on peut voir tout algorithme comme une fonction associant l'état final de la machine à son état initial) n'est pas définie pour toute entrée.

Par ailleurs, il ne s'agit pas de faire répondre "peut-être" à une machine : un algorithme appliqué à une entrée qui le fait entrer dnas une boucle n'a pas de réponse du tout. C'est comme si je vous pose "Quelle est la valeur de 1/0 ? ". La réponse n'est aps "peut être 1, peut être 2, ....", il n'y a pas de réponse.

D) Découle du C) : si vous arrivez à trouver un seul algorithme capable de faire ce que votre pseudo-code C++ fait, d'une part, vous rendrez un énorme service à toutes les boites de développement qui passent 90% de leur temps à trouver ce genre de bugs, d'autre part, vous aurez réfuté le théorème de Rice, donc le théorème d'incomplétude de Gödel, et donc vous aurez rendu l'arithmétique de Peano complète. Plus sérieusement, étant donné que le TIG est démontré, la première hypothèse est impossible.

F) Démonstration : Partant des axiomes de l'arithmétique de Peano, notons 1 le successeur de 0, et 2 le successeur de 1. Comme dans l'article, notons s(x) le successeur d'un élément x pour plus de clareté.

1+1 se réécrit donc s(0) + s(0).

Par l'axiome 5, s(0) + s(0) = s( s(0) + 0 )

Par l'axiome 4, s(0) + 0 = s(0), ce qui permet de réécrire la partie gauche de la ligne précédente en s(s(0)

donc, on a prouvé que s(0) + s(0) = s(s(0)) dans l'arithmétique de Peano. Ce qui, selon les notations que l'on s'est donné au début, s'écrit 1+1 = 2.

On peut faire une preuve du même genre en se donnant la théorie de l'arithmétique formelle, dont les axiomes sont énoncés dans l'article Cohérence des axiomes de l'arithmétique formelle,

G) : non, nous ne somme toujours pas d'accord : vous dites maintenant qu'un bug comme une propriété sur les problèmes, alors que je vous avais dit que je pensais que vous le définissiez comme une propriété sur les couples (algorithme, valeur d'entrée).

G) b) Relisez attentivement la page sur le problème de l'arrêt : il y est stipulé qu'il n'existe PAS d'algorithme pour le résoudre ! Pour reprendre vos propre termes (si informels fussent-ils), résoudre le problème de l'arrêt, ce serait, étant donné un couple (algo, valeur d'entrée), répondre à la question "Ce couple est-il hors domaine de définition des machines de Turing ?", ou bien "cet algorithme est-il un bug ?" (quoique, je vous prête peut-être encore une définition de bug qui n'est pas la vôtre, étant donné que vous appelez beaucoup de choses par ce terme...).

Dans la pratique, ce qui se fait, c'est qu'on développe des algorithmes qui restent dans un domaine très réduit en respectant des règles strictes afin de s'assurer qu'ils entrent bien dans la catégorie de ceux qui terminent. Cependant, la réciproque est très loin d'être vraie : ce n'est pas parce que l'on viole une de ces règles que l'algo va fatalement "boucler", très loin de là même !

Bien entendu, si en fait vous avez dans l'idée de vous restreindre aux algorithmes développés de manière à être sûr qu'il terminent (selon telle ou telle méthode de développement) , alors le problème de l'arrêt ne se pose pas, mais ce faisant, vous réduisez dramatiquement le pouvoir d'expression des machines de Turing. Jamian (d) 12 juin 2009 à 14:00 (CEST)

PS : J'espère que ce coup ci, vous aurez enfin compris certaines choses, car là c'est moi qui commence à désespérer...

1) (A) : 1) Le théorème de rice dit "toute propriété non triviale (c’est-à-dire qui n'est pas vraie ou fausse) sur la sémantique dénotationnelle d'un langage de programmation Turing-complet est indécidable" soit (selon ce que j'en comprend) si on à un résultat d'une fonction qui peut être strictement égal à "peut-être" alors le traitement de la machine de turing est indécidable (soit le résultat du comportement de la machine est = à l'ensemble vide). Je ne vois pas là dedans une allusion à un compilateur ou un garbage-collector mais plutôt aux limites de calcul de la machine de Turing qui ne peut calculer l'indécidable quel que soit le langage compatible que l'on souhaite utiliser donc pour moi c'est vous qui prenez le problème à l'envers.

1) (A) : 2) Ce que je ne comprend pas dans vos 2 premières phrases c'est que vous affirmez le contraire de ce que je dit puis exactement ce que je dit.

• "si un garbage collector parfait existait, alors il serait possible de résoudre le problème de l'arrêt (et donc de déterminer si un algorithme est "acceptable")"

que je ne partage pas car je considère que le problème de l'arrêt est hors définition est le contraire de

• "Qu'un garbage-collector n'ait pas à traiter un algorithme résolvant un problème indécidable est immédiat : un tel algorithme n'existe par définition tout simplement."

avec laquelle je suis totalement d'accord dans la mesure ou le problème de l'arrêt est inutile sur une machine de Turing car impossible à traiter.

1) (A) : 3) Si on élimine les cas indécidables, donc si on ne travaille que sur les cas Turing décidable, il est tout à fait possible de gérer les fuites de mémoire / les éffacages doubles en plaçant des Flags sûr les instances et en émulant tout les parcours possibles (en faisant semblan de passer par le if puis le else dans différents jeux d'essais c'est facile il n'y en à que 4 (oui-oui, oui-non, non-oui et non-non)) si le flag est effacé plus d'une fois il y à segfault et si il est créé plus d'une fois il y à fuites de mémoire. Cela ce fait déjà dans l'industrie.

2) (B) : ERRRRNNN ! Ce qui détermine le tri optimal c'est l'ensemble [Taille du jeu de donnée, mémoire dispo pour le tri, vitesses de traitement souhaitée] chose que seul le développeur et non la machine peut déterminer(compétence de la machine insuffisente). En fait le développeur joue le rôle de l'oracle pour ce problème précis et toutes les machines de Turing complet sont capable d'exécuter tous les tris.

3) (C) : (cf: voir le cas "1" de ma première réponse) Je ne dit pas que le compilateur détectera tous les "bug" je dit qu'il détecte déjà tous les bug de sémantique (Oublis d'incrément des variables de contrôles, variable de contrôle en dépassement de la borne en entrée de boucle, while(true) sans break ou return, ect...). Il est évident qu'il ne peut pas identifier les bug de logique car il n'a pas la connaissance des spécifications pour cela. Cela veut dire que les bugs de logiques doivent être traiter par le développeur en amont en fonction des spec de l'applis. Gödël identifie bien ce cas en nous disant "c'est pas la faute à la machine si tu lui dit de sauter par la fenêtre et qu'elle le fait, car elle est programmée pour faire ce que tu lui dit de faire alors corrige tes instructions au lieu de lui taper dessus". Et typiquement un bug de logique n'est pas toujours une erreur vue de la machine de Turing ou de ses cas d'utilisation. Ex : le programme " F(x){ return 3 + 2 * x;}" au lieu de " F(x){return 3 - 2 * x;}" est un bug que la machine de turing et donc son compilateur n'a aucun moyen d'analyser.

4) (D) Découle du C)) : je n'ai pas dit le contraire j'ai juste dit que "if(x == y) {return traitement_décidable()} else ( while(true);)" n'est pas un bon exemple car le compilateur devrais au moins avertir et au mieux ne pas compiler ce code.

5) (F) non vous ne répondez pas à ce que je demandais, je vous demandais (peut être maladroitement) de me prouver que 1 est bien le successeur de 0. Typiquement c'est indémontrable puisque cela tombe dans le théorème de Gödel.

6) (G) le couple (while(true)) n'est il pas un ensemble [code, données] dans "if(x == y) {return traitement_décidable()} else ( while(true);)" ?

7) (G) b) : MAIS JE NE VEUX PAS LE RÉSOUDRE, JE VEUX JUSTE DIRE QUE L'EXEMPLE N'EST PAS BON ET dire qu'il y à des algorithmes qui traitent déjà certains cas indécidable triviaux. Je veux aussi dire que les cas non triviaux sont plus le problème de l'homme que celui du compilateur et par conséquent je dit au développeur (et au matheu) "regarde la poutre qui est dans ton oeuil avant de critiquer la paille qui est dans celui de la machine de Turing car si t'avais fais ton boulo ça partirait pas en couille et c'est pas la faute à la machine apprend l'uml et à utiliser un débogueur pour trouver ou t'as oublié d'incrémenter la variable de contrôle de la boucle !".

8)("Dans la pratique, ce qui se fait, c'est qu'on développe des algorithmes qui restent dans un domaine très réduit en respectant des règles strictes afin de s'assurer qu'ils entrent bien dans la catégorie de ceux qui terminent. Cependant, la réciproque est très loin d'être vraie : ce n'est pas parce que l'on viole une de ces règles que l'algo va fatalement "boucler", très loin de là même ! ") : Je n'ai pas compris la tournure de la phrase ? Peut-être puis-je ajouter que certains algorithmes de compilateurs ne vérifient pas assez de choses qui restent pourtant dans le domaine du décidable (au niveau de la détection) cependant je suis persuadé que au moins un compilateur "idéal" les inclue tous.

9) ("Bien entendu, si en fait vous avez dans l'idée de vous restreindre aux algorithmes développés de manière à être sûr qu'il terminent (selon telle ou telle méthode de développement) , alors le problème de l'arrêt ne se pose pas, mais ce faisant, vous réduisez dramatiquement le pouvoir d'expression des machines de Turing.") : je ne suis pas totalement d'accord, ce n'est pas parce que l'on se réduit aux algorithmes qui ont (au moins une possibilité d'arrêt (rapport au test de l'entrée "continuer oui/non")) dans tous les traitements, que cela limite la machine de Turing. Le travail du développeur est de s'assurer dans son développement que le programme à au moins une possibilité d'arrêt sinon son programme fait n'importe quoi et ce sera normal d'ailleurs puisque la machine de Turing n'a aucun moyen de savoir qu'il ne faut pas sauter par la fenêtre du 100éme étage alors qu'on lui en à malencontreusement donné l'ordre. C'est comme une histoire que je connais :

"Un homme trouve une lampe, un génie en sort, trois veux :

• avoir une voiture très rappide -> le génie lui sort une Ferrari qui coûte bonbon,
• avoir le compte en banque de bilou -> le génie lui sort un fourgon rempli de lingot d'or,
• Devenir irrésistible aux femmes -> le génie le transforme en tablette de chocolat et se barre.

donc tout est dans la requête et la requête viens de l'homme pas du génie.

Cordialement,

Ppignol (d) 13 juin 2009 à 03:58 (CEST)

(je redescends d'un niveau dans les reply, sinon on va finir par ne plus avoir de place ^^

A1) Vous vous rendez compte que vous dites maintenant exactement la même chose que moi, à ceci près que je le formule par l'absurde ? Le problème de libération de mémoire à un moment donné est justement un problème portant sur la sémantique dénotationnelle d'un programme. Donc, un garbage collector parfait ne peut pas exister.

A2) Comment ça, une phrase est le contraire de l'autre ??! Vous n'êtes pas d'accord avec la première phrase, alors qu'elle dit ce que vous dites : il n'existe pas de garbage collector parfait, car s'il en existait un, alors on pourrait détecter à coup sûr les programmes "à rejeter".

L'autre phrase dit précisément que comme il n'existe pas d'algo permettant de résoudre un problème indécidable, je ne vois pas comment un garbage collector pourrait en rencontrer un. quoi qu'on écrive, ca ne sera jamais un algo capable de résoudre un problème indécidable, d'où inutilité de considérer cette hypothèse...

A3) J'aimerais que vous m'expliquiez un peu plus cette méthode, car là, ce n'est pas clair. le cas (oui, oui), ça veut dire qu'on considère un programme qui passe dans le then et dans le else juste après ? Ca me paraît à exclure... Quoi qu'il en soit, si vous vous mettez à analyser tous les branchements possibles d'un programme, vous allez vous prendre une explosion combinatoire en le nombre de if, vous excluez de réserver de la mémoire dans une boucle et de la rendre à l'extérieur de la boucle, même chose avec des appels récursifs. Ca fait une bonne complexité, et un peu trop de restrictions... Enfin bon, je reste dans l'attente d'une description claire avant d'extrapoler...

B) Ah mais non ! Chaque algo de tri possède ses "cas pathologiques" qui vont lui faire atteindre son pire cas, et ça c'est une question de nature des l'instances, pas du nombre d'instances à résoudre. Lancez un quicksort, un tri par fusion, et un tri bulles sur un ensemble d'instances presques triées d'une part, et un ensemble d'instances presque triées en ordre inverse d'autre part, vous serez surpris des différences de perfs...)

Je ne vois d'ailleurs pas comment un développeur pourrait prédire quel va être précisément l'ensemble des entrées de son algorithme, étant donné que ça dépend de ce que l'utilisateur fera...

C) Ah mais je n'ai jamais parlé des spécifications souhaitées ! Vous dites que le compilateur doit pouvoir traiter tous les "bugs sémantiques" qu'il rencontre. De deux choses l'une : soit vous restreignez la notion de bug sémantique à la petite liste des cas que vous avez écrite entre parenthèses, et alors là vous êtes TRES LOIN de capturer tous les programmes qui vont ne jamais terminer (et donc vous risquez fatalement de compiler des programmes qui ne terminent pas) ; soit vous définissez un "bug sémantique" comme étant la propriété d'un programme qui ne termine jamais, et alors là je vous dit qu'il n'y aura jamais AUCUN algorithme capable de tous les détecter, étant donné qu'il s'agit JUSTEMENT du problème de l'arrêt !

D) découle donc aussi du C) : en fait, vous voulez simplement remplacer le while(true) par n'importe quel morceau de code qui ne termine pas, mais que le compilateur soit incapable de détecter...

F) Mais non ! Les axiomes sont les "briques de bases" d'une théorie, et sont donc, dans la théorie en question, considérés comme intrinsèquement vrais !

Ce que dit le TIG, c'est qu'il existe dans l'arithmétique de Peano (et même dans n'importe quelle théorie permettant de faire des maths) des formules dont ON NE PEUT PAS DIRE si elles sont vraies ou fausses. C'est à dire qu'il n'existe aucun chemin de déduction permettant de confirmer ou de réfuter cette formule ! D'où le terme de théorie "incomplète" !

De manière informelle, le TIG dit que dans toute théorie suffisamment expressive pour permettre de faire de l'arithmétique, on peut exprimer l'équivalent de "Cette phrase est fausse".

G) si, et alors ? while(true), ce n'est donc pas un problème. Donc, ça entre en contradiction avec ce que vous écriviez : "Un bug est le contraire d'un problème utile à l'homme soit un problème décidable". Le problème de l'arrêt, ce n'est pas "while(true)", c'est "Etant donné F un algo et x des données d'entrée, dire si F(x) est défini ou pas".

Gb) "Indécidable triviaux" ? Indéfini, ou non terminant ! En l'occurence, on parle d'algorithmes, pas de problèmes ! "Les cas non triviaux sont le problème de l'homme" : eh ben voilà, on y arrive ! contrairement à ce que vous affirmiez en C), on ne peut pas tout détecter automatiquement, donc il faut s'assurer que les algos qu'on écrit vont bel et bien terminer, quitte à se placer dans un cadre plus restrictif que le pouvoir d'expression des machines de Turing (ce qui, dans la pratique, ne pose pas de problème énorme : généralement, on évite même d'implémenter des algos exponentiels en temps, ou alors on les lance avec un timeout...)

8) Hmmm, c'est une question ouverte, mais à mon avis, on continuera toujours à trouver des propriétés de plus en plus fines à étudier (j'aurais du mal à me dire qu'il n'y a plus rien à trouver dnas l'analyse automatique des codes sources dans tel langage... )

9) Ahhh ben si, mine de rien : si vous stoppez l'algorithme par une intervention extérieure, ça revient à placer une limite en temps (éventuellement initialement inconnue, et pouvant être arbitrairement grande, certes) et donc, fatalement, il y a des instances de problèmes que vous ne résolvez pas... )

la présence d'un timeout restreint le traitement à un nombre d'étapes de calcul prédéterminé, alors que l'intervention de l'utilisateur pour stopper l'exécution de l'algorithme pose une probabilité sur le nombre d'étapes que l'algorithme pourra exécuter (selon la patience de l'utilisateur). Dans les deux cas, on restreint l'ensemble des algos pouvant être mené au bout. Le développeur ne peut d'ailleurs pas faire grand chose de plus, étant donné que s'il s'aventure hors de ces cas classiques dans lesquels il sait que son algo peut toujours être stoppé, il pourra éventuellement (mais pas forcément) créer des programmes qui vont ne pas terminer (et en dehors de ce cadre qu'il s'était donné, il n'a en général aucun moyen de savoir si ce qu'il code termine ou pas).

Pour reprendre la métaphore, si on reste à plus de 3 mètres de la fenêtre, on est certain de ne pas sauter, passé cette limite, on ne répond plus de rien : on peut toujours s'en sortir indemne, ou s'écraser sur le bitume...

Jamian (d) 13 juin 2009 à 13:45 (CEST)

Bon j'en ai mare de tourner autour du pot. Je vais donc faire simple et très imagé.

En réponse à votre dernière image : ce n'est pas à 3 mettre que le saut commence mais quand le pied quitte la fenêtre. Une simple grille devant la fenêtre empêche la chute alors arrêtez de vouloir regarder dehors et commencez déjà par finir de construire la maison. Si on scie la branche coté feuille(par rapport au tronc) faut pas s'étonner de s'étaler.

1) Je ne refait pas les théories mais je m'appuie dessus.

2) Le développeur ne doit pas demander à la machine de sauter par la fenêtre. Si il le fait c'est qu'il est con.

3) La machine n'a pas à chercher le meilleur moyen de sauter par la fenêtre. Si le développeur veut le faire c'est que c'est lui qui est con, c'est pas la machine qui ne comprend rien. OUI, une machine ne saura jamais optimiser un saut par la fenêtre.

4) Si un algorithme dit d'une manière ou d'une autre "saute par la fenêtre" à une machine, c'est la faute du développeur pas de la machine ni de son compilateur/ramasse miette/détecteur de fuite.

5) un compilateur/ramasse miette/détecteur de fuite ne peut pas détecter tous les cas de "jette toi par la fenêtre" mais seulement les plus évidents et sa suffira largement à un bon développeur.

6) Le code "while(true);" dit clairement à la machine de se jeter par la fenêtre. Donc c'est un mauvais exemple pour l'article.

7) Conclusions : Si un développeur et assez con pour dire à une machine de sauter par la fenêtre et qu'elle(son compilateur/ramasse miette/détecteur de fuite) n'optimise pas le code c'est la faute du développeur pas de la machine(ou de son compilateur/ramasse miette/détecteur de fuite).

8) Si vous n'arrivez pas à comprendre ces 7 points ne faites surtout jamais d'informatique. L'informatique vous en remerciera.

https://www.larecherche.fr/v%C3%A9rifier-des-programmes-en-prouvant-des-th%C3%A9or%C3%A8mes

ps : donnez moi une adresse mail et je vous enverrais un corolaire sur la marine américaine et un phare galicien en pps

Ppignol (d) 17 juin 2009 à 02:23 (CEST)

Petit résumé édulcoré du pps :

• Phare Galicien : Allo la flotte américaine, vous allez nous percuter alors changez de cap.
• Marine Américaine : Non ! Vous changez de cap.
• PG : Nan, ça vas pas le faire, ce sera plus facile pour vous !
• MA : (apres plusieurs interlocuteurs : le commandant de la flotte) ON EST LES PLUS FORT PARCE QU'ON EST LA MARINE AMÉRICAINE ET ON VOUS DONNE L'ORDRE DE CHANGER DE CAP SINON ON VOUS DÉGOME !
• PG : VOUS ÊTES PEUT ÊTRE LE PLUS FORTS MAIS NOUS ON PEUX PAS CHANGER DE CAP PARCE QU'ON BOUGE PAS, ON EST LA TERRE ET VOUS ALLEZ VOUS DÉFONCER SUR LES ROCHERS ALORS CHANGEZ DE CAP OU CA VAS VOUS FAIRE TRÈS MAL, MALGRÉ TOUT VOTRE ARMEMENT !
• MA : Ok, désolé, merci pour l'info, bonne journée.

Brainfuck

Bonjour,

Comme l’article Brainfuck se trouve dans ma liste de suivi, j’ai vu que tu travailles actuellement sur cet article. En regardant ce que tu as fait, je me suis aperçu que les commentaires contiennent parfois des virgules, qui est un caractère signifiant. Je pense qu’il faudrait éviter de mettre de tels caractères, même si le code n’est présent qu’à titre d’illustration. Il y a aussi des - et des +, sous la forme M--. Pour la même raison, il faudrait les remplacer par décrémentation de M (qui a aussi l’avantage d’être plus clair pour les non-informaticiens…). Comme tu comprends mieux le BF que moi, je te laisse faire le nécessaire. Cordialement — Ltrl G^☎, le 12 juillet 2013 à 11:59 (CEST)

Signature manquante sur Discussion:Décorateur (patron de conception)

Bonjour Ppignol,

Je suis un robot qui aide les utilisateurs à ne pas oublier de signer leurs messages.

J'ai constaté que votre signature était manquante ou mal insérée sur la page Discussion:Décorateur (patron de conception)^(diff) et l'ai rajoutée à votre place. (signaler une erreur)

À l'avenir, pensez à signer vos messages en cliquant sur l'icône au-dessus de votre fenêtre d'édition, ce qui rajoutera les quatre tildes de signature (~~~~). [+ d'infos]

Je vous souhaite de bonnes contributions sur Wikipédia !

Signature manquante (bot) (discuter) 5 septembre 2020 à 02:07 (CEST)

Signature manquante sur Discussion:Algèbre de Boole (structure)

Bonjour Ppignol,

Je suis un robot qui aide les utilisateurs à ne pas oublier de signer leurs messages.

J'ai constaté que votre signature était manquante ou mal insérée sur la page Discussion:Algèbre de Boole (structure)^(diff) et l'ai rajoutée à votre place. (signaler une erreur)

À l'avenir, pensez à signer vos messages en cliquant sur l'icône au-dessus de votre fenêtre d'édition, ce qui rajoutera les quatre tildes de signature (~~~~). [+ d'infos]

Je vous souhaite de bonnes contributions sur Wikipédia !

Signature manquante (bot) (discuter) 28 avril 2021 à 08:40 (CEST)