Astronomie, informatique et science

Catégorie : Informatique Page 1 of 3

Les erreurs de ChatGPT et autres IAs

Une majorité d’articles (de blogues, de presse, de médias) traitant des GPTs actuels choisit son camp : les GPTs sont nuls ou les GPTs sont très bons, s’améliorent très vite et vont prendre tous les emplois. La vérité est probablement entre les deux.

Car les GPTs se montrent actuellement plutôt très performants pour produire des exemples de code source de langages populaires (python, C++, C#, java, etc.) ou même compléter/adapter/corriger du code source pas trop long.

Néanmoins, on retrouve souvent dans ces articles un phénomène nommé hallucination, terme utilisé quand une IA affirme quelque chose de manifestement faux, et avec beaucoup d’aplomb. Ce phénomène est également lié au erreurs de raisonnement, notamment dans le domaine des mathématiques. Ces erreurs sont particulièrement graves. En voici un exemple :

Erreur de raisonnement de ChatGPT

Ainsi, dans un contexte pas spécialement compliqué, ChatGPT est capable d’affirmer que 0 moins 1 vaut 26. Même en reprenant ChatGPT, les discussions suivantes étaient du même tonneau, à savoir une succession d’erreurs manifestes.

Ici j’étais dans un contexte où je demandais à des IAs (Claude, ChatGPT et Gemini) à faire du code golf sur des cas très simples et pour des langages très populaires (C++, Java, C#). Toutes ces IAs ont beaucoup de difficulté avec le code golf. Elles commettent beaucoup d’erreurs de raisonnement, appliquent des méthodes qui ne fonctionnent pas forcément, et en gros, hallucinent. Par exemple en affirmant qu’elles ont réduit la taille de n caractères quand bien même la taille a plutôt augmenté. Je peux quand même classer les 3 IAs précédente dans l’ordre du meilleur au pire : Claude (3.5 Sonnet), ChatGPT (4) et Gemini.

Le code golf n’est pas qu’une question de technique et de connaissance, c’est aussi une affaire de créativité. Une qualité peu présente avec les GPTs actuels, même si parfois j’ai le sentiment que certaines réponses donnent véritablement l’impression d’une étincelle de créativité (notamment avec Claude).

Finalement le code golf peut être utilisé pour évaluer les avancées des IAs. Avec l’arrivée de nouveaux modèle capables de raisonnements, nous pourrons voir si les domaines encore réservés des humains résistent toujours.

Coder avec un crayon et un papier ?

Dans la série des idées que l’on aurait pu découvrir un 1er avril sur le ton de l’humour, on découvre dans l’actualité : On peut « coder sans ordinateur, avec un crayon et un papier ». L’idée va même plus loin et suggère de limiter la bande passante sur Internet à 3 Go par semaine et par personne.

Il est toujours surprenant de voir des personnes faisant preuve d’ultracrépidarianisme. Car non, on ne code pas avec un crayon et un papier, excepté pour les rares cas d’apprentissage (et encore) ou d’entretien d’embauche (là aussi, c’est devenu rare). Coder autrement sans ordinateur est un non sens et une perte de temps totale.

Comment qualifier aussi la limitation de bande passante, à l’heure du télétravail, de la vidéo à la demande ou de l’ère dite du « Big Data » ?

Par exemple, télécharger le catalogue astrométrique Gaia DR3 afin de faire des études sur des catégories d’objets célestes, cela représente un total d’environ 10 To. Soit plus de 3400 semaines (plus de 65 années) à raison de 3 Go par semaine. Bref, une idée à oublier d’urgence.

Codeur du futur reportant ses modifications depuis son papier et crayon. Image générée par Bing.

C# : pourquoi éviter les tableaux multidimensionnels

Contrairement à de nombreux langages, C# (mais aussi VB.NET et F#) disposent d’un support pour les tableaux multidimensionnels. Ainsi, au lieur d’écrire :

double[][] a = new double[n][];
for (int i = 0; i<n; i++)
a[i] = new double[n];

on peut écrire :

double[,] a = new double[n, n];

ce qui simplifie un peu l’écriture et a l’avantage d’avoir un tableau parfaitement rectangulaire par opposition à un tableau irrégulier (jagged array en anglais).

On pourrait s’attendre à ce que ces tableaux multidimensionnels soient plus performants que des tableaux irréguliers, puisqu’il n’y a qu’un seul new à faire, et que l’accès aux valeurs résulte d’une simple opération de type a + b * c.

Hélas, ces tableaux multidimensionnels doivent être absolument évités (en attendant que l’équipe responsable des SDK .NET se penche sur ce sujet). En effet, quelques pages parlent de ce sujet :

En étudiant plb2 sur Github qui est un code destiné à étudier les performances de quelques algorithmes pour 25 langages, j’ai voulu étudier la variation de performance pour les différents types de tableaux, notamment, pour le cas de la multiplication de 2 matrices utilisant l’algorithme naïf.

Voici le code de base qui initialise 2 tableaux (de dimension 1000 par 1000) et effectue la multiplication matricielle le tout en utilisant des tableaux irréguliers :

Et le code équivalent avec des tableaux multidimensionnels :

Or, l’écart de performance est d’un facteur d’environ 3 (environ 1300 ms pour le premier cas et environ 4000 ms dans le second cas sur une machine de test en mode Release et .NET 8, sous Windows), ce qui est loin d’être négligeable.

Donc il est préférable se contenter de la syntaxe verbeuse des tableaux irréguliers.

La fin des Microsoft Surface ?

Les Microsoft Surface sont un ensemble de matériels allant de la mini tablette Android jusqu’aux ordinateurs portables et ordinateurs fixes dont le premier exemplaire est apparu il y a 10 ans, donc en 2013.

De nombreuses générations se sont succédées, de nouveaux matériels sont apparus, parfois dans un esprit inédit avec un marché plutôt peu inventif.

Néanmoins, plusieurs de ces nouveaux matériels ont été critiqués pour leur bogues multiples et leur manque de fiabilité.

On apprend ainsi que Microsoft vient de mettre fin à l’aventure des Surface Duo.

Il existe aussi un aperçu des appareils Surface apparus au fil des années.

On peut maintenant se demander quels seront les prochains appareils qui seront arrêtés. On peut imaginer que ce sera les Surface Book. En effet, ces ordinateurs portables étaient assez originaux à l’origine. Mais ils souffrent de graves défauts de fabrication. Par exemple, la recherche surface batterie gonflée (ou surface battery swollen en anglais) fournit beaucoup de résultats.

Exemple en photo d’une batterie Lithium-ion gonflée d’un Surface Book qui déforme littéralement le boîtier :

Boîtier de Microsoft Surface Book déformé par sa batterie qui a gonflé
Boîtier de Microsoft Surface Book déformé par sa batterie qui a gonflé

On pourrait aussi évoquer les plastiques de nombreux accessoires (clavier et souris) qui deviennent gluants et collants au bout de quelques années seulement.

Dès lors ont peut s’interroger sur l’avenir de cette ligne de produit de plus en plus décriée pour son manque de qualité et durabilité.

Le meilleur format graphique

Depuis environ une trentaine d’années, le format graphique JPEG règne en leader quasi incontesté. Notamment sur Internet, la majorité des images sont encodées en JPEG.

D’autres formats graphiques cohabitent pour quelques besoins particuliers : PNG (images simples ou besoin du canal alpha) et GIF (petites images animées) notamment. À noter aussi le format TIFF qui bien que très ancien et bien qu’il ne dispose pas de taux de compression intéressants, ni de canal alpha, ses dimensions maximales sont considérables : 2^32-1 x 2^32-1. Et il supporte une très importante profondeur de couleur : jusqu’à 16 bits par canal. Et du coup le format TIFF reste un format populaire pour numériser des documents ou des diapositives.

Si le JPEG était un choix pertinent à l’époque, on peut raisonnablement se demander pourquoi il est encore utilisé de nos jours. En effet, ce format graphique a dorénavant un faible taux de compression face à d’autres formats plus récents, et possède de nombreuses limitations, par exemple :

  • Taille maximale de 65535*65535
  • Pas de canal alpha
  • Profondeur de couleur limitée à 8 bits par canal
  • Taux de compression plutôt faible

Depuis sont apparus de nombreux prétendants au remplacement de ce format JPEG. Dont :

  • JPEG 2000. Ce format présente peu d’améliorations par rapport au JPEG d’origine, et n’a donc pas pu remplacer son prédécesseur.
  • WebP. Surprenamment, ce format est très limité : profondeur de couleur limitée à 8 bits par canal. Taille maximale des images limitée à 16383*16383 seulement. Néanmoins il accepte un canal alpha et a un taux de compression un peu meilleur que le JPEG.
    Une version 2 est en cours mais apporte peu d’évolution (profondeur de couleur légèrement améliorée à 10 bits par canal, taux de compression qui serait un peu amélioré)
  • HEIF/HEIC. Taille maximale de 16383*18383. Profondeur de couleur de 10 bits par canal.
  • AVIF. Taille maximale de 65535*65535 ou plutôt 8192 x 4352 avec des extensions possibles. Profondeur de couleur de 12 bits par canal.
  • JPEG XL. Un format récent mais taillé pour l’avenir tant il cumule les avantages. Dimensions maximales : 2^30-1 x 2^30-1. Profondeur de couleur par canal : 24 bits (entiers) ou 32 bits (flottants). Il supporte aussi pas moins de 4099 canaux (3 + 2^12), et donc le canal alpha est largement supporté. Et en plus il dispose d’un excellent taux de compression, etc.

Bien sûr il existe une multitude d’autres formats graphiques adaptés à des usages bien spécifiques (compression sans perte, support de très grandes dimensions, ou même formats simplement propriétaires).

À noter également que les dimensions maximales dans les 2 dimensions sont impossibles à obtenir en pratique pour de multiples raisons (notamment à cause des limitations d’offsets).

Logo JPEG XL

On comprend bien que le format JPEG XL est le format graphique du futur qui cumule quasiment tous les avantages. Ce devrait bien sûr être le format utilisé sur Internet pour réduire les données transmises et réduire la taille des supports mémoire, dans un réflexe de sobriété. Mais aussi le format de base pour les appareils photo, les appareils de numérisation, etc.

Hélas, tel n’est pas le cas. Google a décidé de mettre des bâtons dans les roues de ce format du futur. Sur fond de rivalité avec d’autres formats nettement moins bons (WebP et AVIF), et de sa situation largement dominante dans le domaine des navigateurs internet (Chromium / Chrome), le JPEG XL va avoir bien du mal à se faire la place qu’il mérite. Faudra-t-il que les autorités étatiques s’occupent de ce dossier ?

AVX et hyper-threading, nouveau chamboulement pour les processeurs

Intel a supprimé le support de l’AVX-512 à partir de sa 12e génération de processeurs (Alder Lake).

Les bouleversements ne vont pas s’arrêter là. Intel se prépare à faire évoluer les jeux d’instructions de ses processeurs, mentionnant l’APX (Advanced Performance Extensions) et l’AVX10 (Advanced Vector Extensions 10). Et en supprimant les instructions MPX (Memory Protection Extensions) qui étaient pourtant apparues récemment sur les processeurs Skylake (6e génération de processeurs). Sans compter que l’AVX10 va se décliner dans de multiples possibilités selon la catégorie de processeur (grand-public/entreprises) et les générations (AVX10.1 puis AVX10.2). Pour les développeurs pratiquant le langage assembleur ou les intrinsics functions accessibles depuis plusieurs langages (notamment le C++), la situation qui n’était déjà pas simple va nettement se complexifier.

L’utilisateur final devrait quand même voir un avantage au final. Le doublement du nombre de registres généraux (passant de 16 à 32) devrait largement aider à améliorer les performances des processeurs, conjointement aux compilateurs qui auront la lourde tâche de gérer cette évolution. Nouveau point positif, l’AVX10 sera possible sur tous les cœurs, qu’ils soient P-core ou E-core.

Autre changement significatif, mais pour le moment au stade de la rumeur : la fin de l’hyper-threading. De toute façon il n’était utilisé que sur les quelques cœurs de type P-core. La disparition de l’hyper-threading n’aurait donc pas un impact significatif. La simplification des cœurs de type P-core qui en résulterait pourrait permettre d’ajouter davantage de cœurs de type E-core. De nos jours, c’est bien ce que l’on attend, notamment de la part des développeurs : davantage de cœurs, davantage de vitesse et davantage de mémoire centrale.

Image d'un processeur fictif
Image d’un processeur fictif. Image générée par Bing.

L’étrange hors-série de Programmez.com dédié au langage python

Le hors-série N°11 de Programmez.com est consacré au langage python. Ce langage qui a connu une popularité croissante est en effet dorénavant utilisé dans de nombreux contextes pour de petits projets, ce qui peut justifier une série d’articles à son sujet.

Néanmoins, plusieurs articles sont rédigés d’une manière maladroite (en étant poli), notamment l’article qui compare la syntaxe de python avec celle de C# ou C++. Comme si on choisissait un langage de programmation en fonction de sa capacité à faire du code golf. Il est vrai que python obtient généralement de bons scores dans le domaine (j’apprécie python notamment pour ça). De mon côté, la capacité à écrire un Hello World de manière succincte n’est pas ma préoccupation première quand je dois résoudre un problème.

Par ailleurs, si un Hello World s’écrit effectivement brièvement en python :

print("Hello World")

Voici la version attribuée au langage C# :

using system;
namespace Hello
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }
}

