Détection des erreurs reproductibles et aléatoires lors de la fabrication d'un modèle #3

New Issue

Open

opened 2023-10-16 15:04:58 +02:00 by neox · 0 comments

neox commented

2023-10-16 15:04:58 +02:00

Owner

Ces deux types d'erreurs sont repérables par des techniques différentes faisant appel à des outils parfois communs, parfois différents.

Cette issue a pour but de lister ces outils afin de faciliter le design du client.

Il va probablement falloir un sous-groupe Gem-graph-lab spécialisé dans le dépistage des erreurs reproductibles et disposant d'un moteur monothread (lent mais indépendant) pour traiter des demandes incompatibles avec les performances demandées au serveur (voir les issues serveur #25, #26 et #27, trop contraignantes pour le serveur).

Le serveur devrait être dédié aux calculs haute performance nécessaires à la recherche d'erreurs aléatoires puis à l'étude des résultats des modèles (leur confrontation à la réalité).

Voir aussi liste des outils dans le cahier des charges : 38e5c855e9/Cahier%20des%20charges

Les erreurs reproductibles (systématiques) sont facilement repérables car elles bloquent rapidement l'exécution du modèle en générant un état cahotique ou, au minimum, non conforme à des critères facilement définissables. Ces critères peuvent porter sur la structure de l'état global (présence ou absence de tel type d'objet ou variation du nombre d'objets de tel type au dela d'un seuil, etc....) ou sur la fréquence d'exécution d'un règle ou d'un groupe de règles.

Ces erreurs peuvent (liste non limitative) :

bloquer complètement l'exécution d'une règle
survenir à chaque exécution d'une règle
survenir toujours dans la même situation ou en présence du même objet
effectuer une modification facilement identifiable
...

Elles surviennent fréquemment lors de la création des modèles.

Elles sont facilement identifiées et corrigées avec des outils simples :

do/undo/redo
slow down/speed up
pas à pas à une localisation aléatoire
pas à pas à une localisation choisie
retour à l'état du modèle précédant la dernière modification
tracage et/ou inhibition sélective de règles ou groupes de règles
édition de nouvelles règles à partir de copies d'états locaux non reconnus
...

A ce niveau de complexité, l'édition est maladroite. Il faut accepter de procéder par essais / erreurs, c'est-à-dire, en gros, de 'pousser à la rencontre les uns des autres' les objets et les règles nouvellement créés, d'observer en détail ce qui se passe et de rééditer jusqu'à obtenir ce que l'on veut.

Les erreurs aléatoires sont difficiles à repérer car :

elles ne bloquent pas l'exécution du modèle
elles provoquent un effet imprévu et qui survient rarement
elles peuvent être indirectes (l'effet imprévu est lui-même causé par un autre effet imprévu)

Garantir qu'aucune erreur aléatoire n'est présente au sein du modèle est impossible.

Les outils les plus utiles pour les repérer sont (liste non limitative) :

Les confrontations prédictions / bilans (nombre d'objets, de situations, de transitions) (resp. meta-x)
la surveillance de l'évolution
(vues 'histoire du modèle', histogrammes nombres d'objets, exécutions de règles)
les statistiques globales ou avec focus sur un object, une situation ou une règle
l'inhibition sélective de règles ou groupes de règles
la suppression transitoire d'objets ou de groupes d'objets
la soustraction d'une partie du modèle ou sa divison en branches si elle est possible
...

Ces deux types d'erreurs sont repérables par des techniques différentes faisant appel à des outils parfois communs, parfois différents. Cette issue a pour but de lister ces outils afin de faciliter le design du client. Il va probablement falloir un sous-groupe Gem-graph-lab spécialisé dans le dépistage des erreurs reproductibles et disposant d'un moteur monothread (lent mais indépendant) pour traiter des demandes incompatibles avec les performances demandées au serveur (voir les issues serveur #25, #26 et #27, trop contraignantes pour le serveur). Le serveur devrait être dédié aux calculs haute performance nécessaires à la recherche d'erreurs aléatoires puis à l'étude des résultats des modèles (leur confrontation à la réalité). Voir aussi liste des outils dans le cahier des charges : https://git.a-lec.org/gem-graph/gem-graph/-/blob/38e5c855e90d08fa5c6bddba7de5f7e4151b5149/Cahier%20des%20charges --- Les erreurs reproductibles (systématiques) sont facilement repérables car elles bloquent rapidement l'exécution du modèle en générant un état cahotique ou, au minimum, non conforme à des critères facilement définissables. Ces critères peuvent porter sur la structure de l'état global (présence ou absence de tel type d'objet ou variation du nombre d'objets de tel type au dela d'un seuil, etc....) ou sur la fréquence d'exécution d'un règle ou d'un groupe de règles. Ces erreurs peuvent (liste non limitative) : - bloquer complètement l'exécution d'une règle - survenir à chaque exécution d'une règle - survenir toujours dans la même situation ou en présence du même objet - effectuer une modification facilement identifiable - ... Elles surviennent fréquemment lors de la création des modèles. Elles sont facilement identifiées et corrigées avec des outils simples : - do/undo/redo - slow down/speed up - pas à pas à une localisation aléatoire - pas à pas à une localisation choisie - retour à l'état du modèle précédant la dernière modification - tracage et/ou inhibition sélective de règles ou groupes de règles - édition de nouvelles règles à partir de copies d'états locaux non reconnus - ... A ce niveau de complexité, l'édition est maladroite. Il faut accepter de procéder par essais / erreurs, c'est-à-dire, en gros, de 'pousser à la rencontre les uns des autres' les objets et les règles nouvellement créés, d'observer en détail ce qui se passe et de rééditer jusqu'à obtenir ce que l'on veut. --- Les erreurs aléatoires sont difficiles à repérer car : - elles ne bloquent pas l'exécution du modèle - elles provoquent un effet imprévu et qui survient rarement - elles peuvent être indirectes (l'effet imprévu est lui-même causé par un autre effet imprévu) Garantir qu'aucune erreur aléatoire n'est présente au sein du modèle est impossible. Les outils les plus utiles pour les repérer sont (liste non limitative) : - Les confrontations prédictions / bilans (nombre d'objets, de situations, de transitions) (resp. meta-x) - la surveillance de l'évolution (vues 'histoire du modèle', histogrammes nombres d'objets, exécutions de règles) - les statistiques globales ou avec focus sur un object, une situation ou une règle - l'inhibition sélective de règles ou groupes de règles - la suppression transitoire d'objets ou de groupes d'objets - la soustraction d'une partie du modèle ou sa divison en branches si elle est possible - ...

neox added a new dependency 2024-01-11 16:55:46 +01:00

#19 Création d'une GUI en GTK 4

neox changed title from ~~UI : détection des erreurs reproductibles et aléatoires lors de la fabrication d'un modèle.~~ to Détection des erreurs reproductibles et aléatoires lors de la fabrication d'un modèle.

2024-01-11 16:59:43 +01:00

neox removed a dependency 2024-01-11 16:59:51 +01:00

#19 Création d'une GUI en GTK 4

neox changed title from ~~Détection des erreurs reproductibles et aléatoires lors de la fabrication d'un modèle.~~ to Détection des erreurs reproductibles et aléatoires lors de la fabrication d'un modèle

2024-01-11 17:11:46 +01:00

neox added the