Arthur Accroc a écrit 2055 commentaires

En l’occurrence, le 1E-17 est plus petit de 7 ordres de grandeurs que 2E-10 (si on prend en compte les valeurs absolues des résultats).

En effet, mais on ne peut pas vraiment s’étonner qu’à l’époque des machines 8 bits, on utilisait des flottants plus petits (donc moins précis) qu’avec les machines 64 bits actuelles (je dis « on utilisait », parce qu’il n’y avait pas de FPU, les calculs en flottants devaient être codés avec des instructions sur les entiers).

Quoiqu’entre les deux, la FPU historique des processeurs Intel (x87) utilise des flottants plus gros (80 bits dont 64 de mantisse) donc plus précis que le moderne jeux d’instructions SSE2 (64 bits) !
De nos jours, c’est la vitesse qui compte, la précision passe au second plan…

gUI en tenant son rôle de borné qui fait semblant de ne rien comprendre a berné tout le monde. Ça devenait un peu gros à la fin mais sinon, je pense que beaucoup de monde s'est laissé avoir par le réalisme du troll.

Sauf que finalement, en installant le paquet mpdecimal (nom sous Arch), j’obtiens des temps d’exécution similaires à ceux de gUI, c’est-à-dire un temps d’exécution avec le type Decimal très proche de celui avec les float (si j’exécute plusieurs fois, les temps varient, entre 2 et 50 % de plus pour le code en Decimal — pour plus de précision, il faudrait modifier le code avec un nombre d’itérations plus gros et fixe pour ne pas être influencé par les imprécisions des flottants). Le facteur 50 ou 60 était manifestement dû à l’utilisation de fonctions de secours en code pur Python.

Et là, ça remet tout en cause…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

N’oublions pas non plus qu’il faut savoir s’arrêter, pour son propre bien :

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Malheureusement, je n’arrive pas à me rappeler quelle pouvait être la représentation des nombres utilisée par les BASIC de l’époque (et je n’ai pas d’ordinateur 8 bits sous la main pour tester). Je ne serais pas surpris qu’ils aient utilisé systématiquement des flottants en BCD (et pas d’entiers), mais je peux me tromper…

Un test avec des émulateurs plus loin (en espérant qu’on puisse leur faire confiance là-dessus), finalement non.

En tout cas les BASIC du Commodore 64 et de l’Amstrad CPC (difficile d’être complètement sûr pour les autres sans les essayer) utilisent tous deux des flottants :

Accessoirement, vous remarquerez au passage comme l’émulateur de C64 fait un effort pour rendre la euh… « netteté » des écrans de l’époque…

Sinon, vous remarquerez aussi que les erreurs sont du même ordre de grandeur… mais différentes. Signe d’une époque où tout n’était pas standardisé (processeurs, flottants…).

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Il doit y avoir une erreur dans ton installation de python. Là tu nous sors l'implémentation en pure python, là où normalement tu devrais avoir une implémentation en C du module. Que te réponds cette commande :

>>> decimal.__libmpdec_version__
'2.4.2'


Bien vu, j’ai regardé de mon côté : une erreur.

En fouillant plus, le paquet mpdecimal n’était pas installé.
Si je l’installe, j’obtiens cette fois des résultats proches de ceux de gUI :

$ time /tmp/bench_float.py 

real    0m0,083s
user    0m0,080s
sys     0m0,004s
$ time /tmp/bench_dec.py 

real    0m0,091s
user    0m0,087s
sys     0m0,004s

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Il y a quand même une conclusion incontestable qui se dégage de cette discussion : les maths, ça n’adoucit pas les mœurs (ou alors peut-être de ceux qui les maîtrisent, mais si c’est pour se faire lyncher par les autres…) ! ;-)

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Faut reconnaitre que sur un exemple comme ça, ça fait tout de même tâche.

Plutôt « tache », en tout cas.
Ce n’est pas le même mot, leur signification est différente et ils ne se prononcent pas pareil en français (en parisien, je ne sais pas — « côte » et « cote » ne se prononcent pas pareil non plus, en français).

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

J’obtiens des résultats similaires à ceux de snowball :

$ time /tmp/bench_float.py 

real    0m0,087s
user    0m0,080s
sys     0m0,007s
$ time /tmp/bench_dec.py 

