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é.
Pourquoi ces technologies.
Ces choix gardent les deux applications autonomes et ne partagent que ce qui doit réellement coïncider.
Des implémentations Java et TypeScript distinctes.
- Pourquoi
- Chaque interface utilise son runtime naturel, tandis qu’un contrat externe compare le même comportement numérique.
- Ce que j’ai écarté
- Un bridge entre langages ou un partage artificiel du code source ajouteraient du couplage sans démontrer la parité observable.
- Ce que cela a coûté
- Nous acceptons de maintenir deux implémentations des algorithmes.
Un parser mathématique borné.
- Pourquoi
- Il fournit les expressions nécessaires à l’atelier tout en gardant grammaire, fonctions et échecs contrôlables.
- Ce que j’ai écarté
- eval ou Function exécuteraient du JavaScript arbitraire et rendraient la frontière de sécurité invérifiable.
- Ce que cela a coûté
- Nous acceptons un langage plus réduit, des fonctions énumérées et des erreurs explicites pour les entrées non prises en charge.
Canvas pour le tracé web.
- Pourquoi
- Il permet un rendu responsive, léger et sans dépendance, avec un contrôle direct de l’échelle et des pixels.
- Ce que j’ai écarté
- Une bibliothèque de graphiques ou un grand arbre SVG ajouteraient dépendances et complexité DOM inutiles pour une seule courbe.
- Ce que cela a coûté
- Nous acceptons d’implémenter axes, mise à l’échelle, redessin et aides d’accessibilité autour du Canvas.
Un corpus golden partagé.
- Pourquoi
- Des cas et tolérances versionnés comparent les sorties réelles de deux runtimes indépendants.
- Ce que j’ai écarté
- Partager le code serait peu naturel entre Java et TypeScript et pourrait propager la même erreur aux deux interfaces.
- Ce que cela a coûté
- Nous acceptons de maintenir cas, tolérances et versions ; le corpus reste un test, pas une preuve formelle.
Les choix qui clarifient les mathématiques.
L’atelier appelle une approximation une approximation.
Préserver le signe de l’intégrale
Les méthodes du point milieu et des trapèzes renvoient une aire orientée : inverser les bornes ou intégrer une fonction négative conserve un résultat négatif au lieu de le convertir en aire géométrique.
Le compromisLa valeur peut surprendre les personnes qui s’attendent toujours à une aire positive, mais elle respecte le sens mathématique de l’intégrale définie.
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.
Le compromisCertaines fonctions sont refusées ; ce n’est pas un système de preuve symbolique.
Respecter exactement la partition demandée
Valeur numérique et graphique utilisent le nombre de segments saisi par l’utilisateur. Aucun runtime n’augmente, ne réduit ni n’adapte silencieusement la discrétisation.
Le compromisUn choix très grossier produit une approximation visiblement grossière ; le produit la montre au lieu de la corriger en secret.
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.
Version publiée vérifiée v1.1.2 Vérification du
IntegraDraw est un outil pédagogique exploratoire. Il ne fournit ni intégration symbolique, ni preuve, ni gestion garantie des discontinuités, ni résultat exact pour une fonction arbitraire.