Forum Sceptique

Autrement dit, ça revient à ce que je disais dans un langage simple avec des références communes : il y a l'innée (structure statique) et l'acquis (sa dynamique). Donc, comme je le suppose, « l'expérience acquise » (pendant « l'entrainement ») provoquera nécessairement des différences de « classement » comme c'est de toute façon le cas chez chacun d'entre nous, d'où la subjectivité, d'où des choix arbitraires en fonction des considérations~classements qui diffèrent chez chacun d'entre nous. D’autant plus pour des systèmes qui continuent à « apprendre » après l'entrainement. Du coup, l'on demeure pile-poil dans la vision systémique~cybernétique habituelle du truc (simplifié certes, à mon petit niveau de passionné), pour ce que j'en connais!

Dash a écrit : 15 févr. 2018, 15:47 Autrement dit, ça revient à ce que je disais dans un langage simple avec des références communes : il y a l'innée (structure statique) et l'acquis (sa dynamique). Donc, comme je le suppose, « l'expérience acquise » (pendant « l'entrainement ») provoquera nécessairement des différences de « classement » comme c'est de toute façon le cas chez chacun d'entre nous, d'où la subjectivité, d'où des choix arbitraires en fonction des considérations~classements qui diffèrent chez chacun d'entre nous. D’autant plus pour des systèmes qui continuent à « apprendre » après l'entrainement.

D'accord.

Pour ma part je considère l'IA comme étant encore collé-collé sur les méthodes statistiques et à des années lumières d'un début de "conscience" (mais c'est pas impossible que ça y parvienne un jour, mais je pense que ça va prendre une révolution dans les algorithmes d'apprentissage; à moins que ça émerge de systèmes de plus en plus complexes (plus de couches, plus de neurones) et de la rapidité des processeurs, qui sait ? ).

I.

Dash a écrit : 15 févr. 2018, 15:47Donc, comme je le suppose, « l'expérience acquise » (pendant « l'entrainement ») provoquera nécessairement des différences de « classement » comme c'est de toute façon le cas chez chacun d'entre nous, d'où la subjectivité, d'où des choix arbitraires en fonction des considérations~classements qui diffèrent chez chacun d'entre nous. D’autant plus pour des systèmes qui continuent à « apprendre » après l'entrainement.

En pratique, les systèmes qui continuent à apprendre sont très rares.
A titre d'exemple, l'IA "Autopilot" de Tesla est parfaitement identique sur toutes les Tesla, elle n'apprend qu'en laboratoire.
Dans le cas général, il n'y a pas de bonne raison pour entrainer différemment les différentes instances d'une IA. La seule bonne raison serait justement de les individualiser, sinon c'est une perte de temps.

Dash a écrit : 14 févr. 2018, 17:36S'il y avait des erreurs de 0/1 (peu importe la provenance : code/composants), nous pourrions obtenir des résultats sensiblement différents pour une même opération entre deux PC/logiciel. Et le fichier Word contenant ton CV pourrait se dégrader avec le temps et perdre des lettres, etc. Mais cela n'arrive jamais!
[...]
Je vulgarise au max. En fait, il y a toute sorte de systèmes de corrections d'erreurs de bits (comme les mémoires ECC, par exemple), mais ce n'est pas du même ordre et cela n'affecte jamais les données/calculs/résultats effectués par les programmes/logiciels.

Si justement, cela les affecte et c'est pour cela qu'il y a les modules de type ECC pour les machines où l'intégrité des données est critique. Et si, ces erreurs sont du même type et affecte tout à fait les "données/calculs/résultats effectués par les programmes/logiciels" !
Les ordinateurs "de bureau" n'ont d'ailleurs pas ces modules de contrôle d'erreur, et c'est une des raisons pour lesquels ils "plantent" plus souvent qu'un serveur.
Et donc contrairement à ce que tu dis, si, un fichier word contenant un CV peut tout à fait se dégrader avec le temps. En pratique, il sera tout simplement illisible, mais probablement réparable. Et si, une calculette pourrait tout à fait dire 2+2=5, même si c'est moins probable étant donnée la taille du problème.
Les probabilités pour qu'une erreur de bit arrive ne sont pas négligeables contrairement à ce que l'on croit. Si on considère uniquement les erreurs de stockage en mémoire vive (et il y a beaucoup d'autres sources d'erreurs), on peut considérer qu'il y a plusieurs milliers d'erreurs par gigaoctet par an (pour une machine allumée 24h/24).

Oui, mais non. Tu formules de façon à mélanger tout ceux qui n’y connaissent rien. Tu dis la même chose que moi sans t’en rendre compte quand je dis que, s’il y a une erreur, cette dernière sera-t-elle que nous ne pourrons pas la confondre (fichier Word illisible, support ne pouvant être lu, etc.). Mais jamais les données qui font sens pour l’utilisateur — à son niveau — vont se modifier. Les altérations se font à un plus bas niveau, mais au niveau de l’utilisateur, soit ça sera lisible, soit le fichier ne s’ouvrira pas ou sera tellement corrompu qu’on le remarquera sans aucune ambiguïté et l'on ne l’utilisera pas. Comme je le disais, c’est tout ou rien!

Mais jamais, jamais le dossier médical informatisé d’un patient ne s’altérera au point de modifier le « b+ » de son groupe sanguin par un « b- ». Un nombre ou un caractère ne peut s’interchanger. Si tel était le cas, ça remettrait en cause absolument tout!