real    0m4,767s
user    0m4,753s
sys     0m0,014s
$ /usr/bin/python3
Python 3.6.3 (default, Oct 24 2017, 14:48:20)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 4.742/0.087
54.50574712643679

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Encore une sujet où on n'a pas avancé d'un iota depuis les années 80… c'est dommage.

Je ne dirais pas ça. Au début des années 80, on utilisait couramment le format BCD, d’abord dans les calculatrices, beaucoup plus répandues que les ordinateurs, mais les processeurs d’ordinateurs avaient aussi des instructions natives pour les traiter (pas en virgule flottante, il n’y avait pas encore de FPU, mais même s’il faut décomposer une opération en virgule flottante en opérations sur des entiers, à un certain stade, il faut effectuer l’opération en entiers sur les mantisses et si elles sont codées en BCD, mieux vaut qu’il y ait des instructions qui traitent directement ce format !).

Avantage du BCD : l’absence de surprise. Si un nombre semble tomber juste en décimal pour les humains (comme 1.8), c’est aussi le cas pour la calculatrice ou l’ordinateur. Si on fait 1/3, on obtient 0.3333… et on est conscient qu’on a une imprécision.

Quand on allumait les ordinateurs grand public de l’époque (des ordinateurs 8 bits, pas des PC ; au début des années 1980, les premiers IBM PC coûtaient une fortune, ce qui les réservait aux professionnels), en une poignée de secondes, on se trouvait sous BASIC. Malheureusement, je n’arrive pas à me rappeler quelle pouvait être la représentation des nombres utilisée par les BASIC de l’époque (et je n’ai pas d’ordinateur 8 bits sous la main pour tester). Je ne serais pas surpris qu’ils aient utilisé systématiquement des flottants en BCD (et pas d’entiers), mais je peux me tromper…

Si jamais j’ai raison là-dessus, il est inexact de dire qu’on n’a pas avancé depuis les années 80 sur le sujet qui t’intéresse (à savoir ne pas avoir des résultats imprécis en faisant des opérations sur des nombres qui nous semblent précis) : on a avancé… dans le mauvais sens.

Enfin il y a des sujets ou c’est pire. Au début des années 80, tu allumais ton ordinateur de poche et quelques secondes plus tard, tu pouvais directement programmer (c’était bien sûr valable aussi pour les ordinateurs 8 bits pas de poche).

Maintenant, ton ordinateur de poche permet de téléphoner, mais pour ce qui est de pouvoir le programmer, c’est beaucoup moins immédiat !

Je ne dis pas qu’il n’y a pas un tas de trucs mieux que dans les années 80 (Internet…), mais même dans le domaine technologique, il y a quelques points sur lesquels on en a perdu.

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

r=0
while r != 1:
  r += 0.1
print ('fini !')

Une règle de base de mes lointains débuts en informatique : ne jamais utiliser d’égalité (ou juste de différence, qui revient au même) comme règle d’arrêt, toujours utiliser une infériorité ou une supériorité.

r=0
while r < 1:
  r += 0.1
print ('fini !')

Ça te garantit que ta boucle s’arrête.
Ça ne te garantit pas qu’elle s’arrête au tour attendu.

En l’occurrence :

print(r)
1.0999999999999999

Conclusion personnelle : un programme qui utilise des flottants dans sa logique de contrôle et pas uniquement pour représenter des données a de forts risques d’être bogué (je ne dis pas que c’est toujours le cas, mais il faut vraiment savoir ce qu’on fait).

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Oui, trop !

Un ami a acheté un iPhone il y a quelques mois. Il a enregistré son empreinte, testé que ça se déverrouillait bien avec et m’a demandé d’essayer pour voir si c’était sûr. Résultat… ça s’est déverrouillé ! Bon, ça ne fonctionne pas deux fois de suite, et peut-être seulement parce qu’il a les mains assez moites et pas moi (ou alors ce lecteur en particulier est juste bigleux). Maintenant, quelqu’un de malintentionné se donnera plus de moyens, par exemple utiliser une bombe réfrigérante pour faire apparaître l’empreinte et un gant pour ne pas perturber avec la sienne.

Bon, ça fait longtemps qu’on sait qu’il y a moyen de ruser les lecteurs d’empreinte par appui et je suis sûr d’avoir vu passer des articles comme quoi même ceux à défilement n’étaient pas 100 % fiables (surtout des problèmes de faux négatifs, mais pas que, si je me rappelle bien).