Mais cette version ne représente pas la situation courante. En l’état actuel, un développeur C# écrirait plutôt simplement :

Console.Write("Hello World");

Le deuxième exemple choisi reprend la célèbre Conjecture de Collatz appliquée au nombre 299999. Et en comparant python avec C++ cette fois-ci.

Côté python, ça donne :

n=2999999
i=0
print(i,">",n)
while n!=1
    if n%2==0:
        n=n//2
    else:
        n=(3*n+1)//2
    i+=1
print(i,">",n)

Côté C++, voici le code verbeux attribué à C++ :

#include <iostream>
using namespace std;
int main()
{
    unsigned int n=2999999;
    unsigned int i=0;
    cout<<i<<">"<<n<<endl;
    while(n!=1)
    {
        if(n%2==0)
        {
            n=n/2;
        }
        else
        {
            n=(3*n+1)/2;
        }
        ++i;
    }
    cout<<i<<">"<<n<<endl;
    return 0;
}

Pourtant ce code peut être amélioré :

#include <iostream>
int main()
{
    int n=2999999, i=0;
    std::cout<<i<<">"<<n<<std::endl;
    while(n!=1)
    {
        n = n%2==0 ? n/2 : (3*n+1)/2;
        i++;
    }
    std::cout<<i<<">"<<n<<std::endl;
}

