[comment]: <> "LTeX: language=fr"
# Travail de Bachelor - PV Semaine 1

**Date** : 26/05/2025

**Lieu** : Salle D2021

**Heure** : 8:17-8:58


| Participants   | Présence | Rôle                                  |
| -------------- | :------: | ------------------------------------- |
| Bapst Frédéric | présent  | participant            |
| Michel Luca    | présent  | participant, organisateur, secrétaire               |

Agenda de séance :

- Retour sur le PV de la séance précédente
- Retour sur l'ébauche du cahier des charges
- Questions/Réponses

## 1. Points discutés

### Retour sur le PV de la séance précédente

Pas de remarques.

### Retour sur l'ébauche du cahier des charges  

Mettre en évidence le fait que COJAC ne fait pas que détecter des anomalies mais permet également de modifier le comportement des calculs :

- Ajout de perturbations pour tester la stabilité des opérations
- Wrappers numériques pour rendre les opérations plus robustes
- Repérer si certains calculs peuvent être faits plus efficacement
- Autodiff -> Calcul des dérivées

De manière plus générale, COJAC permet de redéfinir les opérations en substituant plus où moins ce que l'on veut à ces dernières. Ce comportement doit être répliqué pour COWAC. Les opérations instrumentées doivent être capables d'appeler les comportements suivants :

- Numerical sniffer
- Double-as-float
- Wrappers, si possible

Le mécanisme qui remplace les calculs par un callback ne varie pas, mais le comportement substitué oui.

Il faut définir l'architecture sur laquelle COWAC devra se baser pour être altéré. Le CDC laisse entendre que le fait de coder les callbacks en JS est obligatoire or ça n'est pas le cas. Il serait préférable de citer le fait que l'architecture doit être revue puis d'étudier cette dernière dans le rapport.

JS ne supporte à priori pas les floats et les entiers mais uniquement les doubles (numbers). Cette information doit être vérifiée dans le rapport et l'architecture devra être conçue en conséquence.

Concernant les objectifs du projet, la conception et la réalisation de l'architecture doivent être citées.

Ne pas citer toutes les anomalies qui seront supportées, cela donne plus de flexibilité pour la réalisation du projet.

Évoquer le fait que la signalisation des anomalies devra être plus succinte mais pas la manière de réimplémenter cette signalisation, encore une fois dans le but de rendre le projet un peu plus flexible.

Ajouter un objectif de validation du prototype (via une démonstration par exemple) et un objectif secondaire de mesure de l'impact de l'instrumentation sur les performances

Penser à spécifier que l'une des modalités d'instrumentation substituera les opérations par des fonctions "vides" qui ne font qu'exécuter les opérations en elles-mêmes.

### Questions/Réponses

Aucune.

## 3. Décisions

Aucune.

## 3. Prochaines étapes

| Tâche | Délai | Participants |
| ----- | ----- | ------------ |
| Révision du cahier des charges | 26/05/2025 - 16:00 |Luca Michel        |

> Prochain meeting: **02/06/2025, 8:15-9:00**