thewild a écrit : 19 févr. 2018, 15:23 Les ordinateurs "de bureau" n'ont d'ailleurs pas ces modules de contrôle d'erreur, et c'est une des raisons pour lesquels ils "plantent" plus souvent qu'un serveur.

Faudrait trouver des stats (voir le premier lien à la fin de mon post), mais de par mon expérience/observation empirique (assez conséquentes) quand un PC (ou un module mémoire) est stable dès les premiers jours (sans defect matériel), il ne plante jamais fortuitement à cause d’erreurs de bit unique qui se produirait de temps à autre. En pratique, c’est tellement rare que c’est tout comme si ça n’avait aucune incidence. Mais de toute façon, nous sommes d’accord qu’il s’agit de freeze/plantage et non pas d’autre chose, en pratique?

thewild a écrit : 19 févr. 2018, 15:23Et donc contrairement à ce que tu dis, si, un fichier word contenant un CV peut tout à fait se dégrader avec le temps.

Personnellement, je n'ai jamais observé et n'ai jamais trouvé un exemple d'un seul cas connu et répertorié ou la résultante d'une erreur de bit unique a été observée concrètement dans un fichier (pixel dans une image, fichier audio échouant le null test, pixel manquant dans une lettre d'un fichier texte, etc.). Dans les faits, une mémoire trop sensible aux variations de tension/rayonnement fera planter/freezer le système, comme je le mentionne (et toi aussi) depuis le début (le mythe du pixel dans une image étant de l'ordre de la possibilité théorique, mais ça ne parvient jamais jusque là sans freezer, en pratique).

Mais je pense qu'il est inutile de sodomiser les coléoptères à ce sujet étant donné que toutes les applications sensibles (serveurs de données) qui nécessitent la correction d'erreur de bit possèdent de la mémoire appropriée (ECC/ChipKill) afin d'éviter de planter ou de tout perde (bien plus que par crainte d'altération infime des données, àmha).

thewild a écrit : 19 févr. 2018, 15:23Les probabilités pour qu'une erreur de bit arrive ne sont pas négligeables contrairement à ce que l'on croit. Si on considère uniquement les erreurs de stockage en mémoire vive (et il y a beaucoup d'autres sources d'erreurs), on peut considérer qu'il y a plusieurs milliers d'erreurs par gigaoctet par an (pour une machine allumée 24h/24).

Oui, « techniquement », tu as raison (voir les stats dans le premier lien en bas), Mais elles se manifestent sous quelle forme pour les utilisateurs lambda (avec PC sans memoire ECC)?

Par des freeze/plantages!

Tu connais bcp d'exemples, de gens qui se plaignent/ont observé qu'un symbole ou une valeur s'est modifié dans un de leur fichier?

Voilà! Ça ne remonte jamais jusqu' « au niveau » de l'utilisateur.