Le reproche que je ferais au constructeurs, c’est de vendre ces machins comme s’ils étaient sûrs. La meilleure façon de n’avoir aucun souci avec le lecteur d’empreintes, c’est de ne pas en avoir. En plus, si un vrai méchant veux usurper ton authentification par empreinte, il fait simple : il te tue et te coupe le doigt. Avec une authentification par mot de passe, il est obligé de te garder en vie au moins un peu plus longtemps…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Mon boulot viens de me fournir un Toshiba Tecra A50-C.

Et les touches ne laissent pas de marques sur l’écran ?

C’est le cas sur le Satellite Pro R50-C-15P, qui à voir le manuel semble une déclinaison (très) bas de gamme de la même base que le Tecra A50-C.

Certaines pièces doivent être communes avec le Tecra ou au moins avec le Satellite Pro A50-C, par exemple le clavier, pas trop désagréable pour un clavier chiclet et avec des leds dans les touches verrouillage majuscules et numérique (généralement la première chose économisée sur les bas de gamme).

Le pavé tactile, spécifique, est très mauvais :
– des fois il détecte deux doigts alors qu’on en utilise qu’un (et je n’ai pas de gros doigts), rendant le clic gauche par tapotement impossible (ça fait un clic droit) ;
– il y a des ratés dans la détection, causant des bonds dans un sens ou dans l’autre (on baisse tranquillement le volume sonore et il remonte à fond ou on le monte et il redescend à zéro) ;
– rien qu’au toucher, je peux dire que les boutons sont dotés d’un contacteur à membrane métallique (comme les manettes de jeu bas de gamme à l’époque de l’Amstrad ou de l’Amiga), à la fois désagréable et d’une fiabilité médiocre.

Globalement, ce portable semble un assemblage hétéroclite de pièces de qualité correcte et médiocre, voire très médiocre.

Il y a quatre prises USB dont deux USB 3, mais elles ne sont pas évasées (le métal autour) et les deux USB 2, situées à gauche, donnent l’impression de raboter la prise USB qu’on a l’optimisme d’y enfoncer (pourquoi ne pas en avoir mis moins, mais de meilleure qualité ?). Il y a un lecteur de cartes SD, mais si on l’utilise, on se retrouve avec des fichiers corrompus (à partir d’une carte SD de marque qui ne pose pas de problème sur d’autres lecteurs) ; peu, mais c’est toujours trop (à ce stade-là, pourquoi le mettre ?). Le ventilateur ventile tout le temps, même quand le processeur est à 25°C et il est plus bruyant que celui de mon ancien Compaq en ventilant moins (pourquoi ne pas avoir économisé le lecteur de carte pour mettre un ventilateur correct ou au moins une électronique de gestion correcte ?). Les plastiques, non peints, font cheap, mais ça, c’est une économie raisonnable.

Par contre, il est bien supporté sous Linux (composants tout Intel : processeur, puce graphique, Ethernet, Wi-Fi) : il fonctionne aussi mal sous Windows (pavé tactile, ventilateur…).

Ça paraît très difficile d’éviter Windows avec Toshiba, mais je ne l’ai pas sur mon PC fixe et j’en ai malheureusement besoin pour un truc (mise à jour d’un GPS — si seulement Microsoft proposait une version allégée pour ce genre d’utilisation).

L’écran ne fait qu’une résolution de 1366×768, mais ma vue n’étant plus ce qu’elle a été, je ne veux pas de Full HD pour un écran de portable (je vais encore attendre quelques années pour être sûr que tous les logiciels s’adaptent à la résolution). Il a le gros avantage d’être mat, c’est ce qui m’a décidé à acheter ce Toshiba quand mon vieux Compaq m’a finalement lâché (ça, et la promo à 379 €).