Et si le but est de faire un code court, alors allons-y en 7 lignes en C++ au lieu de 10 lignes en python :

#include<iostream>
int i,n=2999999;
main()
{
    for(printf("%d>%d\n",i,n);n>0;i++)n=n%2?(3*n+1)/2:n/2;
    printf("%d>%d\n",i,n);
}

Sachant que l’on peut encore faire mieux (ce qui veut dire pire en terme de lisibilité).

Ceci démontre que la longueur d’un programme n’est pas un argument en faveur d’un langage de programmation.

De toute façon, comparer les langages de programmation et arriver à la conclusion qu’un langage serait meilleur qu’un autre est une faute grave pour un développeur (c’est plutôt que le développeur devrait s’extérioriser). Tout ce qu l’on peut dire, c’est que certains langages sont plus adaptés que d’autres dans certains contextes. Par exemple, on évitera d’utiliser le langage interprété qu’est python pour de trop gros projets (ou simplement pour sauver la planète, cf. l’article Pourquoi l’utilisation du langage de programmation Python serait en train de « détruire la planète »). Par ailleurs, il ne faut pas oublier que la plupart des langages évoluent de nos jours rapidement (y compris python). Et du coup, les syntaxes attribuées a C++ pour les listes et les dictionnaires ont dorénavant des syntaxes améliorées ce qui annihile les critiques inutiles contre cet excellent langage. Sinon, pourquoi ne pas avoir utilisé la syntaxe de python par exemple version 2.7 ?

