vmagnin a écrit 424 commentaires

Oui, c'est valable pour tous les langages qui calculent avec des flottants.
La norme c'est IEEE 754
Il faut une norme pour qu'un même calcul donne le même résultat sur n'importe quel microprocesseur.

Le problème, c'est qu'en règle générale on sait que le résultat est arrondi, mais on ne sait pas combien de chiffres sont faux. Il y a des gens qui ont travaillé sur des librairies (et des processeurs ?) qui seraient capable de fournir non pas un résultat arrondi, mais un encadrement du résultat entre deux bornes.

Bien sûr, généralement ça se passe bien, seuls les derniers chiffres seront faux. Et par exemple, un ingénieur se contentera souvent d'un nombre de chiffres significatifs faible. Mais il y a des cas pathologiques.

Et même si ça se passe bien, plus les calculs s'enchaînent et plus on accumule les arrondis. Avec un processeur qui fait quelques milliards de calculs par seconde, il faut donc être conscient de la façon dont ça fonctionne.

Une petite citation à méditer :

« Les Shadoks avaient entendu dire que plus un ordinateur va vite, plus il donne de bons résultats. »
Les Shadoks et le Désordinateur, Jacques Rouxel, 2000.

J'ai essayé en fortran, pas l'habitude, désolé si la syntaxe est pas bonne. Je me suis "inspiré" (méchamment copié à ce stade) d'un stackoverflow sur la très célèbre question de la comparaison des flottants, version fortran.

L'effort est apprécié !

Juste pour information, je précise pour le lecteur intéressé par Fortran :
1. le séparateur est le passage à la ligne, donc pas de ; en fin de ligne en Fortran. Par contre, il peut éventuellement être utilisé pour séparer plusieurs instructions sur une même ligne.
2. L'opérateur += n'existe pas en Fortran.
3. Le séparateur pour les structures est le % : on écrirait aim%angle
4. Le test d'égalité est bien le ==. On peut aussi rencontrer l'ancienne syntaxe .eq.
5. Il est effectivement déconseillé, sauf exception, en calcul numérique d'utiliser ce test d'égalité avec des réels flottants, puisque les arrondis s'accumulant au fil des calculs, il y a généralement peu de chances qu'on tombe pile-poil sur la valeur prévue, c'est-à-dire avec environ 16 décimales exactes (ou 53 bits en binaire). Les compilateurs Fortran afficheront d'ailleurs en général un avertissement pour un tel test.

Dans un ton à peine provocateur, le calcul numérique c'est l'art d'obtenir un résultat valable en calculant faux. Car même en s'en tenant à des additions, avec les réels informatiques l'associativité de l'addition vole en éclat et en règle générale :

Par exemple, si on somme des nombres de grandeur variable, on aura alors intérêt à faire la somme du plus petit au plus grand, plutôt que l'inverse, pour limiter les erreurs d'arrondis. De quoi s'amuser…

Petite expérimentation :

$ gfortran pi_monte_carlo_serial.f90
$ ldd ./a.out
        linux-vdso.so.1 (0x00007fff4dde4000)
        libgfortran.so.5 => /usr/lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007fa0ce2c7000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa0ce0dd000)
        libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fa0ce093000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa0cdf44000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa0cdf29000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa0ce5d3000)
$ gfortran -static pi_monte_carlo_serial.f90
$ ldd ./a.out
        n'est pas un exécutable dynamique
$ gfortran -static-libgfortran pi_monte_carlo_serial.f90
$ ldd ./a.out
        linux-vdso.so.1 (0x00007ffc591d5000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f634bde0000)
        libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f634bd96000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f634bc47000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f634ba5d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f634be7b000)

On voit que -static-libgfortran a bien pour effet de ne lier en static que la libgfortran. Les autres le sont en shared.

On peut se faire une idée de ce qu'il y a dedans avec :

$ strings -n 7 /usr/lib/x86_64-linux-gnu/libgfortran.so.5 | more

Est-ce qu'il y a une commande plus élégante pour lister les fonctions contenues dans une librairie ?

La dernière newsletter mensuelle vient de paraître :
https://fortran-lang.org/newsletter/2021/05/01/Fortran-Newsletter-May-2021/

Vous y trouverez les dernières évolutions des projets de la communauté, des nouvelles du développement des compilateurs Flang et LFortran, et la vidéo du dernier Fortran Monthly Call.

de même, je pense que, dans « Intel a rendu disponible gratuitement pour tous ses oneAPI Toolkits », il manque un bout.

Je veux dire : Intel a rendu disponible pour tous, gratuitement, ses oneAPI Toolkits

Oui, et pour le Markdown on peut utiliser ghostwriter qui propose avec F11 une fenêtre en plein écran pour ne pas être distrait. Il affiche quand même l'heure dans sa barre d'état, ça peut servir…

Oui, -static-libgfortran fonctionne avec mon exemple OpenMP. En ce moment je commence à explorer les coarrays et autres routines collectives, et j'ai créé un dépôt pour faire des tests (mais je n'utilise pas -static-libgfortran dans mes comparatifs pour rester simple) :
https://github.com/vmagnin/exploring_coarrays