Est-ce que je rachèterai un Toshiba ? A priori, non (même si pour le prix, je ne peux pas trop me plaindre — heureusement que je ne l’ai pas payé le prix hors promo).
Je comprends bien que sur du matériel pas cher, on ait des pièces de qualité médiocre (après d’autres constructeurs font plus cohérent et évitent de monter des périphériques défectueux), mais le clavier qui laisse des marques sur l’écran, c’est un défaut de conception évitable (on est pas à 0,5 ou 1 mm d’épaisseur près pour un portable qui ne prétend pas être un haut de gamme ultrafin) et impardonnable (un peu plus de plastique, ça n’aurait pas fait exploser le coût), et rien ne garantit qu’ils n’en fassent pas d’autres de cet acabit, y compris sur des portables plus haut de gamme. Je serais justement curieux de savoir s’ils ont évité ce défaut sur le Tecra.

Bon, je voulais un portable que je n’hésite pas à emporter et de ce côté-là, c’est réussi : je me dis que s’il est cassé ou volé, j’achèterai un autre portable bas de gamme, mais fanless (même si ça implique moins de puissance et un écran brillant).

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Lors du test, j'avais sur ma machine que libreoffice, un fichier excel créé par mon application, qui est une extraction de base de donnée.
Fichier des 125 lignes avec une 15 de colonnes, aucun calcul dessus, mais des colonnes avec des cases contenant pas mal de texte.

Si tu enregistres le fichier au format .ods et que tu le rouvres, est-ce que ça met autant de temps ?

Par définition, le format Excel est le format natif d’Excel. Les autres logiciels doivent en plus convertir. Ça peut être intéressant de vérifier déjà que le problème ne vient pas du convertisseur.

Pour voir, j’ai généré un fichier TSV avec 125 lignes de 15 colonnes de chaînes aléatoires d’une longueur comprise entre 1000 et 10000 caractères (quand même long, quoi). L’ouverture prend trois secondes.

Je l’ai sauvegardé en .xlsx et rouvert. L’ouverture prend trois secondes aussi. Je ne sais pas pourquoi c’est lent dans ton cas.

Pour référence ma version de LibreOffice est la 5.3.7.2.0+ (d’après la fenêtre À propos) sous GNU/Linux, et voici le code que j’ai utilisé pour générer le fichier TSV :

#!/usr/bin/perl -w
use strict;

my @_car_possible = ((' ') x 10, '0' .. '9', 'a' .. 'z', 'A' .. 'Z');

sub car_hasard {
    return $_car_possible[int rand @_car_possible];
}

sub chaine_hasard {
    my ($lg_min, $lg_max) = @_;

    my $lg = 8;
    if (defined $lg_min) {
        if (defined $lg_max) {
            $lg = $lg_min + int rand($lg_max - $lg_min + 1);
        } else {
            $lg = $lg_min;
        }
    }

    my $res = '';
    for (1 .. $lg) {
        $res .= car_hasard();
    }
    return $res;
}

for (1 .. 125) {
    print join("\t", map { '"' . chaine_hasard(1000, 10000) . '"'; } 1 .. 15), "\n";
}

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Je me fais des films je sais mais gestion native des emails dans le navigateur ( Un gros merge avec thunderbird ..)

Et on l’appellerait SeaMonkey (ou juste Mozilla) ?

Cela dit, je ne sais pas comment SeaMonkey se sort de toutes les évolutions récentes de Firefox (il n’y avait déjà qu’une partie des extensions pour Firefox qui étaient compatibles avec lui avant le changement du système d’extensions)…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Ça m’a bien fait rire (euh… c’était bien une blague, hein ?).

Mais il y a intérêt à bien calculer son coup : la terre tourne, si tu rates ton timing, ton morceau d’astéroïde tombera carrément ailleurs !

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

C’est peut-être une tentative pour que le site reste tout public : si tu n’as compris qu’un seul mot (à ce niveau-là, l’objectif n’est pas atteint), les enfants n’en comprendront peut-être aucun…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

J'ai pas eu l'impression que Jancovici soit spécialement pro-nucléaire. C'est surtout qu'il ne vois pas trop comment on va s'en sortir sans, a moyen terme. Sachant qu'en plus, il y a moyen de faire du nucléaire beaucoup plus propre moins sale…

Normalement, le nucléaire pourrait être une solution énergétique sur un terme assez court. Même sans considérer le problème des déchets, qui n’a jamais été résolu, l’uranium n’est pas renouvelable ; et si tous les pays se mettaient à avoir la même proportion de nucléaire que la France, il ne durerait pas longtemps. Concernant le plutonium, on a abandonné, faute de réussir à sécuriser le refroidissement, mais on espère développer la fusion… alors qu’elle dégage encore plus d’énergie que la fission du plutonium.