Enfin, concernant le supposé « coup de grâce » de python contre les autres langages au sujet de sa bibliothèque, il est difficile de faire ce genre de comparaison. D’autant plus que si C++ a a effectivement une bibliothèque standard incomplète, bien d’autres impressionnantes bibliothèques viennent en renfort (l’auteur semble ignorer boost).

En conclusion, un article, voire un hors-série, à ignorer.

La programmation informatique dans la série Citadel

La série Citadel en 6 épisodes est une série d’espionnage dotée d’un budget conséquent, mais souffre d’un scénario assez bancal. Toutefois le point qui nous intéresse ici, c’est la programmation informatique dans le troisième opus. D’une manière assez étrange, alors que l’héroïne consulte ses mails, en inversant l’écran horizontalement, on aperçoit un programme :

Citadel saison 1 épisode 3 : programmation informatique à la lecture de ses mails
Citadel saison 1 épisode 3 : programmation informatique à la lecture de ses mails

Il s’agit d’un simple programme en langage C, avec une simple fonction main et une fonction de création d’un nouveau fichier. À noter l’utilisation des arguments de la fonction main (program_name = argv[0]) ce qui est généralement à faire avec d’énormes précautions.

Cette partie programmation n’a bien sûr rien à faire à cet endroit. Manifestement il fallait en rajouter avec un peu de coloration syntaxique, et comme on voit l’écran à l’envers par transparence, ça passe inaperçu pour la plupart.

Justement, à quand les écrans transparents ?

La fausse prise en compte de l’inflation pour les impôts

