Le problème de cohérence.
Un outil numérique peut sembler convaincant alors que deux implémentations divergent sur le nombre d’intervalles, l’aire signée ou les fonctions invalides. IntegraDraw avait un passé Java et devait gagner une édition web sans devenir deux calculatrices distinctes.
La refonte explicite le contrat : nombre exact d’intervalles demandé, résultats signés, erreur visible et rejet clair des entrées non finies.
Ce sur quoi les runtimes doivent s’accorder.
L’interface n’est utile que si les règles restent stables :
- Les méthodes du milieu et des trapèzes utilisent exactement le nombre de segments saisi.
- Une aire négative reste négative.
- La valeur de comparaison est une référence Simpson, jamais un résultat symbolique exact.
- Le parser web n’utilise ni eval ni Function.
Un contrat au-dessus des implémentations.
Partager le code Java et TypeScript créerait un pont maladroit sans prouver grand-chose. Partager le comportement attendu est plus utile.
J’ai introduit un corpus golden versionné consommé par JUnit et Vitest. Tolérances et limites propres aux runtimes restent visibles.
Deux interfaces, un même référentiel numérique.
Java distribue une interface Swing et le cœur numérique dans un JAR. Le web utilise un parser sans dépendance, des routines TypeScript et un tracé Canvas responsive. Les deux vérifient le corpus partagé.
Les choix qui clarifient les mathématiques.
L’atelier appelle une approximation une approximation.
Borner le langage d’expressions
Le navigateur accepte x, constantes, arithmétique, parenthèses et fonctions documentées via son propre parser.
C’est plus sûr que du JavaScript arbitraire, mais volontairement moins expressif.
Nommer correctement la référence
La comparaison utilise Simpson composite avec 8 192 sous-intervalles et parle de référence, pas de résultat exact.
Certaines fonctions sont refusées ; ce n’est pas un système de preuve symbolique.
Comparer le comportement observable
Les tests Java et TypeScript utilisent les mêmes cas en gardant leurs tolérances visibles.
Le corpus doit évoluer délibérément avec le contrat mathématique.
Distribuer les deux applications.
La CI compile Java 17, exécute JUnit, construit et teste le JAR, puis vérifie, teste et compile TypeScript. Les candidats incluent bundle web et SBOM des deux runtimes.
La publication compare des builds indépendants, valide les inventaires et contrôle manifestes SHA-256 et attestations GitHub.
Ce que l’atelier rend visible.
L’utilisateur modifie fonction, intervalle et segments puis compare estimations, courbe et référence Simpson.
Les applications restent autonomes ; le corpus offre aux mainteneurs un lieu unique pour contrôler la promesse numérique.
Registre des preuves.
Le contrat numérique est assez petit pour être énuméré :
- Corpus golden
- Six cas d’intégrales, trois expressions invalides et sept cas de validation sous le schéma version 1.
- Vérification
- 22 déclarations JUnit et 80 TypeScript dans la version auditée.
- Référence
- La comparaison Simpson composite du navigateur utilise 8 192 sous-intervalles.
- Limite
- La référence n’est pas exacte ; discontinuités et expressions non finies peuvent être rejetées et les limites des runtimes diffèrent volontairement.