Mais dans la réalité, le parc de centrales du pays le plus nucléarisé du monde est vétuste et on n’est plus capable que de construire une centrale défectueuse en explosant les délais et les budgets.

Pour que le nucléaire puisse être une solution plutôt que de nous péter à la gueule, il faudrait remplacer tous les jean-foutres qui sont actuellement aux postes de décision de la filière par des gens responsables et capables de la remettre à flot. Pour ça, il faudrait commencer par arrêter de mettre des jean-foutres à la tête de l’État : si nous avions des dirigeants un tant soit peu responsables, ils imposeraient déjà que l’EPR soit conforme à l’état de l’art avant qu’il soit mis en service ; ça donnerait un premier signe fort à la filière qu’il est temps d’arrêter les conneries.

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Mauvaise foi ? De la part de qui ?

J’attends toujours un exemple d’application réelle utilisant un arbre dont la représentation en JSON ne passe pas avec les analyseurs actuels.

J’aurais pensé que quelqu’un en trouverait peut-être un au moins pour la limite la plus basse par défaut de 100 (un petit effort !), mais j’attends toujours…

Sinon, que les analyseurs JSON ne puissent pas lire un fichier produit dans une démarche malveillante, de test ou artistique, mais sans utilité réelle, ça ne m’empêchera pas de dormir (surtout si ça ne concerne pas ceux de mes langages de prédilection). Il y a des trucs qui m’ennuient plus en informatique (l’abandon du système de fichiers Intermezzo, par exemple, ou Berkeley DB*).

Note : si on a un arbre de plus de 100 niveaux qui tient en mémoire, il est fortement déséquilibré (c’est vrai que j’ai oublié ce cas dans mes commentaires précédents) ou beaucoup de nœuds sont le seul nœud fils de leur nœud parent. Un arbre correspondant au second cas peut être compacté en regroupant ces nœuds avec leur nœud parent.

Un petit schéma (ASCII parce que c’est plus simple — je sais que c’est moche), pour éclairer le principe :

        e
       /
      d                     e
     / \                   /
    c   f               bcd
   /                   /   \
  b         devient   a     f
 /                     \
a                       g
 \
  g

Donc, il reste à trouver l’exemple d’une application ayant l’utilité d’un arbre d’une profondeur de plus de 100 (par rapport à la limite par défaut la plus basse) voire 900 (par rapport à la limite de récursion sur Python si elle n’est pas facilement relevable, sinon encore plus) fortement déséquilibré et dont un rééquilibrage fausse le sens.

Cela dit, je n’exclus pas complètement qu’un développeur se retrouve un jour dans ce cas. La page de lovasoa pourrait alors lui être utile… si elle distinguait pour tous les langages ou bibliothèques la limite par défaut et la limite maximale.

* Si je voulais râler contre une brique logicielle, ce serait la base Berkeley DB.
Ton serveur OpenLDAP est arrêté brusquement (coupure électrique…) alors qu’il était bien pépère à ne faire que des opérations de lecture sur son backend bdb et c’est hyper grave, il faut reconstruire la base en suivant une doc imbitable. Merde !
Il y a aussi le cas où un fichier Berkeley DB perdu au fin fond du profil Firefox est corrompu et où Firefox ne démarre plus, sans explication pertinente (heureusement, c’est rare ; Firefox ne doit pas les garder ouverts en lecture…).
Berkeley DB n’est à la fois pas adaptée pour une grosse charge et pénible à gérer pour une faible charge. Malheureusement des logiciels l’utilisent…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Le boulot d'un parseur json c'est de prendre une chaîne au format json et d'en faire une structure qui permet de se balader dans l'arbre que cette chaîne représentait. Et c'est tout. Et oui, cet arbre devra probablement être entre encodé autrement pour des temps d'accès efficace. Mais c'est pas le problème du parseur.

À mon sens, c’est exactement l’inverse : un format JSON sert à l’encodage d’une structure existante (et qui tient en mémoire) pour pouvoir la recharger lors d’une autre exécution ou la transmettre.
L’utilité du parser est de permettre de restaurer cette structure.