Sur Pi Monte Carlo, gfortran+OpenMP est gagnant. Mais on peut penser que les compilateurs Fortran vont continuer de s'améliorer avec les coarrays, les cosum, etc. La version avec co_sum n'est pas loin derrière OpenMP.

:-)

dans dix ans au plus les ordinateurs se programmeront eux-même.

Voilà un serpent de mer qui est plus vieux que je ne pensais !

Le -static-libgfortran m'a été susurré par un développeur de gfortran. Je l'ai testé sur un petit algorithme de calcul de Pi par Monte Carlo et voici ce que j'obtiens en temps de calcul et en taille d'exécutable en fonction des drapeaux :

normal : 20,1 s ; 17 ko
-static : 19,4 s ; 1,3 Mo
-static-libgfortran : 18,8 s ; 287 ko

Apparemment, ça embarque moins de choses dans l'exécutable, mais c'est un peu plus rapide (-3 %, c'est modeste mais c'est toujours ça de gagné quand c'est long). J'ai cru comprendre que le -static-libgfortran permettait d'embarquer les fonctions intrinsèques du langage situées dans libgfortran comme RANDOM_NUMBER() que j'utilise dans mon test. Donc pour cette librairie c'est en static et pour les autres en shared.

J'ai trouvé ça, mais c'est un peu court jeune homme :
https://gcc.gnu.org/onlinedocs/gfortran/Link-Options.html#Link-Options

Je vais demander à la personne de m'expliquer plus précisément les choses. Et je posterai si j'ai une réponse claire.

Après, bien sûr, ça améliore les choses sur ce programme-là, mais ça n'est pas forcément une loi générale. A tester pour chaque programme, comme c'est souvent le cas en optimisation.

Oui, personnellement, ça ne me manquait pas !

J'ai trouvé l'argumentaire de la décision (16-10-2018) :
https://j3-fortran.org/doc/year/18/18-272.txt

Many, if not most, Fortran implementations support these degree-argument
versions as extensions, and they are widely used. In the spirit of
standardizing existing practice, we should add the following generic
intrinsic functions to the standard: ACOSD, ASIND, ATAN2D…
[…]
This provides a portable mechanism for programs that have
mathematical formulas that need the actual degrees, and don't
want the overhead of converting to/from radians.

Plus étonnant, il y a même dans cette norme l'apparition de fonctions trigonométriques où les angles sont exprimés en multiples de : ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, TANPI. Le message correspondant est intitulé "IEEE Circular trigonometric functions":
https://j3-fortran.org/doc/year/19/19-204.txt

On les retrouve dans un certain nombre de librairies mathématiques, par exemple :
https://docs.oracle.com/cd/E19059-01/stud.10/819-0499/ncg_lib.html

Ça doit répondre à des disciplines où exprimer ainsi les angles est une pratique courante.

A noter que Lubuntu a automatiquement créé un fichier de swap de 512 Mo. Avec 2 Go de RAM, c'est indispensable pour éviter de figer le système en cas de saturation de la RAM. Ce qui peut arriver vite avec un navigateur (il faut bien sûr éviter d'ouvrir trop d'onglets…).

J'essaierais un Lubuntu et je remplacerais le disque dur par un petit SSD (s'il y a une connecteur SATA sur la carte mère). J'utilise toujours Lubuntu pour les vieux coucous, c'est la plus légère des Ubuntu.

J'ai installé un Lubuntu 21.04 Beta (https://lubuntu.fr/) hier sur un portable HP Compaq 6715b (BIOS datant de 2006) et ça marche très bien, malgré les 2 Go de RAM, y compris Firefox pour aller sur YouTube. Mais c'est vrai que le processeur a 2 coeurs : c'est un AMD Turion 64 X2. Et le passage à un SSD l'a rendu beaucoup plus agréable à utiliser…

Tu n'as qu'à essayer quelques une des distributions citées ici avec une clé Live-USB avant d'installer. Ca te permettra de voir si ça fonctionne d'une façon acceptable.

Oui, j'utilise ghostwriter, disponible dans les dépôts Ubuntu en version 1.8.1. L'écran est divisé en deux, l'éditeur Markdown à gauche et la visualisation à droite.

J'ai eu une expérience mitigée avec ifort 2015, qui marchait très bien avec certains codes, mais pas avec le projet gtk-fortran. Comme il était payant, je n'avais malheureusement pas pu avoir les versions ultérieures pour corriger le défaut.

Maintenant qu'il est gratuit, ça facilitera les choses.

Mais gfortran est clairement mon compilateur n°1. J'ai rarement eu des soucis avec. A part un bug qui a traîné pendant quelques années…

Ce qui m'intéresse dans ifort, c'est en fait d'avoir deux compilateurs. C'est toujours intéressant de compiler avec plusieurs compilateurs, ça permet d'obtenir un code plus solide car les messages peuvent être complémentaires.