Bref, presque toutes les « erreurs » informatiques — ayant une incidence trompeuse — connues et répertoriées se sont produites avant les années 2000 à cause d’arrondis mal effectué et/ou du à des résolutions de calcul pas assez élevées/précises (sinon, les cas « modernes» sont très connus et touche des sphères très spécifiques. Voir plus bas). Mais il s’agissait de difficultés/problèmes purement mathématiques (connus bien avant l’utilisation des ordinateurs) et essentiellement liés aux résolutions insuffisantes de l’époque. De nos jours, ces types de problèmes (pour la plupart des utilisations) sont résolus et les normes (voir l’IEEE 754, entre autres) ont été ajustées en conséquence. Sinon, les défaillances et la dégradation des composantes matérielles prenant part aux calculs ne provoquent pas des erreurs « en contexte utilisateur » de type « imprécision » qui altéreraient le résultat d’un calcul, mais rien d’autre. Ces types de défaillances créent des « freeze » qui empêchent l’ensemble du processus de s’effectuer (ou carrément d'accéder aux données, comme un Hard Disk/CD qui est dead).

Et c’est ce qui était important de souligner face à l’une des 2 interrogations de jean7 : non, la faillibilité dans un composant électronique ne peut interchanger une donnée essentielle dans l’analyse du jeu de Go ou concernant le groupe sanguin d’un patient dans un fichier médical informatisé, par exemple (considérant que la correction d'erreur mémoire est prise en compte par de l'ECC/Chipkill, etc. ).

La nuance étant, cependant, comme pour tout appareil « physique/électro-mécanique », que cela n’empeche pas d’autres types de problèmes/défaillances de survenir. Nous pouvons tjrs imagiers, par exemple, une surchauffe, un incendie faisant fondre des pièces et des câbles électriques où la résultante finirait par déclencher un truc innaproprié par un système comportant une AI, mais cela n’a plus rien à voir avec le présent sujet. Si le feu consume les murs de soutien d'une maison, le toit va s’effondrer, peu importe la fiabilité des calculs (et des mémoires) de l’AI du systèmes domotique de la maison! Sinon, reste le problème des erreurs au sein des algorithmes, mais ces derniers sont conçus par des humains et ces derniers sont donc directement responsables de ces erreurs.

Maintenant, pour relativiser, et concernant l’autre interrogation de jean7, oui, il demeure tjrs le problème de la précision des calculs utilisant des nombres avec suite infinis après la virgule face à un « horizon infinitésimal », mais cette « problématique » n’a aucune répercussion (du à la capacité des composantes actuelles et de la norme IEEE 754) sur nos fichiers et les opérations (nécessitanta des calculs) que nous pouvons effectuer à la maison, par exemple, sur des images dans Photoshop, des sons dans un éditeur audio ou des textes/calculs sous Word/Excel. Sinon, tu peux être certain que ma vieille tante, qui me téléphone déjà 4 fois par année parce que Microsft verrouille son compte mail (parce qu'elle accroche accidentellement la touche SHIFT quand elle entre son MDP) me téléphonerait bien plus souvent si nos PC de maison (sans ECC) interchangeaient des caractères de MDP à cause des erreurs de bit!!

Ça serait la cata pour des millions d'utilisateurs!

Par contre, il est vrai, après avoir fait quelques recherches sur le net, qu’encore aujourd’hui, en certains domaines très spécifiques et utilisant des calculs scientifiques (simulations numériques en physique, chimie, biologie, aéronautique, automobile, nucléaires, médicales, etc.), existent des erreurs dues à l’approximation des nombres avec suite infinie lors des calculs effectués par certains algorithmes utilisant certains composants, comme les GPU des cartes vidéo, entre autres. Mais à ce que je comprends, ce ne sont pas des « erreurs aléatoires » dues à l’instabilité/l'usure des composants (les ECC/Chipkill réglants le problème), mais bien à un manque de précision provenant de l’accumulation d'approximations/arrondis par certains algorithmes qui n’ont pas nécessairement été conçus, à la base (3D, jeux vidéo), pour servir de super-calculateur afin de faire de la recherche scientifique. Et sinon, oui, en rapport avec la question de Jean7, pour des AI devant jongler avec un « horizon infinitésimal » — dépendamment du domaine et du type de problème/calcul — cela peut certainement poser problème (à voir si les ordinateurs quantiques vont ressourdre cet aspect). Mais tout ça n’a rien à voir (en pratique, puisque les systèmes de correction d'erreurs sont utilisé) avec un « manque de fiabilité » des composants physiques (mémoire/CPU). Ce sont des problèmes essentiellement d’ordre mathématique/algorithmique qui persistent dans ce domaine.

Quelques liens pour en tirer nos propres conclusions :

Mémoire à code correcteur d'erreurs

Chipkill, technique de correction d'erreur qui protège de tout fonctionnement incorrect.

Fiabilité des calculs sur ordinateur

L’IEEE 754 (norme pour la représentation des nombres à virgule flottante en binaire.)

Erreurs numériques de calculs de dose par la méthode de Monte-Carlo sur GPU

Dash a écrit : 19 févr. 2018, 19:12Mais jamais, jamais le dossier médical informatisé d’un patient ne s’altérera au point de modifier le « b+ » de son groupe sanguin par un « b- ». Un nombre ou un caractère ne peut s’interchanger. Si tel était le cas, ça remettrait en cause absolument tout!

Mais si, justement, ça arrive.
Ca ne remet rien en cause, sur les systèmes critiques il y a au mieux de systèmes de correction d'erreur, et au pire des systèmes de contrôles qui alertent qu'il y a une erreur.

Dash a écrit : 20 févr. 2018, 09:09 Faudrait trouver des stats (voir le premier lien à la fin de mon post), mais de par mon expérience/observation empirique (assez conséquentes) quand un PC (ou un module mémoire) est stable dès les premiers jours (sans defect matériel), il ne plante jamais fortuitement à cause d’erreurs de bit unique qui se produirait de temps à autre. En pratique, c’est tellement rare que c’est tout comme si ça n’avait aucune incidence. Mais de toute façon, nous sommes d’accord qu’il s’agit de freeze/plantage et non pas d’autre chose, en pratique?

Non non, nous ne sommes pas d'accord. Je maintiens qu'en pratique ton + peut se changer en -, ton 0 en 1, ton A en B (enfin plus probablement ton B en C, mais c'est un détail), etc.
Pour les stats, la meilleure étude que je connaisse est celle de Google : http://www.cs.toronto.edu/~bianca/paper ... rics09.pdf

Dash a écrit : 20 févr. 2018, 09:09 Oui, « techniquement », tu as raison (voir les stats dans le premier lien en bas), Mais elles se manifestent sous quelle forme pour les utilisateurs lambda (avec PC sans memoire ECC)? Par des freeze/plantages!
[...]Voilà! Ça ne remonte jamais jusqu' « au niveau » de l'utilisateur.

Pas du tout. Le plantage, on va dire que c'est le meilleur des cas parce qu'au moins l'utilisateur se rend compte qu'il y a un problème.
Je ne sais pas ce qui te fait dire que ça n'affecte jamais les données de l'utilisateur, mais c'est faux.
Grossièrement, on peut dire qu'il y a une chance sur deux pour que le système plante directement, et une chance sur deux pour que des données soient changées sans plantage.

thewild a écrit : 21 févr. 2018, 17:21 Je ne sais pas ce qui te fait dire que ça n'affecte jamais les données de l'utilisateur, mais c'est faux.
Grossièrement, on peut dire qu'il y a une chance sur deux pour que le système plante directement, et une chance sur deux pour que des données soient changées sans plantage.

Je plussoie
Un fichier est une structure de données plus des données ... et l'ensemble forme un tout .... une modification/erreur d'un bit peut affecter n'importe quel endroit du fichier .... si cet endroit touche à la structure de donnèes, il peut y avoir (ou non) plantage (lors de la lecture même), si cet endroit concerne une donnée il n'y aura pas de plantage à la lecture, dans la plupart des cas l'utilisateur ne sera pas au courant de l'erreur .... mais il peut y avoir un plantage de l'application qui interpréte la donnée si celle-ci sort du domaine de variation attendu ou possède une incohérence vis à vis des autres données lues.

J'espère que c'est compréhensible ... j'avoue que je ne sais plus ou j'en suis

Selon Claude Shannon le nombre maximum de parties aux échecs serait de 10120

Selon G.H. Hardy c'est énormément plus que ça : 101050 (en tenant compte de la règle des 50 coups).

Numberphile a une vidéo là-dessus: https://www.youtube.com/watch?v=Km024eldY1A

I.

Ajout: http://wismuth.com/chess/longest-game.html

Lulu Cypher a écrit : 21 févr. 2018, 18:24
thewild a écrit : 21 févr. 2018, 17:21 Je ne sais pas ce qui te fait dire que ça n'affecte jamais les données de l'utilisateur, mais c'est faux.
Grossièrement, on peut dire qu'il y a une chance sur deux pour que le système plante directement, et une chance sur deux pour que des données soient changées sans plantage.
Je plussoie [...]

De toute évidence, je ne suis pas assez calé (l’informatique c’est vaste et il y a plusieurs spécialités) pour être en mesure d’expliquer clairement et en détail, de façon technique, mon point, mais, manifestement, encore moins vous deux.

Il est impossible que 50% (ou même 10%) des erreurs de bit se traduisent par une modif de donnée sensible. Ça n'a aucun sens, car ce n’est pas représentatif de ce qui se passe dans la réalité. Idem avec les plantages (votre « autres 50% »). Si c’était à ce point, nos PC planteraient des dizaines de fois/jour, chaque jour, systématiquement!

Demandons à Cogite/Denis (mais est-ce vraiment nécessaire vu la simplicité d’approximation, même à vue de nez), compte tenu des millions de PC dans le monde x les millions d’opérations/calculs à la seconde de chacun x le taux d’erreurs de bit mentionné dans l’article Wiki quel serait le nombre total d’erreurs de bit (approx). Maintenant, imaginez que 50% de ses dernières modifient des données sensibles et 50% se traduisent par des plantages.

Ce serait tellement conséquent que la techno numérique (l’utilisation des PC donc) serait moins fiable que les anciens systèmes et moyens analogiques d’antan. Les feuilles en papier tapé à la machine à écrire (même en tenant compte des erreurs de frappe humaines) seraient plus sûres et sécuritaires. Chaque semaine des centaines et des centaines de cas d’erreurs/incidents graves seraient rapporté dans les médias et tous les acteurs du domaine concerné (au lieu de discuter sur le futur de l’AI, le jeu de Go et cie) seraient occupé à tenter de résoudre le problème et à nous mettre en garde de ne pas utiliser les ordinateurs, sauf pour jouer! Du coup, oubliez les voitures autonomes et consorts, c’est totalement impossible selon « votre 50% ».

Je pense que vous oubliez/confondez les étapes intermédiaires, ainsi que les 0/1 désignant les bits d’avec (les erreurs d’arrondis qui n’impactent pas nécessairement le chiffre à gauche de la virgule) la donnée finale (chiffre/lettre).

Puisque nous sommes tous les 3 incapables d’expliquer, techniquement, comment ça procède dans le détail et qu’il n’y a aucune manifestation d’erreurs de données sensibles concrète et observable au quotidien, la charge de la preuve est dans votre camp! Moi, je ne peux pas prouver l’inexistence de ces exemples concrets.

Je vous mets au défi de trouver des exemples pratiques et concrets (autre que les erreurs d’arrondis dues aux combinaisons de grand nombre d’op en certains domaines spécifiques). Des exemples de modifications/altérations de données sensibles ayant un impact « à notre échelle ». Par exemple, une valeur/caractère qui change dans les comptes de banque, les dossiers médicaux, les fichiers texte, audio, vidéo, etc. Tributaire des erreurs de bit. Bonne chance à l’avance! Les seules erreurs connues et répertoriées concernent des arrondis et sont présentées dans un document dont j’ai moi-même fourni le lien (et datent de plus de 20 ans!).

Et sinon, je n’ai pas de lien sous la main, mais je me souviens de tests qui ont déjà été effectués où ils faisaient exprès (de façon automatisée) de copier/coller/reproduire un fichier des millions de fois sans qu’il n’y ait, au final, aucune donnée sensible d’altérée et ce, malgré les erreurs de bit unique qui se produisent, entre autres, pendant l’opération.

Si l’incidence était telle que vous l’imaginez/prétendez, la dégradation d’un fichier (quel qu’il soit, peu importe le type) serait telle que l'utilisation du numérique dégraderait plus que les anciens supports analogiques. Mais ce n’est pas le cas! En pratique, dans la réalité, l’on observe rien de tel! La calculette de votre PC n'indiquera jamais 4 si vous entrez 2+3. C'est même l'argument principal de la techno et de la fiabilité du numérique par rapport à l'analogique.

Je ne demande qu’à voir. Allez, détordez-moi!

Pour dire, si l’on me prouve le contraire, je vais être plus ébranlé que si l’on me prouve que la terre est visitée par des extraterrestres ou que les pourvois psy existent! Sérieusement!

񮾍 Moi j'ai tapé un astérisque, mais j'imagine que c’est une erreur de bit qui a altéré/modifié le caractère! Idem avec le point manquant à la fin de ma phrase : erreur de bit

Dash a écrit : 22 févr. 2018, 14:44 Il est impossible que 50% (ou même 10%) des erreurs de bit se traduisent par une modif de donnée sensible. Ça n'a aucun sens, car ce n’est pas représentatif de ce qui se passe dans la réalité. Idem avec les plantages (votre « autres 50% »). Si c’était à ce point, nos PC planteraient des dizaines de fois/jour, chaque jour, systématiquement!

Demandons à Cogite/Denis (mais est-ce vraiment nécessaire vu la simplicité d’approximation, même à vue de nez), compte tenu des millions de PC dans le monde x les millions d’opérations/calculs à la seconde de chacun x le taux d’erreurs de bit mentionné dans l’article Wiki quel serait le nombre total d’erreurs de bit (approx). Maintenant, imaginez que 50% de ses dernières modifient des données sensibles et 50% se traduisent par des plantages.

Euh... Qu'appelles-tu une erreur de bit ? (no pun intended)

l'altération d'un bit (le format binaire (0/1), le langage machine.) à cause de prob de tension/rayonnement.

Je ne sais pas si tu as suivi la discussion, mais pour faire bref (je dois quitter) Jean7 posait la question (remonte d'une page ou deux) à savoir si le nombre conséquent d'opérations/calculs pouvait générer des erreurs et si le matériel, les composants électroniques pouvaient se dégrader et générer des erreurs dans les calculs. J'ai fait une réponse simpliste/vulgarisée pour dire, grosso modo, que le propre de la techno numérique c'était de ne pas dégrader l'info avec le temps ni de produire des erreurs de calcul, etc. J'ai aussi mentionné qu'il y avait bel et bien des erreurs, mais que des systèmes de correction (par exemple les mémoires ECC), corrigeaient ces dernières et que cela se passait à un autre niveau qui ne concerne pas l'utilisateur au final. Mais thewild veut entrer dans les détails et enculer les mouches en soulignant qu'il y a bel et bien des erreurs de bit. Je suis d'accord avec lui, mais ce que je dis, c'est que les systèmes de correction d'erreur font très bien leur job et qu'au final, ça ne pose pas de problème en pratique alors que lui prétend qu'une calculatrice peut indiquer un faux résultat à cause d'une « erreur de bit »!

lien Wiki a écrit :Des travaux publiés entre 2007 et 2009 ont montré des fréquences d'erreur très variables, avec des variations de plus de 7 ordres de grandeur, allant de 10−10 à 10−17 erreur / bit - heure, c'est-à-dire environ une erreur par bit, par heure, par gigaoctet de mémoire à une erreur par bit, par millénaire, par gigaoctet de mémoire5,6,7. Une étude à très grande échelle basée sur les très nombreux serveurs de Google a été présentée lors de la conférence Sigmetrics / Performance 20096. Le taux d'erreur mesuré était de plusieurs ordres de grandeur plus élevé que les études à petite échelle ou les études de laboratoire précédentes, avec 25 000 à 70 000 erreurs par milliard d'heures, par mégabits (environ 2,5 × 10−11 à 7 × 10−11 erreur /bit - heure, soit environ 5 erreurs dans 8 gigaoctets de mémoire par heure en utilisant le taux d'erreur le plus élevé); plus de 8 % des modules de mémoire DIMM étaient affectés par des erreurs chaque année.

Dash a écrit : 22 févr. 2018, 16:03 l'altération d'un bit (le format binaire (0/1), le langage machine.) à cause de prob de tension/rayonnement.

Je ne sais pas si tu as suivi la discussion, mais pour faire bref (je dois quitter) Jean7 posait la question (remonte d'une page ou deux) à savoir si le nombre conséquent d'opérations/calculs pouvait générer des erreurs et si le matériel, les composants électroniques pouvaient se dégrader et générer des erreurs dans les calculs. J'ai fait une réponse simpliste/vulgarisée pour dire, grosso modo, que le propre de la techno numérique c'était de ne pas dégrader l'info avec le temps ni de produire des erreurs de calcul, etc. J'ai aussi mentionné qu'il y avait bel et bien des erreurs, mais que des systèmes de correction (par exemple les mémoires ECC), corrigeaient ces dernières et que cela se passait à un autre niveau qui ne concerne pas l'utilisateur au final. Mais thewild veut entrer dans les détails et enculer les mouches en soulignant qu'il y a bel et bien des erreurs de bit. Je suis d'accord avec lui, mais ce que je dis, c'est que les systèmes de correction d'erreur font très bien leur job et qu'au final, ça ne pose pas de problème en pratique alors que lui prétend qu'une calculatrice peut indiquer un faux résultat à cause d'une « erreur de bit »!

Ok, j'ai compris.

Les ordinateurs sont bourrés de système de détection et correction d'erreurs, à tous les niveaux. Je n'ai jamais rencontré, dans ma carrière d'informaticien, d'erreur qui soit imputable à une "erreur de bit", et pas à une erreur de programmation, de données, ou de défaillance matérielle.

Voilà!

CQFD Merci bonsoir !

Dash a écrit : 22 févr. 2018, 14:44Il est impossible que 50% (ou même 10%) des erreurs de bit se traduisent par une modif de donnée sensible. Ça n'a aucun sens, car ce n’est pas représentatif de ce qui se passe dans la réalité. Idem avec les plantages (votre « autres 50% »). Si c’était à ce point, nos PC planteraient des dizaines de fois/jour, chaque jour, systématiquement!

Sauf qu'il y a des systèmes correctifs. Car ces erreurs arrivent effectivement plusieurs fois par jours.

Maintenant, imaginez que 50% de ses dernières modifient des données sensibles et 50% se traduisent par des plantages.

Tu as mal compris. J'ai dit 50% de chances que ça plante et 50% que ça change des données (et j'ai précisé que c'était pour faire de la très grosse vulgarisation). Je n'ai pas dit des données "sensibles".
Quel pourcentage de la mémoire vive d'un ordinateur contient des données réellement sensibles ? Extrêmement peu (je ne m'aventurerais pas à un chiffre, ça dépend énormément du type de tâche).
Si, par exemple, tu joues à un jeu très gourmand en mémoire, il a des très fortes chances que le changement d'un bit parmi ces milliards n'ait absolument aucune conséquence. Le plus probable est qu'un pixel aura une couleur légèrement différente que celle qu'il aurait dê avoir, et ce seulement pendant une trame d'affichage ! Ca passe complètement inaperçu, mais ce n'est pas pour ça que ça n'existe pas.
Pas de plantage, pas de zéros en plus ou en moins sur ton compte en banque, mais les faits sont là.

Ce serait tellement conséquent que la techno numérique (l’utilisation des PC donc) serait moins fiable que les anciens systèmes et moyens analogiques d’antan. Les feuilles en papier tapé à la machine à écrire (même en tenant compte des erreurs de frappe humaines) seraient plus sûres et sécuritaires.

Ca m'étonnerait qu'un humain puisse atteindre les taux d'erreur d'un ordinateur. 50.000 erreurs par mégabit par milliards d'heures, c'est extrêmement faible. C'est en manipulant énormément de donnée que ça devient significatif.

Puisque nous sommes tous les 3 incapables d’expliquer, techniquement, comment ça procède dans le détail

C'est trivial, pas besoin d'aller chercher midi à quatorze heure. Le caractère unicode "0" est stocké en mémoire vive (représentation binaire en latin basic 00110000). Le dernier bit change (la réprésentation binaire devient 00110001), le 0 devient 1.
Est-ce que ce 0 va être réécrit quelque part ? Peut-être que oui, peut-être que non. Il y a énormément d'information dans un ordinateur dont l'intégrité n'a pas la moindre importance. Beaucoup ne sont contenues en mémoires que pour être rapidement utilisées, mais ne seront jamais réécrites. Le fait qu'elles changent sera très probablement totalement invisible.

Des exemples de modifications/altérations de données sensibles ayant un impact « à notre échelle ».

Si tu as déjà exécuté l'utilitaire sfc de Microsoft et qu'il t'a corrigé des erreurs, alors il y a de très grandes chances pour que tu aies déjà eu un exemple sous les yeux. Cet utilitaire vérifie l'intégrité des fichiers critiques du système d'exploitation uniquement.
Si tu as déjà eu un bug d'affichage (sans plantage, je précise), idem. Enfin là ça peut souvent être un problème logiciel, mais avec un pilote stable il y a des chances que ce soit un bit flip.
On peut trouver plein d'exemples. Le fichier texte ou le fichier excel, ils sont tellement insignifiants dans la quantité de données traitées par un ordinateur que ça tombe rarement sur eux.
Sur les gros systèmes qui traitent peu d'information superflues (en gros, n'importe quel serveur), c'est beaucoup plus délicat, et c'est pour ça que sur un serveur on a de la redondance et des codes correcteurs (ECC, RAID, etc.).

aucune donnée sensible d’altérée et ce, malgré les erreurs de bit unique qui se produisent, entre autres, pendant l’opération

Alors c'est qu'ils utilisaient des systèmes correcteurs. Sinon, il faudra m'expliquer par quel miracle les erreurs de bit peuvent disparaitre d'elles-même.

Dash a écrit : 22 févr. 2018, 16:03J'ai aussi mentionné qu'il y avait bel et bien des erreurs, mais que des systèmes de correction (par exemple les mémoires ECC)

Les ordinateurs de bureau n'ont pas ces systèmes.

mais ce que je dis, c'est que les systèmes de correction d'erreur font très bien leur job et qu'au final, ça ne pose pas de problème en pratique alors que lui prétend qu'une calculatrice peut indiquer un faux résultat à cause d'une « erreur de bit »!

Oui les systèmes de correction d'erreur font très bien leur job. Mais tu n'en as presque pas sur un ordinateur de bureau.
Oui, je maintiens qu'une calculatrice peut indiquer un faux résultat à cause d'une erreur de bit, mais ce n'est pas moi qui ait choisi cet exemple car il est effectivement extrême. La probabilité pour que ça arrive est pour le moins faible...

Cogite Stibon a écrit : 22 févr. 2018, 16:29Les ordinateurs sont bourrés de système de détection et correction d'erreurs, à tous les niveaux.

Merci de préciser lesquels.
Je vois bien TCP pour les transmissions réseau, mais pas grand chose d'autre. On parle d'ordinateurs de bureau, donc pas d'ECC, pas de RAID, pas de ZFS.

Dash a écrit : 22 févr. 2018, 16:39 Voilà!

CQFD Merci bonsoir !

Et c'est pourquoi votre fille est muette

Sérieusement .... il me semblait que le D voulait dire Démontrer .... ou est la démonstration .... j'aime beaucoup Cogite et j'ai un profond respect pour lui mais ne nous livre que son témoignage[1]

Je ne me battrai par sur des probabiltés de survenue d'erreur que tu m'assignes gracieusement et neanmoins à tort. Je n'ai pas non plus parlé de plantage systematique comme tu le dis ..... alors Je vais essayer de dire les choses les plus simplement du monde :
Sur un transfert de fichier, et en oubliant les codes autocorrecteurs et autre dispositifs de parités qui permettent d'identifier une erreur et de la corriger automatiquement .... donc en supposant qu'une erreur de bit survienne il n'y a que 2 cas :

L'erreur concerne la structure données[2]
L'erreur concerne les données

Pour le cas 1 ... le plantage est rare mais possible er ne se révélera qu'à la lecture du la partie du fichier incriminé et l'interprétation par l'application qui l'utilise[3] sinon si l'erreur est mineure ... il ne se passe pas grand chose
Pour le cas 2 ... difficile de s'en rendre compte ... le seul cas ou ce serait possible c'est justement avec le contrôle des domaine de variation des données traitées par les fonctions unitaires (le vrai mot c'est atome programmatique ... mais je trouve ca con) de bas niveau ... ce qui veut dire que meilleure est l'application moins le plantage apparaitra et plus une erreur données pourrait (le conditionnel n'est pas anodin) être "trapée".

Tout ça pour dire que je ne comprends pas ta derniëre réponse qui me parait sans grand rapport avec mon dernier post .... mais n'étant pas en super santé en ce moment je demande de manière totalement arbitraire et injustifiée l'indulgence du jury

------------------------------------
[1] je dois dire que mon témoignage personnel va dans le même sens que celui de cogite mais que ce n'est pas parce que je n'ai pas constaté quelque chose que cette chose n'existe pas ?!? En plus même si j'ai croisé des cas d'erreur de bits il y a toutes les chances que je ne m'en sois pas rendu compte ... les plantages sont rares et une erreur sur les données ne se remarque pas vraiment .... donc ...
[2] au sens large du terme ... il peut s'agir de la structure du fichier, de la structure des données manipulées, la sructure des propriétés d'une donnée, la structure des informations permettant l'autocorrection d'erreurs, etc ...
[3] ne perd pas de vue qu'il existe également des caractéristique de qualité du logiciel et que tout ne se fait pas sur un coin de table ... la robustesse incluant la repise d'erreurs existe

J'suis sur cell (donc j'fais court). ri3n de ce que tu dis n'est faux.

Le désacord est ailleurs. En pratique est- ce que la techno numérique est sûr?

Compte tenue que ce qui nécessite des dispositifs de correction d'erreur en possede (AI, serveurs, omaines sensibles, etc.) est- ce que cela causes des problèmes?

Le reste date d'une autre époque et/ou n'est que de l'enculage de mouche qui sera mal interprété par M. Mme tout le monde.

Sérieusement .... il me semblait que le D voulait dire Démontrer .... ou est la démonstration

En rapport avec ce que je prétend depuis le début : que cela ne provoque pas de probs concrets, même dans l'espace d'une vie d'informaticien (cf Cogite). Que ça ne concerne pas l'utilisateurs qui regarde ses données. Que les données sont de toutes façon sur disque dur (raid, etc) et qu'une mem qui fait planter notre PC est "defect", ne corrompt pas les données sur disque et qu'on la change, etc, etc. que les erreurs humaines ( prog/données) sont sans commune mesure contre tout le reste de l'enculage de mouche.

Intelligence artificielle : les scientifiques tirent la sonnette d’alarme

Dash a écrit : 23 févr. 2018, 03:06Le désacord est ailleurs. En pratique est- ce que la techno numérique est sûr?

On n'est pas en désaccord là dessus.

Compte tenue que ce qui nécessite des dispositifs de correction d'erreur en possede (AI, serveurs, omaines sensibles, etc.) est- ce que cela causes des problèmes?

Non, comme tu le dis les systèmes sensibles sont assez bien protégés.

Tu as subtilement changé ton propos, et je reviens dont au début de la discussion avec toi, c.f. ton message du 14/02. Je confirme que je suis en total désaccord avec ce message.

Tu appelles ça de "l'enculage de mouche", j'appelle ça de la rigueur, c'est aussi là dessus qu'on est en désaccord.

Dash a écrit : 23 févr. 2018, 04:28
Sérieusement .... il me semblait que le D voulait dire Démontrer .... ou est la démonstration
En rapport avec ce que je prétend depuis le début : que cela ne provoque pas de probs concrets, même dans l'espace d'une vie d'informaticien (cf Cogite). Que ça ne concerne pas l'utilisateurs qui regarde ses données. Que les données sont de toutes façon sur disque dur (raid, etc) et qu'une mem qui fait planter notre PC est "defect", ne corrompt pas les données sur disque et qu'on la change, etc, etc. que les erreurs humaines ( prog/données) sont sans commune mesure contre tout le reste de l'enculage de mouche.

Ce n'est pas une démonstration, c'est une hypothèse .... les erreurs dont je parle arriveront toujours avec une probabilité très très faible mais ce n'est pas une raison pour confondre inpossible et improbable et pourront statistiqument porter sur des données "sensibles"

Maintenant est-ce que la technologie est fiable .... la redondance, les correcteurs d'erreurs, la qualité[1] des développement ... tout ça concourre à la rendre fiable ... ce qui veut dire possédant un risque très faible et non un risque nul. Maintenant, concernant le support matériel en lui même, bien que les MTBF des matériels sont de plus en plus importants ... je constate (mais ce n'est qu'un témoignage personnel) que les taux de pannes arrivent plus fréquement .... peut être un biais de ma part.

------------------------------------
[1] qualité dans le sens iso9000 pas dans le sens "j'ai fait des tests et c'est tout beau (duh)"

thewild a écrit : 23 févr. 2018, 11:37 Tu as subtilement changé ton propos, et je reviens dont au début de la discussion avec toi, c.f. ton message du 14/02. Je confirme que je suis en total désaccord avec ce message.

Tu appelles ça de "l'enculage de mouche", j'appelle ça de la rigueur, c'est aussi là dessus qu'on est en désaccord.

Je n’ai pas du tout changé mon propos.

Tu n’as juste jamais voulu saisir que j’ai utilisé les « 0/1 » de façon simpliste dans le sens de « numérique » par opposition à l’analogique afin de faire saisir que les calculs ne peuvent « se tromper », donner de « mauvais résultats ». C’est une « image » qui est très couramment utilisée un peu partout pour faire piger aux « non-initiés » que tout (en informatique) n’est « que calcul » et qu’il n’y a pas d’erreurs de calcul comme telles (parce que les math sont les math et que si erreurs il y a, elles proviennent de ceux qui effectuent les calculs).

Tu remarqueras aussi que j’ai employé le terme « trompe/trompé » pour dire que le code ne se trompe jamais. Ensuite, oui, je dis que les 0/1 ne peuvent s’interchanger par erreur, mais tjrs dans une optique de vulgarisation, mais, le plus important, c’est que je prends même le soin — avant ta première intervention, je précise — de mettre un astérisque qui renvoie à une note de bas de page où je mentionne — moi-même — que tout cela est une vulgarisation, car, à un autre niveau, il y a bel et bien des erreurs de bit (les 0/1 du langage machine que toi, moi et d’autres connaissons), mais qu’elles sont corrigées et que cela n’affecte donc pas les donné au final.

Autrement dit, nous disons pratiquement la même chose tous les deux depuis le début. Si je n’avais pas mis ma note de bas de page, je pourrais, à la limite, comprendre ton désir de « rigueur », mais ce n’est pas le cas. J’ai moi-même (et en premier) pris soin de laisser savoir qu’il y avait bel et bien des erreurs de bit et que je vulgarisais. Donc!?

Là où nous ne sommes pas d’accord, c'est concernant la résultante de ces erreurs de bit. Moi je prétends que dans les faits, soit ça ne change rien, soit ça freeze ou plante et puis c’est tout. Comme ce que moi, Cogite et l’ensemble des habitants de cette planète expérimentons depuis tjrs. Sauf que tu t’es mis à affirmer des trucs absurdes concernant « 50% » ou comme le fait que les calculatrices de nos OS pouvaient indiquer un résultat erroné à une simple addition (ou que le groupe sanguin d'un fichier texte pouvait changer, suite à mon exemple). Et c’est bien ça que je réfute et rejette et pourquoi je poursuis depuis. Et je maintiens mon point : dans les faits concrets, cela ne se produit jamais. Je répète : jamais! ECC ou non, s’il se produit suffisamment d’erreurs de bit pour indiquer 5 au lieu de 4 lorsqu’on tape 2+2, ça va freezer/planter bien avant. Ça ne remonte donc jamais au point de faire ce genre d’erreur significative qui remettrait l’utilisation de l’informatique et des technos numérique en cause dans tous les domaines.

Le rapport avec le Go, AlphaGo/Zero, l'IA, les échecs ?

I.

Lulu Cypher a écrit : 23 févr. 2018, 15:37 Ce n'est pas une démonstration, c'est une hypothèse

Une hypothèse? Mais c’est le monde à l’envers!

C’est à toi de me prouver que ça cause des problèmes concrets aux utilisateurs! Le CQFD n’est pas en rapport avec autre chose que : personne ne constate des erreurs de données dans leurs fichiers. Sinon, je suis d’accord depuis le début que ça peut freezer/planter. Je vous répète seulement que toutes les erreurs « internes » (bit or wathever) dont vous parlez ne changent rien au fait que les utilisateurs que nous sommes n’expérimentent aucune altération de donnée « à l’échelle » utile et pratique.

Lulu Cypher a écrit : 23 févr. 2018, 15:37les erreurs dont je parle arriveront toujours avec une probabilité très très faible mais ce n'est pas une raison pour confondre inpossible et improbable et pourront statistiqument porter sur des données "sensibles"

Mais je sais bien qu'elles arrivent. Mais elles ne se nommes pas « erreur de bit unique » pour rien (c'est un seul bit qui peut être confondu). Prenons l'exemple d'un fichier audio à 44.1KHz. Et supposons que l'erreur de bit concerne les données et qu'il n'y a pas de plantage. Supposons aussi, parmi tout ce qui pourrait être susceptible d'être affecté (affichage d'un pixel à l'écran, autre truc dans le logiciel utilisé, etc.) cela soit précisément un bit qui concerne l'info audio, ben l'erreur va affecter un seul sample sur 44100 samples/s (si l'erreur affecte la def). Mais encore, cela pourrait être l'une des 65 536 valeurs d'amplitude de la résolution (pour du 16 bit, suis généreux, j'aurais pu prendre 32 bit). Bref, dire que cette erreur ne sera pas perceptible est un euphémisme (euphémisme n'est même pas un terme assez « fort » dans ce cas).

Faut aussi comprendre qu'il ne s'agit pas de suites d'erreurs, les unes dernières les autres, se suivant dans un même temps, qui s'agenceraient de façon intelligente pour affecter des donnés ayant un rapport entre elles. Autrement dit, tu n'auras jamais plusieurs erreurs de bit, à un même instant, affectant le sample #1, l'autre le sample #2, etc., et qui finirait pas créer une altération « à notre échelle » utile. Du coup, la donnée utile (quand il n'y a pas de plantage et que l'erreur réussit à remonter jusqu'aux données) n'est jamais altérée au niveau de son interprétation « utilitaire ».

Forum Sceptique

Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Shannon vs Hardy

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0

Re: Un programme bat le champion d'Europe du jeu de go, 5-0