Du coup, à moins que le programmeur (du premier programme si celui qui produit du JSON n’est pas le même que celui qui le lit) soit idiot, il a choisi une structure un minimum exploitable et pas complètement inefficace pour son application. Si on prend l’exemple utilisé pour le test, la seule information encodée par n tableaux imbriqués sans éléments, c’est… n.

J’attends toujours que quelqu’un trouve un exemple d’application ayant l’utilité d’un arbre très profond qui tient en mémoire (c’est une vraie question, je n’affirme pas que ça n’existe pas)…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Non, c'est pas du tout ok de s'arrêter pour quelque raison que ce soit.

Nous vivons dans un monde fini (je ne sais pas si les chantres de la croissance infinie s’en apercevront avant d’avoir ravagé la planète au point que ce soit la famine globale, mais c’est une autre histoire), ton ordinateur l’est encore plus. Donc il y a forcément des limites.

Si il y a ce genre de limite, a minima elle doivent être clairement écrite dans la doc.

C’est le cas pour Perl. Si ça ne l’est pas pour ton langage, mauvais langage ⇒ changer de langage.

Ce qui me choquerait c’est que ça segfaulte salement.

Là dessus on est d'accord, c'est encore pire.

C’est pour ça que les auteurs de la plupart des bibliothèques ont fixé des limites.

D’une manière générale, c’est pas une mauvaise pratique de fixer des limites.

Si… Et c'est particulièrement vrai dans le cas d'une bibliothèque où celui qui l'écrit n'a absolument aucune idée de la manière dont elle va être utilisée.

Oui, enfin considérons que tu aies un ordinateur avec pas mal de mémoire, 32 Go. Ça fait 2³⁵.
Considérons un arbre binaire complet de 100 niveaux (la limite la plus basse pour un analyseur JSON selon les test de lovasoa). Il comprend 2¹⁰⁰ - 1 nœuds. Ça n’est pas prêt de rentrer dans ton ordinateur, même si par miracle chaque nœud ne prenait qu’un octet.

Peut-être vas-tu me dire que l’ordinateur de la météo est plus gros. Cela dit, le nombre d’atomes de notre planète est estimé à environ 10⁵⁰, soit environ 2¹⁶⁶. Tu montes un peu la limite par défaut ou tu prends un langage dont l’analyseur JSON a une limite à 512 et ton arbre n’est pas représentable sur Terre, même avec un atome par nœud…

Bon, considérons que l’intérêt est de représenter des arbres incomplets.
On trouve des analyseurs JSON qui tiennent jusqu’à plus de 50 000 niveaux (éventuellement en changeant la limite par défaut). Ça veut dire que pour accéder à une des feuilles les plus profondes, il faut quand même 50 000 itérations. Ça paraît compromettre l’efficacité.

Alors après, on ne peut pas complètement écarter à priori qu’il existe des cas pour lesquels malgré tout une telle représentation serait adaptée. Mais je serais très curieux d’en avoir un exemple. Et là, on pourra dire « quels idiots les programmeurs de telle bibliothèque JSON, elle ne couvre pas tous les usages », mais pas avant.

En attendant, est-ce que le vendeur de ta voiture t’a prévenu que son moteur ne peut pas fonctionner sans oxygène ? C’est quand même une limite très importante !

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Oui, en ruby ou en PHP aussi, la limite est fixée dans le code.

Vu les valeurs que tu as trouvées (101 et 512), ça ne m’étonne pas.
Je soupçonnerais la même chose pour Rust (128), C/jansson (2049 — note que ton programme indique la valeur pour laquelle ça ne fonctionne plus, 513 par exemple en Perl en laissant la limite par défaut à 512)…

Cela empêche d'utiliser JSON, pour, par exemple représenter un arbre, alors que sans cette limite fixée par les implémentations, le format s'y prêterait très bien.

La remarque de Thomas ramène à la réflexion : est-ce qu’un arbre très profond a un sens dans une application réelle ?

S’il est très profond, mais pas très large, l’accès aux données ne semble pas optimal ; mieux vaudrait peut-être utiliser une autre structure (table de hachage ?). S’il est très profond et très large, donc très volumineux, est-ce que les capacités mémoires actuelles permettent de l’avoir entièrement en mémoire (la taille augmente exponentiellement avec la profondeur quand même), ou faut-il le manipuler directement sur disque/SSD ? Dans le deuxième cas, la question n’est pas de le sérialiser, mais d’avoir un format permettant un accès efficace sur disque/SSD.