La déclaration des revenus démarre. À cette occasion, les médias sont nombreux à diffuser un article sur ce sujet, et à mettre l’accent sur l’inflation. Notamment, le relèvement des tranches d’imposition de 5,4% ferait littéralement gagner de l’argent. Avec un exemple à l’appui : un contribuable touchant 2500 euros par mois, économiserait 328 euros d’impôt cette année.

Néanmoins, ces économies d’impôts ne serait valables que dans le cas défavorable d’une stagnation des revenus, ce qui en période d’inflation correspond à une vraie perte de pouvoir d’achat, d’autant plus que l’inflation demeure élevée.

Il serait donc intéressant de savoir ce qui arrive concernant les impôts au cas où les revenus suivraient l’inflation (disons 5,4%). Est-ce que les impôts restent stables grâce/malgré la hausse des tranches d’imposition à hauteur de l’inflation ?

Faisons un minuscule programme en C# pour étudier les impacts :

Ce programme très simple permet de calculer pour tous les revenus entre 15 000 et 100 000 euros par tranche de 1000 euros le montant des impôts avec les anciennes tranches d’imposition, puis le montant des impôts avec les nouvelles tranches d’imposition, et enfin la différence entre ces 2 valeurs. On ne prend en compte que le cas d’un célibataire (quotient familial=1), n’ayant aucun autre revenu, et en ne choisissant pas les frais réels (donc en optant pour la déduction forfaitaire de 10%). Enfin, on ne tient pas compte des décotes qui ne s’appliquent que dans un nombre limité de cas.

Le programme calcule effectivement que pour des revenus entre 31 000 euros et 82 000 euros, le montant de l’impôt diminue de 329 euros (61 euros en moins pour un revenu juste en-dessous de 30 000 euros et 771 euros en moins pour un revenu un peu au-dessus de 88 000 euros).

Mais tous ces chiffres ne sont valables qu’à revenu constant. Que se passe-t-il si les revenus augment de 5,4% ? Relançons le programme en modifiant la constante 1,000 par 1,054 :

Dans tous les cas, le montant à payer est supérieur.

Ainsi, la revalorisation des tranches d’imposition au niveau de l’inflation ne garantit en rien une stabilité de l’impôt pour des revenus progressant selon l’inflation. Les contribuables sont perdants. Et étonnamment, aucun journaliste n’a pensé à vérifier ce cas.

Image générée par Bing

AVX-512, la confusion

Le jeu d’instructions AVX-512 va fêter ses 10 ans cette année. Toutefois, il existe une immense fragmentation dans ce jeu d’instructions puisqu’il existe de nombreuses évolutions telles que F, CD, VL, DQ, BW, IFMA, VBMI, VBMI2, VPOPCNTDQ, BITALG, VNNI, VPCLMULQDQ, GFNI, qui sont supportées par un petit nombre de processeurs.

Ce jeu d’instructions AVX-512 succède au jeu d’instruction AVX2 déjà ardu à implémenter. Même les précédents jeux d’instructions SSE et AVX ne sont pas simples à appréhender comme on peut le voir sur ce tutoriel « SSE & AVX vectorization ».

De plus, ces jeux d’instructions occupent une place non négligeable dans les processeurs modernes, ainsi qu’une complexité là aussi importante. Avec tous ces inconvénients, les développeurs de logiciels peuvent être excédés et préfèreraient à la place davantage de cœurs pour distribuer la charge.

Alors que les processeurs grand public chez AMD et Intel commençaient à inclure tout ou partie des jeux d’instruction AVX-512, Intel a finalement fait machine arrière et supprime maintenant le support de l’AVX-512 dans ses derniers processeurs grand public, la déclinaison Alder Lake. Il faut dire que les processeurs Intel supportent maintenant 2 types de cœurs : les performants et par opposition les « non performants » qui excluaient de fait l’AVX-512. Quant-à AMD, la dernière génération Zen 4 continue d’avoir un support de l’AVX-512. Reste à voir si ce support se maintiendra avec les générations futures.

Coup de théâtre : Intel vient de publier en open source son code source permettant un tri rapide à l’aide du jeu d’instructions AVX-512, ce tri rapide étant basé sur l’algorithme de tri bitonic. Cet algorithme de tri n’est pas le plus efficace puisque qu’il est en O(n(log(n))²). Mais pour certains cas particuliers, grâce à l’AVX-512, il permet de paralléliser une partie de travail et au final peut être plus rapide que les meilleurs algorithmes de tri. L’abandon de l’AVX-512 est donc malvenu pour ce cas particulier.

Enfin, on peut se demander si l’AVX-1024 verra le jour dans ces conditions.

Page 1 of 3

Fièrement propulsé par WordPress & Thème par Anders Norén