Tu peux désinstaller les noyaux que tu n'utilises pas, ils peuvent s'accumuler au fil des mises à jour. Regarde dans muon ou synaptic.

Tu peux aussi installer le paquet bleachbit pour faire du ménage. En particulier lancer la version root pour nettoyer le système.

Attention, j'ai un PC avec une puce graphique Intel i915 : depuis que j'ai upgradé en Ubuntu 20.10 je suis confronté à un bug du Kernel 5.8. Impossible d'ouvrir une session Plasma/KDE.

En attendant la résolution du problème, j'ai désinstallé le Kernel 5.8 et j'utilise le 5.4.

https://askubuntu.com/questions/1288395/system-is-unusable-after-upgrade-to-20-10-i915-gpu-hang

https://gitlab.freedesktop.org/drm/intel/-/issues/2334

Oui, le copier/coller n'est apparu que vers la 2.2 :
https://blog.genma.fr/?Test-de-la-version-2-2-de-FirefoxOS

Douglas Engelbart l'avait pourtant montré en 1968 :
https://www.01net.com/actualites/quand-fut-invente-le-copier-coller-515762.html

Oui, ça peut être :
- la carte mère,
- le processeur,
- peut-être les barrettes, mais est-ce qu'on n'aurait pas quand même un affichage dans ce cas ?

Dans ce cas-là, le BIOS devrait quand même émettre des bip bip…

Exactement, j'avais un ZTE Open C avec un Firefox OS 2.1, que j'aimais bien mais qui était un peu limité, et au moment où avec la version 2.5 le système allait vraiment commencer à disposer de toutes les fonctionnalités qu'on pouvait en attendre, pouf… le projet est abandonné… C'était un peu bizarre…

Je ne me sers plus de mon ZTE (en tant que téléphone) mais je l'ai passé en LinageOS :
https://blog.mossroy.fr/2018/11/21/passer-un-zte-open-c-sous-lineage-os/

Sous Kubuntu, ça se fait normalement tout seul si la clef est connue du noyau. Dans l'applet réseau, il suffit de cliquer sur le bon réseau (les identifiants des cartes réseau apparaissent entre parenthèses derrière le nom du réseau).

Si c'est un problème matériel, tu peux toujours acheter une clef Wi-Fi, par exemple chez tp-link. Chez moi j'en utilise souvent une (TL-WN821N) car la carte Wi-Fi de mon portable et ma borne Wi-Fi ne s'entendent pas toujours bien… Alors qu'au bureau je n'ai pas de souci.

Les changements à apporter pour migrer de GTK 3 à 4 sont listés ici:
https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/NEWS

Mon expérience personnelle, dans le cadre de la migration de gtk-fortran de GTK 3 vers 4, est qu'il y a pas mal de changements à faire :
https://github.com/vmagnin/gtk-fortran/issues?page=2&q=label%3A%22GTK+4%22+is%3Aclosed

Dans ce projet, il s'agissait pourtant essentiellement de simples démos. Mais qui d'un autre point de vue étaient justement faites pour explorer de nombreux widgets. Donc c'est normal d'avoir été confronté à pas mal de petits ou gros changements (pour faire simplement tourner les applis comme avant, sans même utiliser les nouveautés de GTK 4).

Donc la migration vaut le coup si :
- on veut profiter des nouveautés de GTK 4,
- et/ou on vise une pérennité de l'application au-delà des 10 prochaines années.

Pour développer une nouvelle application, on choisira GTK 4 si on n'est pas ultra-pressé : pour l'instant GTK 4.0.0 est dans Fedora Rawhide et devrait arriver dans une semaine ou deux dans Fedora 33. Dans Debian, elle est encore dans la branche expérimentale. Donc je ne sais pas encore si elle apparaîtra dans Ubuntu 21.04.
Voir : https://pkgs.org/search/?q=gtk4

La 4.0.0 présente bien sûr encore des bugs :
https://gitlab.gnome.org/GNOME/gtk/-/issues
et une version mineure devrait sortir pour GNOME 40.

Enfin, il y a un Discourse très actif pour les développeurs GTK :
https://discourse.gnome.org/c/platform/5
Emmanuele Bassi, un des développeurs de GTK, y est très actif et vous apporte toujours des réponses nettes et claires.

https://gtk.developpez.com/actu/311313/GTK-4-0-est-disponible-La-boite-a-outils-pour-realiser-des-interfaces-graphiques-apporte-des-ameliorations-dans-le-transfert-des-donnees-et-d-une-prise-en-charge-integree-de-la-lecture-multimedia/

C'est sûr que ça fait à peu près un an que j'ai commencé la migration du projet gtk-fortran de GTK 3 vers GTK 4. Ca fait pas mal de casse dans les API. Migrer une grosse application, ça représentera un gros boulot. Surtout si finalement on se contente de faire marcher l'existant avec le nouveau GTK et qu'on ne tire pas profit des nouvelles API.

Probablement qu'en 2030, la libgtk-3.0 sera toujours présente dans nos distributions…