À moins que tu consideres que supporter différentes versions d'un même OS ce soit équivalent à porter sur une plate forme différente?
Tecnhiquement, c'est plus ou moins le cas. Il y a la version de l'OS, mais aussi toutes les caractéristiques de l'appareil (taille de l'écran, présence de senseurs, mémoire, processeur, etc), qui semblent mettre le bazar partout. Google gère ça relativement bien, en cachant les applications non-compatibles dans Google Play (il y a quand même pas mal d'erreurs), mais la conséquence, c'est que sur certains appareils, tu n'as accès qu'à une partie ridicule du store. Du coup, on a beau te dire "l'application existe sur Android", rien ne garantit qu'elle va être disponible pour ton Android. C'est un problème pour tout le monde, développeurs, utilisateurs, commerciaux, vendeurs de téléphone, etc. Et ça donne une mauvaise image d'Android pour tout le monde.
Bof, Google est le premier responsable de la fragmentation, avec la complicité des vendeurs de téléphones (ou l'inverse). Si par exemple il était possible de mettre à jour son Android, il y aurait nettement moins de fragmentation (et on pourrait très bien suggérer aux utilisateurs de mettre à jour leur appareil).
Ce n'est pas Android qui est trop fragmenté, c'est le monde du smartphone en général. Pendant des années, on nous a rabaché que c'était beaucoup trop coûteux pour une boite de maintenir une version Linux en plus des versions Mac et Windows, y compris pour les programmes vendus relativement cher (suite Office, jeux, etc), et maintenant on voudrait nous faire croire qu'il est rentable de développer 10 versions d'applications gratuites?
IA se mettant des coups de pieds au cul récursivement ?
C'est exactement la définition de la singularité technologie, la violence en moins. Si quelqu'un crée une IA capable de s'améliorer elle-même, on va avoir une rupture dans l'histoire de la technologie—des innovations technologiques à profusion, virtuellement instantanées.
La notion d'intelligence artificielle est quasiment impossible à définir de manière consensuelle, mais en tout cas, pour générer une singularité technologique, il lui faut plusieurs propriétés : la capacité de créer des IA plus performantes, et la capacité à inventer des "choses" autres que des IA. La deuxième exclut dans une certaine mesure tout ce qui consiste en du calcul brut. Par exemple, une IA capable de démontrer des théorèmes mathématiques ne pourrait pas enclencher un tel cycle, par contre, une IA capable de créer de nouvelles conjectures, de démontrer des théorèmes, et de produire des IA encore plus fortes pour définir de nouvelles conjectures, de démontrer des théorèmes, et de produire des IA encore plus fortes, pourraient plus ou moins "résoudre" les mathématiques, ce qui serait quand même une sorte de truc important pour l'humanité…
Mouais, si je comprends bien, tu veux dire que l'"OS cérébral" qui a inventé les avions, les ordinateurs, et les centrales nucléaires est le même que celui qui a inventé le fondamentalisme religieux, l'épuration ethnique, et le bizutage. Du coup, on peut très bien disposer prochainement d'un programme d'IA tellement puissant qu'il est capable de concevoir des IA encore plus intelligentes, en le faisant tourner sur une machine qui n'arrive pas à détecter ton imprimante wifi? Ça me parait paradoxal, mais pas forcément plus que l'existence de gamins miséreux qui passent leur vie à récupérer quelques grammes de métaux précieux dans nos poubelles informatiques…
En même temps, c'est un peu la discussion qu'on a eue sur un autre fil il y a peu de temps, est-ce que les datacenters de Google sont vraiment "intelligents"? Contraitement à la plupart des approches en IA, les algorithmes sont profondément bêtes ; ils ne font que chercher des réponses dans la base de données gigantesque des connaissances humaines numérisées. Plus cette base sera exhaustive et plus les algorithmes de recherche seront précis, et plus on aura l'impression d'accéder à une sorte de mémoire centrale de l'humainité. Cependant, une telle structure n'est pas "intelligente" et ne peut rien inventer, rien créer, rien produire à part des synthèses des données qu'elle contient. Elle est donc totalement incapable de générer cette fameuse singularité, son point d'arrivée ne peut être qu'une sorte de Wikipédia incroyablement exhaustive munie d'une interface intuitive, mais elle sera totalement dépendante de la création humaine pour s'enrichir de nouvelles données. Elle va pouvoir te lister tous les algotithmes de tri, mais ne pourra pas en inventer un. Elle pourra te lister des centaines de milliers de conjectures mathématiques, sans pouvoir en démontrer aucune.
J'ai l'impression que dans le domaine logiciel, pour avoir une singularité, il faut impérativement des machines autoprogrammables. Par exemple, des logiciels qui auto-codent de nouvelles fonctionnalités, ce genre de choses. 20 ans me semble très optimiste pour voir une telle technologie fonctionner réellement. Au cours des 20 dernières années, quelles ont réellement été les innovations en terme de programmation (pas les trucs cryptiques et en proof of concept dans les labos de recherche)? Vu comment c'est parti, il ne me semble pas improbable que dans 20 ans, on en soit toujours à peu près au même point…
Pendant que certains se font peur tout seuls avec l'intelligence artificielle, on doit composer tous les jours avec des OS plus ou moins buggués, toujours aussi techniques à installer et à utiliser, et toujours aussi "bêtes". Il y a une évolution très nette des supports informatiques : tout petits ordinateurs avec des écrans tactiles, wifi, toujours plus de données stockées dans un petit espace… Mais pour ce qui est de la qualité générale les logiciels, warf warf. On a utilisé les améliorations des capacités de calcul pour faire tourner les logiciels dans des frameworks de plus en plus lourds (flash, java…) ; les gains de réactivité sur les accès disque ont été plus que largement compensés par la nécessité de pinger un serveur à l'autre bout de la planète pour ouvrir n'importe quelle application… C'est toujours aussi long de développer le moindre logiciel, toujours aussi long de le débugguer, toujours aussi galère pour le faire tourner sur plusieurs plateformes et lui faire passer les mises à jour du système. Bref, on en est encore à passer le plus clair de notre temps à faire tourner des logiciels triviaux correctement. Si d'ici 50 ans on pouvait arriver à des systèmes à peu près stables, à peu près robustes, et à peu près compatibles avec le matériel et le logiciel des autres, je pense que ça serait un progrès très net. Ça me semblerait assez dément d'imaginer que la singularité technologique est imminente alors qu'on sait à peine comment être sûr d'afficher correctement un lecteur vidéo sur une page web…
Tu pourrais au moins me donner le bénéfice du doute et dégrader le sophisme en paralogie… Je revendique l'effet de style, tout le monde a compris que je ne voulais pas dire "tout le monde". (tiens, une paralogie récursive).
Pour rebondir sur les autres commentaires, il y a une différence très nette entre "tout le monde est d'accord pour dire", "tout le monde est d'accord pour faire", et "tout le monde fait". Je suis d'accord pour dire plein de trucs que je ne fais absolument pas. J'irais même plus loin : je suis d'accord pour dire plein de trucs que je n'ai même pas l'intention de faire. Par exemple, je suis d'accord pour dire que ça serait bien que je fasse un régime.
D'un autre côté, ne pas en manger semble entraîner très rapidement une forme de délire pseudoscientifique et des troubles de la personnalité (les gens se prennent pour des experts en études statistiques biomédicales). Le pire dans l'histoire c'est que comme les gens ont l'habitude de justifier leurs idées préconçues en inventant des faits imaginaires, ils ne savent même plus ce que c'est que de raisonner sur la base de données fiables…
Quand bien même, les journaux ne me semblent pas réservés à des contributeurs sans conflits d'intérêt. La plupart du temps, les nouvelles versions de divers logiciels sont présentées par des membres des projets, etc. Ça serait un peu plus gênant que cette personne soit spécifiquement payée pour faire de l'"infopub", mais ça n'est pas non plus antinomique avec l'idée d'un journal.
Ceci dit, je trouve un peu merdique de passer sous Linux en troquant une solution propriétaire pour une autre solution propriétaire. Du point de vue de l'entreprise, rien ne change ; elle est tout autant dépendante de son fournisseur qu'avant. À force de se réjouir des passages à Linux, on oublie le risque de voir tous ces beaux Linux se transformer en systèmes Android, avec un kernel libre et toute la surcouche applicative propriétaire. Bien sûr, c'est important d'avoir des drivers libres, mais est-ce plus important que de pouvoir relire le code des applications qui stockent les données sensibles, communiquent avec l'extérieur, gèrent les clients et fournisseurs, les comptes, les ressources humaines, etc?
On ne pourra jamais faire ça tant que la génération qui a dans les 60-70 ans est encore là. C'est une génération qui a connu, peut-être pas les privations, mais au moins l'idée qu'on puisse ne pas manger ce dont on a envie. C'est donc hyper-important pour eux de manger des quantités de barbaque démentielle. Qui n'a jamais entendu "quand on était gamins, on n'avait pas de la viande à tous les repas"? Actuellement, tout le monde est d'accord pour dire que la viande à tous les repas, c'est profondément débile : c'est inutile, c'est cher, c'est dangereux pour l'environnement, et c'est dangereux pour la santé. Il faudra forcément revenir un jour vers une consommation de viande plus saine, mais ça ne sera jamais possible tant qu'une partie de la population considèrera un tel changement comme une régression dans l'échelle sociale.
En ce qui concerne les requêtes logiquement bien formulées mais qui n'ont pas de réponse directe dans la base de données ("quel temps faisait-il la veille de Noël 2004 à Paris"), j'ai peur que la solution ne vienne que très lentement, par l'ajout de nouvelles fonctions au fil des rapports de bugs. Intuitivement, j'ai l'impression que l'ensemble des requêtes tordues est infini, et qu'il sera toujours possible de formuler quelque chose de logique que la machine ne saura pas interpréter ("quel pilote de F1 est né le lendemain du jour anniversaire de la catastrophe de Tchernobyl?"). Dans un langage de programmation, il y a un jeu de mot-clés, mais dans le langage réel, on peut inventer à volonté des mots clés que la machine ne connait pas. Tu vas documenter "lendemain", "veille", "semaine suivante", etc., mais la liste de concepts me semble infinie ("dont le signe astrologique rime avec 'tuyau'" : bon courage! C'est trivial d'aller chercher la liste des signes astrologiques, mais il faut qu'un programmeur code un bout de script pour expliquer qu'il n'est pas nécessaire d'avoir le signe astrologique dans Wikidata ; on peut le déterminer à partir de la date de naissance. Il faut ensuite aller récupérer la transcription phonétique des mots et comparer le dernier son : encore une fois, ça n'est pas insurmontable, mais il faut juste coder le concept de "rimer". Et il faudra faire ça avec chaque concept. Ça représente probablement des milliers de concepts à coder. Chacun d'entre eux n'est pas spécialement insurmontable, mais c'est la tâche d'ensemble qui est virtuellement infaisable). Résultat, une AI qui semble profondément débile et qui se gamelle sur du niveau école primaire ("Désolé, je ne sais pas ce que veut dire 'avoir le même nombre de consonnes' veut dire"). Avec le temps, et au prix d'une base de code gigantesque, il pourrait devenir de plus en plus dur de trouver des questions triviales que l'IA ne sait pas traiter, mais un tel logiciel n'a pas les propriétés d'un système "intelligent".
Étrangement, j'aurais l'impression que l'affaire des présidents américains est plus facile à traiter. Il suffit d'avoir un algo de tri par défaut, à adpater en fonction du type de liste. Ici, c'est une liste de mandats, la solution est généralisable à toutes les listes de mandats. Ce qui me semble le plus difficile, c'est de déterminer quand il ne faut pas répondre, parce que ça repose sur l'intuition. Un être humain saura très bien qu'il faut comprendre différemment "Quel est le plus grand compositeur" et "quel est le plus grand arbre". Et qu'il faut probablement demander une précision sur "quel est le plus grand basketteur". Trouver la limite à laquelle il est raisonnable de demander une information supplémentaire me semble quasiment impossible. "Quelle est la taille de la Joconde" ne devrait jamais déclencher la question "parlez-vous de la largeur, de la hauteur, ou de l'épaisseur?", alors que répondre "2503 mètres cubes" à "quel est la taille moyenne des parkings publics marseillais" est ridicule.
Donc non, si tu lui sort que t'as un peu trop chaud, elle ne va pas descendre à -2°. Ou alors, il n'y a strictement aucune intelligence :)
Jusqu'à preuve du contraire, une machine n'a aucune intelligence. Il va donc descendre à -2°C s'il pense qu'il doit descendre à -2°C, à moins que son programmeur ait prévu une limite. Dans ce cas, la machine n'est pas plus intelligente qu'avant, c'est juste le programmeur qui l'est.
Enfin bon, pour le moment, ce n'est pas encore de l'intelligence, juste du simulacre, à base d'algorithmes de recommandation, de prédiction… Mais ce n'est qu'une question de temps.
Sur quels arguments te bases-tu? Des séries TV de science fiction? Je ne connais aucun produit grand public ayant les caractéristiques d'une intelligence artificielle. Bien sûr, on peut noter de nombreux progrès dans bien des domaines, et on requalifie le concept d'AI au fur et à mesure. "Gagner aux échecs contre un grand maître" par exemple n'est plus depuis longtemps considéré comme un exemple d'AI, ça n'est que du calcul. Si on considère des applications d'AI "pures", par exemple les chatbots, on n'avance pas très vite. D'ailleurs, c'est assez frustrant, mais les algos qui marchent le mieux sont les moins "intelligents" : on recopie des trucs qui ont l'air de correspondre à des conversations à partir d'une immense base de données. Le big data permet de singer l'intelligence, mais les programmes qui "comprennent" réellement une conversation ne ressemblent pas à grand chose. On pourrait dire la même chose des outils de traduction : quand ça marche à peu près, ça n'est pas lié à une analyse syntaxique et contextuelle, c'est juste un algo qui pioche dans une énorme banque de données de bouts de phrases traduites par des humains.
Bref : ce n'est qu'une question de temps, j'en sais absolument rien. Avec les algorithmes actuels, on pourrait s'approcher de quelque chose qui fait illusion quelques minutes, mais on ne peut rien confier de critique à de telles "intelligences" qui ne comprennent rien : 1) tu n'es jamais à l'abri d'un déraillement total (il n'y a aucun garde fou), et 2) l'intelligence ne pourra jamais faire mieux que d'exploiter sa base de connaissances. Il n'y a pas grand chose à attendre d'un tel algorithme, en tout cas, il est totalement incapable d'innover d'une manière autonome.
Pour ton exemple de photos, ça va pouvoir marcher avec "Montre-moi les photos de Noël". Mais ça pourrait ne jamais marcher avec "Affiche les images prises deux jours avant le 13 Novembre". Pourquoi? Simplement parce que tu utilises un langage de programmation, avec des mot-clés, une syntaxe, des règles, et des opérations prévues par le programmeur. Ce langage est conçu de manière à ressembler à un dialecte du langage naturel, c'est certainement plus pratique que de dire "ShowPic Dec 25", mais ça masque le fait que c'est un dialecte restrictif du langage naturel, qui ne comprendra plus rien dès que tu modifieras la syntaxe de la phrase de manière innocente. Et avec les technologies actuelles, un tel truc ne pourrait marcher qu'avec une connexion permanente à la base de données de Google…
Mouais, le rêve de l'interface intuitive… Je n'ai jamais rien vu de vraiment convainquant. En général, plus c'est censé être intuitif et moins c'est souple (voire, moins c'est utilisable). Ce n'est pas un hasard si en 2015 le moyen le plus efficace de demander des choses complexes à un ordinateur, c'est un terminal et un langage de programmation.
J'ai l'impression qu'il est probablement impossible de commander finement une machine programmable sans savoir ce qu'est une machine programmable et comment elle fonctionne. Ton interface domotique, elle ne va que transformer quelque chose comme "Maison, change la température à 20 degrés dans le salon" en "Command: temp[room0] = 20". Et forcément, ça va être bourré de bugs. "Température à deux degrés de moins que dans la cuisine" et pouf, il fait -2°C dans la baraque. En fait, pour avoir ce qu'on veut, il faudra apprendre un nouveau langage de programmation qui ressemble à un pseudo-langage humain, mais qui n'en est pas un. Un langage pour le frigo, un langage pour la télé, un langage pour le chauffage, un langage pour la voiture, le tout conçu par des américains ou des coréens, qui pige mal le français, qui ne va pas te comprendre quand tu as une trachéite… Une sorte de dépendance inévitable aux limites de tous ces objets débiles que leurs concepteur osent prétentieusement appeler "intelligents". Aucun service rendu, que du gadget.
Pas nécessairement, je ne pense pas que prendre le modulo nécessite un test, par exemple. Éventuellement, le standard pourrait définir plusieurs comportements en fonction de l'architecture, ce qui est pas pareil qu'un comportement indéfini.
Ça pourrait être intéressant de voir les différences de performances induites par ce genre de vérifications. Ça pourrait ne pas être énorme. Après, on peut toujours prétendre que le choix du C est stupide pour 90% des applications codées en C, ce qui est certainement vrai. Ça justifierait de ne pas pénaliser les vrais programmes nécessitant d'être près de la machine parce que les gens ne savent pas utiliser des langages de haut niveau pour coder un démineur.
Je me demande s'il n'y a pas une confusion sur cette histoire de double licence. La solution viable, c'est ce que faisait Qt à une époque : bibliothèque disponible sous double licence : GPL et proprio. Si tu prends la version GPL, c'est gratuit, mais comme tu compiles en liant ton soft à la biliothèque, ton soft doit être distribué sous GPL. Si tu veux le distribuer sous licence proprio, tu achètes une licence proprio. C'est une solution propre et sans aucune ambiguité.
Là, je ne comprends même pas de quoi on parle. Si tu distribues un logiciel sous double licence GPL/licence non-commerciale mais que ça n'est pas une bibliothèque, rien n'empêche le distributeur de recompiler la version GPL et la distribuer sous les conditions de la GPL. Si c'était ça l'idée, ça me semble complètement idiot.
Les licences non-commerciales sont d'une manière généale inutiles et dangereuses. Le problème est évidemment la définition du "non-commercial", puisqu'on peut faire du commerce sans faire de bénéfices, et que de toutes manières ça va forcément sortir des conditions pour être inclu dans les grandes distributions (et au final, personne n'utilisera le logiciel la plupart du temps, ça n'a que peu d'intérêt).
Le seul cas où je trouve que l'esprit de la GPL est violé, c'est quand on use d'explications rocambolesques pour différencier l'utilisateur et le client. Dans l'esprit, le bénéficiaire de la GPL devrait être celui qui utilise le programme, pas celui qui possède le matériel sur lequel le programme fonctionne. Il me semble que c'est plus ou moins réglé dans la GPL v3, mais c'est un trou conceptuel dans la licence de départ.
En fait, je crois qu'on est complètement d'accord : il me parait tout à fait normal d'avoir une erreur ou une valeur à Inf/Nan que de prendre le modulo.
Je ne comprends toujours pas la logique du "comportement indéfini" : clairement, un comportement indéfini signale une instruction invalide (puisqu'elle peut virtuellement avoir n'importe quel effet). Pourquoi ne pas stopper le programme, plutôt que de le laisser se poursuivre dans un état indéterminé?
En C, Selon le standard :
- type signé : comportement indéfini si overflow
- type non-signé: comportement « modulo »
Mouais, l'intérêt de standardiser un comportement indéfini me semble relativement limité (à part pour indiquer au programmeur qu'il ne doit pas faire ça). Du point de vue programmation, le comportement indéfini n'a aucun intérêt (puisqu'on ne peut pas l'exploiter, on doit juste l'éviter), et je dirais que le comportement "modulo" a un intérêt très limité (d'une manière générale, il va être buggogène dans 99% des cas, et dans le 1% restant, tout programmeur normalement constitué va faire un modulo explicite, ne serait-ce que pour des raisons de lisibilité et de portabilité).
Bon, on ne va pas épiloguer pendant des siècles ; tes arguments ne peuvent pas convaincre d'autres que toi. 1) la description des algorithmes ne correspond pas à un mélange aléatoire des cartes (en fait, tu fais des substitutions déterministes en enchaînant plusieurs algorithmes dans l'espoir que l'ensemble n'est pas trop cyclique. Comme on a essayé de te l'expliquer, il y a beaucoup plus simple et beaucoup plus efficace), 2) l'implémentation des algorithmes est bugguée (ils ne font pas ce que tu crois qu'ils font, ce qui justifie ma remarque sur la différence entre "mélanger" et "faire n'importe quoi"), et 3) l'implémentation est terriblement complexe et inefficace, et tu ne peux pas progresser si tu ne te remets pas en question. Par exemple, pour ta dernière fonction, il y a moyen de faire le mélange "en place" (sans rien "malloc-er") avec une seule boucle for: les cartes 0 et 31 restent en place, les autres peuvent être substitutées dans un ordre précis avec juste un pointeur pour stocker une valeur temporaire.
D'un autre côté, il fait ce qu'il veut : beaucoup de développeurs mettent leur code sous licence proprio (ou pour être plus précis, laissent leur code sur leur serveur sans le partager), et ça ne pose pas de problème aux joueurs. L'erreur a été de poster cette annonce sur ce site dédié au logiciel libre. Ça revient à faire de la pub pour une boucherie sur un site végétarien : on s'en prend plein la tronche et c'est bien fait. Parce que sur le fond, ce n'est pas la publication d'un jeu sous licence libre qui va révolutionner le monde, hein…
Je pense qu'il ne sait pas ce qu'il veut. Il veut une communauté sympa pour avoir du retour, créer des cartes, et ne pas être tout seul sur son serveur. Mais en même temps, il veut contrôler le truc : connaitre les adresses emails des gens, garder le code pour lui, et éviter qu'un "concurrent" propose le même jeu sur un serveur miroir de meilleure qualité (puisque personne ne choisirait le concurrent si le service était moins bon).
Pour trouver des gogos abrutis qui filent leur email à tout le monde, qui sont prêts à perdre 20 minutes à essayer n'importe quel jeu sans regarder la licence, et qui souhaitent s'agglomérer en communautés pour se dire "kikoo", "lol", "trop mdr ce jeu" dans un petit chat interactif, il faut faire de la pub sur Facebook.
Je pense que pour un jeu de poker qui ne cherche pas à gérer de l'argent, on s'en fout un peu de l'algorithme de mélange
Il est évident que dans ce contexte précis, en effet, on s'en fout pas mal. Mais c'est du code libre ; il peut être réutilisé par les distributions, éventuellement inclus dans des CD de jeux libres, et réutilisé dans des contextes différents, y compris peut-être des cas où il y a un enjeu un peu plus important. Évidemment, on peut toujours dire qu'il faut relire le code en fonction de l'enjeu, mais c'est un argument foireux : on ne relit pas le code de libreoffice même quand on calcule ses impôts dans le tableur, parce qu'on fait quand même confiance au gars qui l'a programmé.
D'une manière générale, bricoler un algo à la va-vite, on l'a tous fait. La réinvention de la roue est un processus très important dans l'apprentissage de la programmation, et je ne pense pas qu'on puisse devenir un bon programmeur sans avoir réécrit dans l'ignorance la plus totale des algos naïfs de tri, d'échantillonnage, etc. Mais ça, c'est l'étape n°1. On ne va pas rester toute sa vie avec son algo de tri en O(n2). La partie intéressante commence quand on étudie les "vrais" algorithmes, quand on comprend leur logique, et quand on les réimplémente. On s'aperçoit de ses progrès quand on relit son vieux code et qu'on voit à quel point on était mauvais et naïf 10 ans avant. Et ça ne s'arrête jamais, on doit chercher à progresser toute sa vie.
Du coup, je pense qu'il n'y a aucune honte à avoir sur du code pourri. Évidemment, on peut se moquer gentiment des gens qui réintentent tout tous seuls, surtout quand il existe du pseudo-code partout : c'est une forme de naïveté de ne pas imaginer que d'autres avant ont pu rencontrer le même problème et consacrer du temps à le résoudre. Par contre, je pense que c'est une erreur de ne pas vouloir apprendre, et d'avoir une position arrogante face aux critiques. Ici, non seulement l'implémentation est pourrie, mais en plus elle est est bugguée (les cartes ne sont pas mélangées correctement). Quand on pond 200 lignes de code pour faire quelque chose qui devrait tenir en 3 lignes, et qu'en plus ça fait n'importe quoi, on a quand même de la marge de progression.
Sans blague, je ne pense pas que Linuxator sache ce que "for (cc=0 ; cc < get_rand(32) ; cc++ )" fait. Si c'est volontaire, il manque un commentaire sur la loi sous-jacente (binomiale négative?). En tout cas, il existe une différence entre "mélanger les cartes" et "faire n'importe quoi avec le paquet", même si le résultat final pourrait ne pas être totalement différent…
Je pense que l'algo, tel que décrit, est daubé. Les deux dernières étapes ne servent à rien, et si je comprends bien la première, elle est daubée aussi (parce qu'une proportion conséquente des cartes n'est pas mélangée). Même sans l'élégance et la rapidité des algorithmes utilisés en pratique, il aurait suffi de réassigner un nouvel ordre : on tire 32 nombres aléatoires ente 0 et 1, et on utilise l'ordre du vecteur pour réordonner le paquet (on doit être en O(n log n)).
Je ne vois pas vraiment de raison pour que le C++ soit plus lent que le C.
Il y a plusieurs niveaux de réponse. Le premier niveau, évidemment, c'est que le C est (à peu près) valide en C++, et qu'il suffit de coder en C pour avoir les mêmes performances. Le deuxième niveau est que ça dépend ; en théorie, on peut faire plus de choses au C++ au moment de la compilation, et que sur des cas particuliers, C++ peut être plus rapide que C (il y a des exemples d'algorithmes qui peuvent même être résolus au moment de la compilation en C++ via des templates ou des constructions un peu complexes). Le troisième niveau, le "vrai" niveau, consiste à admettre que la richesse du C++, la programmation objet, la STL, etc, ont des contraintes qui ajoutent un coût significatif—et là, on est bien d'accord, on n'est pas à fonctionalités égales. Les fonctions virtuelles, ont un coût, par exemple. Par ailleurs, les idiomes du C++ sont plus lourds que le C ; par exemple, on a tendance à faire beaucoup plus de tests pour vérifier l'intégrité des classes ; il est également plus facile en C++ d'appeler du code inutile (constructeur par défaut…) involontairement.
utiliser des char[] dans l'array, et pas des std::string
Ce genre de trucs, par exemple, me semblent relever du fameux C/C++, une sorte de langage indéterminé qui mélange les idiomes des deux langages. Après, chacun fait ce qu'il veut, et il n'existe pas encore de religieux intégristes du C++. Mais personnellement je trouve que c'est dommage de perdre la sémantique (un std::string n'est pas un std::vector en C++) pour gagner un micropouillème hypothétique au moment de l'exécution (sans compter qu'il n'est pas impossible que le compilo détecte les concaténation de chaines constantes, et que plus le code est clair, plus le compilo est efficace).
[^] # Re: Merci pour cette news et pour les commentaires
Posté par arnaudus . En réponse à la dépêche Se passer de Dropbox en montant son coffre-fort numérique à la maison. Évalué à 3.
Qu'est-ce qui t'empêche de chiffrer tes documents sensibles avant de les mettre sur le serveur du tiers en qui tu n'as pas confiance?
[^] # Re: Point sécurité.
Posté par arnaudus . En réponse à la dépêche Se passer de Dropbox en montant son coffre-fort numérique à la maison. Évalué à 3.
Vu que le possesseur dudit képi est en droit de te demander ta clé de chiffrage, je ne vois pas vraiment ce que ça change.
[^] # Re: Fragmentation
Posté par arnaudus . En réponse au journal Microsoft investit dans CyanogenMod !?. Évalué à 3.
Tecnhiquement, c'est plus ou moins le cas. Il y a la version de l'OS, mais aussi toutes les caractéristiques de l'appareil (taille de l'écran, présence de senseurs, mémoire, processeur, etc), qui semblent mettre le bazar partout. Google gère ça relativement bien, en cachant les applications non-compatibles dans Google Play (il y a quand même pas mal d'erreurs), mais la conséquence, c'est que sur certains appareils, tu n'as accès qu'à une partie ridicule du store. Du coup, on a beau te dire "l'application existe sur Android", rien ne garantit qu'elle va être disponible pour ton Android. C'est un problème pour tout le monde, développeurs, utilisateurs, commerciaux, vendeurs de téléphone, etc. Et ça donne une mauvaise image d'Android pour tout le monde.
[^] # Re: Fragmentation
Posté par arnaudus . En réponse au journal Microsoft investit dans CyanogenMod !?. Évalué à 10.
Bof, Google est le premier responsable de la fragmentation, avec la complicité des vendeurs de téléphones (ou l'inverse). Si par exemple il était possible de mettre à jour son Android, il y aurait nettement moins de fragmentation (et on pourrait très bien suggérer aux utilisateurs de mettre à jour leur appareil).
Ce n'est pas Android qui est trop fragmenté, c'est le monde du smartphone en général. Pendant des années, on nous a rabaché que c'était beaucoup trop coûteux pour une boite de maintenir une version Linux en plus des versions Mac et Windows, y compris pour les programmes vendus relativement cher (suite Office, jeux, etc), et maintenant on voudrait nous faire croire qu'il est rentable de développer 10 versions d'applications gratuites?
[^] # Re: Intelligence artificielle... warf...
Posté par arnaudus . En réponse au journal Bill Gates est « préoccupé par la superintelligence » artificielle . Évalué à 5.
C'est exactement la définition de la singularité technologie, la violence en moins. Si quelqu'un crée une IA capable de s'améliorer elle-même, on va avoir une rupture dans l'histoire de la technologie—des innovations technologiques à profusion, virtuellement instantanées.
La notion d'intelligence artificielle est quasiment impossible à définir de manière consensuelle, mais en tout cas, pour générer une singularité technologique, il lui faut plusieurs propriétés : la capacité de créer des IA plus performantes, et la capacité à inventer des "choses" autres que des IA. La deuxième exclut dans une certaine mesure tout ce qui consiste en du calcul brut. Par exemple, une IA capable de démontrer des théorèmes mathématiques ne pourrait pas enclencher un tel cycle, par contre, une IA capable de créer de nouvelles conjectures, de démontrer des théorèmes, et de produire des IA encore plus fortes pour définir de nouvelles conjectures, de démontrer des théorèmes, et de produire des IA encore plus fortes, pourraient plus ou moins "résoudre" les mathématiques, ce qui serait quand même une sorte de truc important pour l'humanité…
[^] # Re: Intelligence artificielle... warf...
Posté par arnaudus . En réponse au journal Bill Gates est « préoccupé par la superintelligence » artificielle . Évalué à 5.
Mouais, si je comprends bien, tu veux dire que l'"OS cérébral" qui a inventé les avions, les ordinateurs, et les centrales nucléaires est le même que celui qui a inventé le fondamentalisme religieux, l'épuration ethnique, et le bizutage. Du coup, on peut très bien disposer prochainement d'un programme d'IA tellement puissant qu'il est capable de concevoir des IA encore plus intelligentes, en le faisant tourner sur une machine qui n'arrive pas à détecter ton imprimante wifi? Ça me parait paradoxal, mais pas forcément plus que l'existence de gamins miséreux qui passent leur vie à récupérer quelques grammes de métaux précieux dans nos poubelles informatiques…
[^] # Re: Intelligence artificielle... warf...
Posté par arnaudus . En réponse au journal Bill Gates est « préoccupé par la superintelligence » artificielle . Évalué à 6.
En même temps, c'est un peu la discussion qu'on a eue sur un autre fil il y a peu de temps, est-ce que les datacenters de Google sont vraiment "intelligents"? Contraitement à la plupart des approches en IA, les algorithmes sont profondément bêtes ; ils ne font que chercher des réponses dans la base de données gigantesque des connaissances humaines numérisées. Plus cette base sera exhaustive et plus les algorithmes de recherche seront précis, et plus on aura l'impression d'accéder à une sorte de mémoire centrale de l'humainité. Cependant, une telle structure n'est pas "intelligente" et ne peut rien inventer, rien créer, rien produire à part des synthèses des données qu'elle contient. Elle est donc totalement incapable de générer cette fameuse singularité, son point d'arrivée ne peut être qu'une sorte de Wikipédia incroyablement exhaustive munie d'une interface intuitive, mais elle sera totalement dépendante de la création humaine pour s'enrichir de nouvelles données. Elle va pouvoir te lister tous les algotithmes de tri, mais ne pourra pas en inventer un. Elle pourra te lister des centaines de milliers de conjectures mathématiques, sans pouvoir en démontrer aucune.
J'ai l'impression que dans le domaine logiciel, pour avoir une singularité, il faut impérativement des machines autoprogrammables. Par exemple, des logiciels qui auto-codent de nouvelles fonctionnalités, ce genre de choses. 20 ans me semble très optimiste pour voir une telle technologie fonctionner réellement. Au cours des 20 dernières années, quelles ont réellement été les innovations en terme de programmation (pas les trucs cryptiques et en proof of concept dans les labos de recherche)? Vu comment c'est parti, il ne me semble pas improbable que dans 20 ans, on en soit toujours à peu près au même point…
# Intelligence artificielle... warf...
Posté par arnaudus . En réponse au journal Bill Gates est « préoccupé par la superintelligence » artificielle . Évalué à 10.
Pendant que certains se font peur tout seuls avec l'intelligence artificielle, on doit composer tous les jours avec des OS plus ou moins buggués, toujours aussi techniques à installer et à utiliser, et toujours aussi "bêtes". Il y a une évolution très nette des supports informatiques : tout petits ordinateurs avec des écrans tactiles, wifi, toujours plus de données stockées dans un petit espace… Mais pour ce qui est de la qualité générale les logiciels, warf warf. On a utilisé les améliorations des capacités de calcul pour faire tourner les logiciels dans des frameworks de plus en plus lourds (flash, java…) ; les gains de réactivité sur les accès disque ont été plus que largement compensés par la nécessité de pinger un serveur à l'autre bout de la planète pour ouvrir n'importe quelle application… C'est toujours aussi long de développer le moindre logiciel, toujours aussi long de le débugguer, toujours aussi galère pour le faire tourner sur plusieurs plateformes et lui faire passer les mises à jour du système. Bref, on en est encore à passer le plus clair de notre temps à faire tourner des logiciels triviaux correctement. Si d'ici 50 ans on pouvait arriver à des systèmes à peu près stables, à peu près robustes, et à peu près compatibles avec le matériel et le logiciel des autres, je pense que ça serait un progrès très net. Ça me semblerait assez dément d'imaginer que la singularité technologique est imminente alors qu'on sait à peine comment être sûr d'afficher correctement un lecteur vidéo sur une page web…
[^] # Re: La viande !
Posté par arnaudus . En réponse au journal Climat et logiciel. Évalué à 0.
Tu pourrais au moins me donner le bénéfice du doute et dégrader le sophisme en paralogie… Je revendique l'effet de style, tout le monde a compris que je ne voulais pas dire "tout le monde". (tiens, une paralogie récursive).
Pour rebondir sur les autres commentaires, il y a une différence très nette entre "tout le monde est d'accord pour dire", "tout le monde est d'accord pour faire", et "tout le monde fait". Je suis d'accord pour dire plein de trucs que je ne fais absolument pas. J'irais même plus loin : je suis d'accord pour dire plein de trucs que je n'ai même pas l'intention de faire. Par exemple, je suis d'accord pour dire que ça serait bien que je fasse un régime.
[^] # Re: La viande !
Posté par arnaudus . En réponse au journal Climat et logiciel. Évalué à 10.
D'un autre côté, ne pas en manger semble entraîner très rapidement une forme de délire pseudoscientifique et des troubles de la personnalité (les gens se prennent pour des experts en études statistiques biomédicales). Le pire dans l'histoire c'est que comme les gens ont l'habitude de justifier leurs idées préconçues en inventant des faits imaginaires, ils ne savent même plus ce que c'est que de raisonner sur la base de données fiables…
[^] # Re: pub?
Posté par arnaudus . En réponse au journal Le Port de San Diego migre sous Linux !. Évalué à 10.
Quand bien même, les journaux ne me semblent pas réservés à des contributeurs sans conflits d'intérêt. La plupart du temps, les nouvelles versions de divers logiciels sont présentées par des membres des projets, etc. Ça serait un peu plus gênant que cette personne soit spécifiquement payée pour faire de l'"infopub", mais ça n'est pas non plus antinomique avec l'idée d'un journal.
Ceci dit, je trouve un peu merdique de passer sous Linux en troquant une solution propriétaire pour une autre solution propriétaire. Du point de vue de l'entreprise, rien ne change ; elle est tout autant dépendante de son fournisseur qu'avant. À force de se réjouir des passages à Linux, on oublie le risque de voir tous ces beaux Linux se transformer en systèmes Android, avec un kernel libre et toute la surcouche applicative propriétaire. Bien sûr, c'est important d'avoir des drivers libres, mais est-ce plus important que de pouvoir relire le code des applications qui stockent les données sensibles, communiquent avec l'extérieur, gèrent les clients et fournisseurs, les comptes, les ressources humaines, etc?
[^] # Re: La viande !
Posté par arnaudus . En réponse au journal Climat et logiciel. Évalué à 8.
On ne pourra jamais faire ça tant que la génération qui a dans les 60-70 ans est encore là. C'est une génération qui a connu, peut-être pas les privations, mais au moins l'idée qu'on puisse ne pas manger ce dont on a envie. C'est donc hyper-important pour eux de manger des quantités de barbaque démentielle. Qui n'a jamais entendu "quand on était gamins, on n'avait pas de la viande à tous les repas"? Actuellement, tout le monde est d'accord pour dire que la viande à tous les repas, c'est profondément débile : c'est inutile, c'est cher, c'est dangereux pour l'environnement, et c'est dangereux pour la santé. Il faudra forcément revenir un jour vers une consommation de viande plus saine, mais ça ne sera jamais possible tant qu'une partie de la population considèrera un tel changement comme une régression dans l'échelle sociale.
[^] # Re: Assistant personnel
Posté par arnaudus . En réponse au journal Galaxie Wikidata : le hub est en extension. Évalué à 2.
Merci pour la réponse détaillée.
En ce qui concerne les requêtes logiquement bien formulées mais qui n'ont pas de réponse directe dans la base de données ("quel temps faisait-il la veille de Noël 2004 à Paris"), j'ai peur que la solution ne vienne que très lentement, par l'ajout de nouvelles fonctions au fil des rapports de bugs. Intuitivement, j'ai l'impression que l'ensemble des requêtes tordues est infini, et qu'il sera toujours possible de formuler quelque chose de logique que la machine ne saura pas interpréter ("quel pilote de F1 est né le lendemain du jour anniversaire de la catastrophe de Tchernobyl?"). Dans un langage de programmation, il y a un jeu de mot-clés, mais dans le langage réel, on peut inventer à volonté des mots clés que la machine ne connait pas. Tu vas documenter "lendemain", "veille", "semaine suivante", etc., mais la liste de concepts me semble infinie ("dont le signe astrologique rime avec 'tuyau'" : bon courage! C'est trivial d'aller chercher la liste des signes astrologiques, mais il faut qu'un programmeur code un bout de script pour expliquer qu'il n'est pas nécessaire d'avoir le signe astrologique dans Wikidata ; on peut le déterminer à partir de la date de naissance. Il faut ensuite aller récupérer la transcription phonétique des mots et comparer le dernier son : encore une fois, ça n'est pas insurmontable, mais il faut juste coder le concept de "rimer". Et il faudra faire ça avec chaque concept. Ça représente probablement des milliers de concepts à coder. Chacun d'entre eux n'est pas spécialement insurmontable, mais c'est la tâche d'ensemble qui est virtuellement infaisable). Résultat, une AI qui semble profondément débile et qui se gamelle sur du niveau école primaire ("Désolé, je ne sais pas ce que veut dire 'avoir le même nombre de consonnes' veut dire"). Avec le temps, et au prix d'une base de code gigantesque, il pourrait devenir de plus en plus dur de trouver des questions triviales que l'IA ne sait pas traiter, mais un tel logiciel n'a pas les propriétés d'un système "intelligent".
Étrangement, j'aurais l'impression que l'affaire des présidents américains est plus facile à traiter. Il suffit d'avoir un algo de tri par défaut, à adpater en fonction du type de liste. Ici, c'est une liste de mandats, la solution est généralisable à toutes les listes de mandats. Ce qui me semble le plus difficile, c'est de déterminer quand il ne faut pas répondre, parce que ça repose sur l'intuition. Un être humain saura très bien qu'il faut comprendre différemment "Quel est le plus grand compositeur" et "quel est le plus grand arbre". Et qu'il faut probablement demander une précision sur "quel est le plus grand basketteur". Trouver la limite à laquelle il est raisonnable de demander une information supplémentaire me semble quasiment impossible. "Quelle est la taille de la Joconde" ne devrait jamais déclencher la question "parlez-vous de la largeur, de la hauteur, ou de l'épaisseur?", alors que répondre "2503 mètres cubes" à "quel est la taille moyenne des parkings publics marseillais" est ridicule.
[^] # Re: Assistant personnel
Posté par arnaudus . En réponse au journal Galaxie Wikidata : le hub est en extension. Évalué à 2.
Jusqu'à preuve du contraire, une machine n'a aucune intelligence. Il va donc descendre à -2°C s'il pense qu'il doit descendre à -2°C, à moins que son programmeur ait prévu une limite. Dans ce cas, la machine n'est pas plus intelligente qu'avant, c'est juste le programmeur qui l'est.
Sur quels arguments te bases-tu? Des séries TV de science fiction? Je ne connais aucun produit grand public ayant les caractéristiques d'une intelligence artificielle. Bien sûr, on peut noter de nombreux progrès dans bien des domaines, et on requalifie le concept d'AI au fur et à mesure. "Gagner aux échecs contre un grand maître" par exemple n'est plus depuis longtemps considéré comme un exemple d'AI, ça n'est que du calcul. Si on considère des applications d'AI "pures", par exemple les chatbots, on n'avance pas très vite. D'ailleurs, c'est assez frustrant, mais les algos qui marchent le mieux sont les moins "intelligents" : on recopie des trucs qui ont l'air de correspondre à des conversations à partir d'une immense base de données. Le big data permet de singer l'intelligence, mais les programmes qui "comprennent" réellement une conversation ne ressemblent pas à grand chose. On pourrait dire la même chose des outils de traduction : quand ça marche à peu près, ça n'est pas lié à une analyse syntaxique et contextuelle, c'est juste un algo qui pioche dans une énorme banque de données de bouts de phrases traduites par des humains.
Bref : ce n'est qu'une question de temps, j'en sais absolument rien. Avec les algorithmes actuels, on pourrait s'approcher de quelque chose qui fait illusion quelques minutes, mais on ne peut rien confier de critique à de telles "intelligences" qui ne comprennent rien : 1) tu n'es jamais à l'abri d'un déraillement total (il n'y a aucun garde fou), et 2) l'intelligence ne pourra jamais faire mieux que d'exploiter sa base de connaissances. Il n'y a pas grand chose à attendre d'un tel algorithme, en tout cas, il est totalement incapable d'innover d'une manière autonome.
Pour ton exemple de photos, ça va pouvoir marcher avec "Montre-moi les photos de Noël". Mais ça pourrait ne jamais marcher avec "Affiche les images prises deux jours avant le 13 Novembre". Pourquoi? Simplement parce que tu utilises un langage de programmation, avec des mot-clés, une syntaxe, des règles, et des opérations prévues par le programmeur. Ce langage est conçu de manière à ressembler à un dialecte du langage naturel, c'est certainement plus pratique que de dire "ShowPic Dec 25", mais ça masque le fait que c'est un dialecte restrictif du langage naturel, qui ne comprendra plus rien dès que tu modifieras la syntaxe de la phrase de manière innocente. Et avec les technologies actuelles, un tel truc ne pourrait marcher qu'avec une connexion permanente à la base de données de Google…
[^] # Re: Assistant personnel
Posté par arnaudus . En réponse au journal Galaxie Wikidata : le hub est en extension. Évalué à 4.
Mouais, le rêve de l'interface intuitive… Je n'ai jamais rien vu de vraiment convainquant. En général, plus c'est censé être intuitif et moins c'est souple (voire, moins c'est utilisable). Ce n'est pas un hasard si en 2015 le moyen le plus efficace de demander des choses complexes à un ordinateur, c'est un terminal et un langage de programmation.
J'ai l'impression qu'il est probablement impossible de commander finement une machine programmable sans savoir ce qu'est une machine programmable et comment elle fonctionne. Ton interface domotique, elle ne va que transformer quelque chose comme "Maison, change la température à 20 degrés dans le salon" en "Command: temp[room0] = 20". Et forcément, ça va être bourré de bugs. "Température à deux degrés de moins que dans la cuisine" et pouf, il fait -2°C dans la baraque. En fait, pour avoir ce qu'on veut, il faudra apprendre un nouveau langage de programmation qui ressemble à un pseudo-langage humain, mais qui n'en est pas un. Un langage pour le frigo, un langage pour la télé, un langage pour le chauffage, un langage pour la voiture, le tout conçu par des américains ou des coréens, qui pige mal le français, qui ne va pas te comprendre quand tu as une trachéite… Une sorte de dépendance inévitable aux limites de tous ces objets débiles que leurs concepteur osent prétentieusement appeler "intelligents". Aucun service rendu, que du gadget.
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par arnaudus . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Pas nécessairement, je ne pense pas que prendre le modulo nécessite un test, par exemple. Éventuellement, le standard pourrait définir plusieurs comportements en fonction de l'architecture, ce qui est pas pareil qu'un comportement indéfini.
Ça pourrait être intéressant de voir les différences de performances induites par ce genre de vérifications. Ça pourrait ne pas être énorme. Après, on peut toujours prétendre que le choix du C est stupide pour 90% des applications codées en C, ce qui est certainement vrai. Ça justifierait de ne pas pénaliser les vrais programmes nécessitant d'être près de la machine parce que les gens ne savent pas utiliser des langages de haut niveau pour coder un démineur.
[^] # Re: changement de licence
Posté par arnaudus . En réponse au journal GNU GPL et commercialisation : mauvaise compréhension des licences, l'exemple WPScan. Évalué à 4.
Je me demande s'il n'y a pas une confusion sur cette histoire de double licence. La solution viable, c'est ce que faisait Qt à une époque : bibliothèque disponible sous double licence : GPL et proprio. Si tu prends la version GPL, c'est gratuit, mais comme tu compiles en liant ton soft à la biliothèque, ton soft doit être distribué sous GPL. Si tu veux le distribuer sous licence proprio, tu achètes une licence proprio. C'est une solution propre et sans aucune ambiguité.
Là, je ne comprends même pas de quoi on parle. Si tu distribues un logiciel sous double licence GPL/licence non-commerciale mais que ça n'est pas une bibliothèque, rien n'empêche le distributeur de recompiler la version GPL et la distribuer sous les conditions de la GPL. Si c'était ça l'idée, ça me semble complètement idiot.
Les licences non-commerciales sont d'une manière généale inutiles et dangereuses. Le problème est évidemment la définition du "non-commercial", puisqu'on peut faire du commerce sans faire de bénéfices, et que de toutes manières ça va forcément sortir des conditions pour être inclu dans les grandes distributions (et au final, personne n'utilisera le logiciel la plupart du temps, ça n'a que peu d'intérêt).
Le seul cas où je trouve que l'esprit de la GPL est violé, c'est quand on use d'explications rocambolesques pour différencier l'utilisateur et le client. Dans l'esprit, le bénéficiaire de la GPL devrait être celui qui utilise le programme, pas celui qui possède le matériel sur lequel le programme fonctionne. Il me semble que c'est plus ou moins réglé dans la GPL v3, mais c'est un trou conceptuel dans la licence de départ.
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par arnaudus . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 1.
En fait, je crois qu'on est complètement d'accord : il me parait tout à fait normal d'avoir une erreur ou une valeur à Inf/Nan que de prendre le modulo.
Je ne comprends toujours pas la logique du "comportement indéfini" : clairement, un comportement indéfini signale une instruction invalide (puisqu'elle peut virtuellement avoir n'importe quel effet). Pourquoi ne pas stopper le programme, plutôt que de le laisser se poursuivre dans un état indéterminé?
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par arnaudus . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 4.
Mouais, l'intérêt de standardiser un comportement indéfini me semble relativement limité (à part pour indiquer au programmeur qu'il ne doit pas faire ça). Du point de vue programmation, le comportement indéfini n'a aucun intérêt (puisqu'on ne peut pas l'exploiter, on doit juste l'éviter), et je dirais que le comportement "modulo" a un intérêt très limité (d'une manière générale, il va être buggogène dans 99% des cas, et dans le 1% restant, tout programmeur normalement constitué va faire un modulo explicite, ne serait-ce que pour des raisons de lisibilité et de portabilité).
[^] # Re: Mélange des cartes
Posté par arnaudus . En réponse au message Jeu de poker pour Linux.. Évalué à 3.
Bon, on ne va pas épiloguer pendant des siècles ; tes arguments ne peuvent pas convaincre d'autres que toi. 1) la description des algorithmes ne correspond pas à un mélange aléatoire des cartes (en fait, tu fais des substitutions déterministes en enchaînant plusieurs algorithmes dans l'espoir que l'ensemble n'est pas trop cyclique. Comme on a essayé de te l'expliquer, il y a beaucoup plus simple et beaucoup plus efficace), 2) l'implémentation des algorithmes est bugguée (ils ne font pas ce que tu crois qu'ils font, ce qui justifie ma remarque sur la différence entre "mélanger" et "faire n'importe quoi"), et 3) l'implémentation est terriblement complexe et inefficace, et tu ne peux pas progresser si tu ne te remets pas en question. Par exemple, pour ta dernière fonction, il y a moyen de faire le mélange "en place" (sans rien "malloc-er") avec une seule boucle for: les cartes 0 et 31 restent en place, les autres peuvent être substitutées dans un ordre précis avec juste un pointeur pour stocker une valeur temporaire.
[^] # Re: Mise au point
Posté par arnaudus . En réponse au journal [Trackgame] Jeu de course vectoriel au tour par tour. Évalué à 8.
D'un autre côté, il fait ce qu'il veut : beaucoup de développeurs mettent leur code sous licence proprio (ou pour être plus précis, laissent leur code sur leur serveur sans le partager), et ça ne pose pas de problème aux joueurs. L'erreur a été de poster cette annonce sur ce site dédié au logiciel libre. Ça revient à faire de la pub pour une boucherie sur un site végétarien : on s'en prend plein la tronche et c'est bien fait. Parce que sur le fond, ce n'est pas la publication d'un jeu sous licence libre qui va révolutionner le monde, hein…
[^] # Re: Dommage de fermer le machin...
Posté par arnaudus . En réponse au journal [Trackgame] Jeu de course vectoriel au tour par tour. Évalué à 10.
Je pense qu'il ne sait pas ce qu'il veut. Il veut une communauté sympa pour avoir du retour, créer des cartes, et ne pas être tout seul sur son serveur. Mais en même temps, il veut contrôler le truc : connaitre les adresses emails des gens, garder le code pour lui, et éviter qu'un "concurrent" propose le même jeu sur un serveur miroir de meilleure qualité (puisque personne ne choisirait le concurrent si le service était moins bon).
Pour trouver des gogos abrutis qui filent leur email à tout le monde, qui sont prêts à perdre 20 minutes à essayer n'importe quel jeu sans regarder la licence, et qui souhaitent s'agglomérer en communautés pour se dire "kikoo", "lol", "trop mdr ce jeu" dans un petit chat interactif, il faut faire de la pub sur Facebook.
[^] # Re: Mélange des cartes
Posté par arnaudus . En réponse au message Jeu de poker pour Linux.. Évalué à 3.
Il est évident que dans ce contexte précis, en effet, on s'en fout pas mal. Mais c'est du code libre ; il peut être réutilisé par les distributions, éventuellement inclus dans des CD de jeux libres, et réutilisé dans des contextes différents, y compris peut-être des cas où il y a un enjeu un peu plus important. Évidemment, on peut toujours dire qu'il faut relire le code en fonction de l'enjeu, mais c'est un argument foireux : on ne relit pas le code de libreoffice même quand on calcule ses impôts dans le tableur, parce qu'on fait quand même confiance au gars qui l'a programmé.
D'une manière générale, bricoler un algo à la va-vite, on l'a tous fait. La réinvention de la roue est un processus très important dans l'apprentissage de la programmation, et je ne pense pas qu'on puisse devenir un bon programmeur sans avoir réécrit dans l'ignorance la plus totale des algos naïfs de tri, d'échantillonnage, etc. Mais ça, c'est l'étape n°1. On ne va pas rester toute sa vie avec son algo de tri en O(n2). La partie intéressante commence quand on étudie les "vrais" algorithmes, quand on comprend leur logique, et quand on les réimplémente. On s'aperçoit de ses progrès quand on relit son vieux code et qu'on voit à quel point on était mauvais et naïf 10 ans avant. Et ça ne s'arrête jamais, on doit chercher à progresser toute sa vie.
Du coup, je pense qu'il n'y a aucune honte à avoir sur du code pourri. Évidemment, on peut se moquer gentiment des gens qui réintentent tout tous seuls, surtout quand il existe du pseudo-code partout : c'est une forme de naïveté de ne pas imaginer que d'autres avant ont pu rencontrer le même problème et consacrer du temps à le résoudre. Par contre, je pense que c'est une erreur de ne pas vouloir apprendre, et d'avoir une position arrogante face aux critiques. Ici, non seulement l'implémentation est pourrie, mais en plus elle est est bugguée (les cartes ne sont pas mélangées correctement). Quand on pond 200 lignes de code pour faire quelque chose qui devrait tenir en 3 lignes, et qu'en plus ça fait n'importe quoi, on a quand même de la marge de progression.
Sans blague, je ne pense pas que Linuxator sache ce que "for (cc=0 ; cc < get_rand(32) ; cc++ )" fait. Si c'est volontaire, il manque un commentaire sur la loi sous-jacente (binomiale négative?). En tout cas, il existe une différence entre "mélanger les cartes" et "faire n'importe quoi avec le paquet", même si le résultat final pourrait ne pas être totalement différent…
[^] # Re: Mélange des cartes
Posté par arnaudus . En réponse au message Jeu de poker pour Linux.. Évalué à 1.
Je pense que l'algo, tel que décrit, est daubé. Les deux dernières étapes ne servent à rien, et si je comprends bien la première, elle est daubée aussi (parce qu'une proportion conséquente des cartes n'est pas mélangée). Même sans l'élégance et la rapidité des algorithmes utilisés en pratique, il aurait suffi de réassigner un nouvel ordre : on tire 32 nombres aléatoires ente 0 et 1, et on utilise l'ordre du vecteur pour réordonner le paquet (on doit être en O(n log n)).
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par arnaudus . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 5.
Il y a plusieurs niveaux de réponse. Le premier niveau, évidemment, c'est que le C est (à peu près) valide en C++, et qu'il suffit de coder en C pour avoir les mêmes performances. Le deuxième niveau est que ça dépend ; en théorie, on peut faire plus de choses au C++ au moment de la compilation, et que sur des cas particuliers, C++ peut être plus rapide que C (il y a des exemples d'algorithmes qui peuvent même être résolus au moment de la compilation en C++ via des templates ou des constructions un peu complexes). Le troisième niveau, le "vrai" niveau, consiste à admettre que la richesse du C++, la programmation objet, la STL, etc, ont des contraintes qui ajoutent un coût significatif—et là, on est bien d'accord, on n'est pas à fonctionalités égales. Les fonctions virtuelles, ont un coût, par exemple. Par ailleurs, les idiomes du C++ sont plus lourds que le C ; par exemple, on a tendance à faire beaucoup plus de tests pour vérifier l'intégrité des classes ; il est également plus facile en C++ d'appeler du code inutile (constructeur par défaut…) involontairement.
Ce genre de trucs, par exemple, me semblent relever du fameux C/C++, une sorte de langage indéterminé qui mélange les idiomes des deux langages. Après, chacun fait ce qu'il veut, et il n'existe pas encore de religieux intégristes du C++. Mais personnellement je trouve que c'est dommage de perdre la sémantique (un std::string n'est pas un std::vector en C++) pour gagner un micropouillème hypothétique au moment de l'exécution (sans compter qu'il n'est pas impossible que le compilo détecte les concaténation de chaines constantes, et que plus le code est clair, plus le compilo est efficace).