Vois-tu un exemple d’application pour laquelle un arbre très profond (disons avec une profondeur supérieure à 5000) soit une structure adaptée ?

Si oui, la question de pouvoir le représenter pour le stocker, idéalement sous une forme moins sensible à la plateforme qu’une forme binaire, est effectivement intéressante.

Est-ce que les bibliothèques de sérialisation disponibles pour les divers langages gèrent ça mieux que les bibliothèques JSON ? Y a-t-il une représentation (ou à peu près) standard dont les bibliothèques tiennent mieux la route à ce niveau (XML ?) ?

La seule fois où j’ai eu à stocker un arbre (il y a 25 ans ; on trouvait moins de bibliothèques, à l’époque…), j’avais fait un parcours en profondeur et je stockais un nœud par ligne de fichier avec comme indications sa profondeur et sa valeur. Quand on reconstruisait l’arbre, la profondeur indiquait où greffer le nouveau nœud sur la branche courante. D’un point de vue analyse syntaxique, c’est très simple (en tout cas avec les valeurs de mes nœuds, qui l’étaient). Maintenant, cet arbre passerait en JSON, même avec la limite à 100 du parser Ruby…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Et combien de tableaux imbriqués faut-il pour faire planter un parser JSON ?

L’intérêt est-il de pouvoir manipuler des données légitimes qui utiliseraient disons 10000 niveaux (ça existe ?) ou de se protéger contre des fichiers JSON volontairement malformés ?

Le module JSON de Perl fixe la limite arbitrairement à 512. Extrait de son manuel :

max_depth
$json = $json->max_depth([$maximum_nesting_depth])

Sets the maximum nesting level (default 512) accepted while encoding or decoding. If a higher nesting level is detected in JSON text or a Perl data structure, then the encoder and decoder will stop and croak at that point.

À l’essai, si on remonte la limite beaucoup plus haut, le parser en pur Perl s’arrête à 100000, alors que le parser de JSON::XS (écrit en C pour une plus grande rapidité) plante un peu après 74800 sur mon système (JSON utilise un parser ou l’autre suivant si JSON::XS est installé ou non).

ET bien dans certains langages, très peu.

Peut-être devrais-tu regarder si les limites que tu atteins avec d’autre langages ne sont pas aussi fixées arbitrairement pour éviter des problèmes…

Pour référence, le code Perl que j’ai utilisé :

#!/usr/bin/perl -w
use strict;

use JSON;

my $json = JSON->new;
$json->max_depth(5000000);
my $decoded = $json->decode(<STDIN>);

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

« Brève », je verrais plutôt ça pour les articles (officiels) courts, à la place de « dépêche » (dans le sens où je l’ai utilisé), pour éviter la confusion avec la terminologie actuelle.

C’est vrai que « billet » évoque plutôt une forme courte. Ça laisse donc plusieurs possibilités pour un contenu personnel court : « note » (que j’ai proposé), « billet » ou « brève » (je fais une proposition, je ne prétends pas imposer ma vision des choses ; peut-être la majorité ou les éditeurs du site préféreront-ils un autre choix).

Il reste à trouver un mot pour les contenus personnels longs. Faute de mieux, il m’avait semblé que « billet » faisait moins court que « note » (ou « brève » en l’occurrence), tout en restant relativement adapté à un contenu personnel. Mais si quelqu’un a une meilleure idée…

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

Pour « note », qui est connoté àmha,

Connoté en quoi ?

je préférerais « bloc-note » (post-it étant une marque déposée iirc) qui fait métonymie avec le support et ce qui est écrit dessus brièvement.

Un bloc-note, c’est un bloc… dans lequel on écrit des notes. Chaque écrit individuel est une note.

Par rapport à tes différences entre bref / long : ce serait une différence d'affichage (soit avec le mot dépêche / article, soit via la css) ? À partir de combien de caractères ? (2000 ou 4000 a priori).

J’aurais tendance à laisser le choix à l’utilisateur de la rubrique dans laquelle il publie, mais en présélectionnant suivant la longueur (quand on clique sur Prévisualiser).

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

J’en profite pour proposer une terminologie plus proche du français courant, où « journal », c’est un ensemble de feuilles de papier avec des articles dessus.

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

C’est fait.

« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone