Voici la consigne de mon formateur :
"Ecrire un algorithme qui affiche la moyenne des nombres pairs et la moyenne des multiples de 3 d'un tableau d'entiers initialisés par des nombres entrés au clavier par l'utilisateur.
L'utilisateur entrera un maximum de 15 nombres et signifiera la fin de ses entrées en tapant -1 au clavier.
0 n'est pas considéré comme un nombre pair ou un multiple de 3."
 
Voici notre code

 
 
Avez-vous des avis sur la construction de cet algorithme svp ? J'ai effetué cet algo avec des collègues et nous nous demandons s'il y aurait moyen de l'améliorer... On débute en algo et nous ne devons pas encore programmer en C pour le moment.

tu dois aussi vérifier que tu as rentrer 15 nombres ou moins  

L14 : la variable j n'a pas été initialisée

Conceptuellement, le code mélange deux choses :
La récupération des données en entrée et le calcul des moyennes.
L'affichage des résultats est lui bien séparé, mais la aussi, tu mélange le calcul de la moyenne et l'affichage, autant séparer cela.
Je séparerais cela en trois parties :
- La récupération des données en entrée
- les calculs de moyennes
- L'affichage des résultats en sortie
C'est important de bien séparer ce qui doit l'être, ça te préparera aux architectures modernes, ou bien souvent ce qui affiche un résultat n'est pas le même programme que celui qui le calcule.
 
En reprenant le code, et l'améliorant, ça donnerait :

//déclaration des variables  
tableau datas[15] : entier 
var j, nb_datas, data, sum_multiple2, sum_multiple3, nb_multiple2, nb_multiple3 : entier 
var average2, average3 : flottant 
 
 
// Lire les données 
// initialisations 
nb_datas <- 0 
data <- 0 
 
lire data 
TANT QUE data <> -1 et nb_datas <> 15 FAIRE    // -1 signifiera la fin de ses entrées 
    datas[nb_datas] <- data 
    nb_datas <- nb_datas + 1 
    lire data 
FTANT 
 
// Calculer les valeurs moyennes  
// initialisations 
j <- 0 
sum_multiple2 <- 0 
sum_multiple3 <- 0 
nb_multiple2 <- 0  
nb_multiple3 <- 0 
average2 <- 0 
average3 <- 0 
 
TANT QUE j <> nb_datas FAIRE 
    data <- datas[j] 
    SI data <> 0 ALORS 
        SI data mod 2 = 0 ALORS   // si c'est un nb pair 
                nb_multiple2 <- nb_multiple2 + 1 
                sum_multiple2 <- sum_multiple2 + data 
        FSI 
        SI data mod 3 = 0 ALORS   // si c'est un nb impair 
                nb_multiple3 <- nb_multiple3 + 1 
                sum_multiple3 <- sum_multiple3 + data 
        FSI 
    FSI 
    j <- j + 1 
FTANT 
SI nb_multiple2 <> 0 ALORS 
    average2 <- sum_multiple2/nb_multiple2 
FSI 
SI nb_multiple3 <> 0 ALORS 
    average3 <- sum_multiple3/nb_multiple3 
FSI 
 
// Afficher les résultats  
SI nb_datas = 0 ALORS 
    ecrire 'pas de données' 
SINON     
    SI nb_multiple2 = 0 ALORS 
              ecrire 'pas de nombre pair' 
    SINON 
              ecrire average2  //affiche la moyenne des nombres pairs 
    FSI 
 
    SI nb_multiple3 = 0 ALORS 
              ecrire 'pas de nombre multiple de 3' 
    SINON 
              ecrire average3  //affiche la moyenne des multiples de 3 
    FSI 
FSI

 
Bon sinon, dans votre code original, les lignes 18 et 23 sont fausses.
pour la 18, ça devrait être
multiple2 <- multiple2 + tab[j]
et idem pour l'autre.
Avec votre code actuel, les moyennes doivent valoir toujours 1
 
Autre point important a prendre en compte : tenir compte des valeurs limites  
Est-ce que ça marche si il y a pas de données (l'utilisateur saisit -1 tout de suite) et est-ce que ça s’arrête si il y a 15 données.
On voit que votre code marche si il y a pas de données en entrée (quoique dire que la moyenne est 0 quand il y a aucune valeur, ça se discute...) par contre, on voit qu'il continue a fonctionner si l'utilisateur saisit une quinzième donnée.
(et dans la vraie vie, on tiendrait compte des autres conditions aux limites suivantes : l'utilisateur n'a pas saisi un nombre mais autre chose, ou un entier qui déborde de la valeur minimale/maximale permise pour un entier, ou une des sommes déborde de la valeur minimale/maximale permise pour un entier, mais je ne pense pas que ça entre en ligne de compte dans ce type d'exercice)
 
Dernier détail, écrire mod 2 et mod 3, et non mod2 et mod3, car mod est un opérateur.
 
A+,

Bonjour à tous,
Tout d'abord Merci beaucoup pour vos retours car cela me donne à réfléchir. Voici les modifications que j'ai apportées dans l'algorithme car il manquait certaines choses que j'ai mises en rouge pour mieux visualiser ici en bas, les choses telles que 1) l'importance de correctement nommer les variables, 2) relire un nouveau nombre avant de reboucler, 3) initialiser la variable j, 4) mettre un espace entre mod et 3 par exemple car mod est un opérateur
 
 
 

 
 
Je vous invite également à lire l'algorithme de Gilou qui est très bien structuré.

Bonjour Gilou,
 
Merci beaucoup pour ton aide précieuse. Puis-je te poser quelques questions concernant ta façon de réfléchir quant à la construction de ton algoortihme svp ?
 
1. Pourquoi avoir choisit un type flottant pour les variables average2 et average3 ?
2. Qu'entends-tu par architecture moderne svp ?

3.

Est-ce que tu peux regarder mon dernier code svp dans le dernier post ? je pense que le programme devrait fonctionner maintenant ...
 
4. Si j'ai bien compris, il est plus fcile de procéder de la manières suivante ? :
- Entrée des données : Dialogue avec l'utilisateur <=> c'est-à-dire ce qui suit // Lire les données dans ton code ?
- Traitement des données et calcul des résultats <=> c'est-à-dire ce qui suit // Calculer les valeurs moyennes dans ton code ?
- Affichage des résultats. Dialogue avec l'utilisateur. <=> c'est-à-dire ce qui suit // Afficher les résultats dans ton code ?
 
Très belle journée à toi

1) il faut un float et pas un entier pour stocker des moyennes qui n'ont aucune raison d'être des valeurs entières à partir du moment où tu fais une division. Avec des entiers, ça va tronquer.
 
2) Je pense qu'il fait référence au design pattern "MVC" (modèle vue contrôleur) : https://fr.wikipedia.org/wiki/Mod%C [...] %C3%B4leur
 
4) oui. L'idée du MVC est de rendre indépendant les 3 parties : récup des données (ça peut être une saisie clavier, via une API, via une BD, via un fichier...), leur traitement et leur "affichage" (dans une console, une IHM, stockage dans un fichier ou une BD, envoi de la réponse suite à une requête d'API...
 
Si tout est imbriqué, tu vas te retrouver à de voir recoder plusieurs fois certaines parties. Pas efficace
 
Gilou complètera

 
 
Puis-je également demander si il faudrait rajouter un       liredata        entre les lignes 40 et 41 dans la version que tu a proposée s'il te plaît ?

 
 
Un grand Merci pour ces précieuses informations.

Il faut! Bien vu.
Je vais de ce pas éditer mon post.
A+,

Parce qu'en général, le résultat d'une division entière est un nombre rationnel, et que la méthode la plus courante pour représenter un nombre rationnel (son approximation a un nombre de décimales près en fait), c'est d'utiliser un type flottant
 

Par exemple une architecture  back / middle / front. Ton back est une couche qui fait l'interface entre le stockage des données (le plus souvent une BDD) et sa représentation dans le middle. Un middle qui interprète tes données comme des structures complexes et les transforme. Un front qui présente le résultat de ces transformations à l'utilisateur.
Ton back, ça peut très bien être de la BDD hébergée chez AWS, sur "le cloud". Ton middle il peut être partiellement sur le cloud et partiellement chez toi (serveurs d'authentification, etc) un middle, c'est souvent plusieurs parties qui tournent ensemble sans se marcher sur les pieds. Et un front, qui va être par exemple sur le browser de l'utilisateur et communique via REST avec le middle.
Il faut bien séparer les responsabilités de chaque partie, sinon, la moindre évolution peut devenir problématique.
Et bien séparer les responsabilités, ça permet de savoir de manière précise quelle partie on teste quand on fait les tests de son code.
 

Oui, au détail qu'il n'y a pas de dialogue dans un affichage, c'est juste de la réponse automatique à un changement des paramètres d'affichage. Si ce n'est pas la cas, et que ça implique des re-calculs de ce que tu affiches (et pas juste la manière dont tu l'affiches) parce que ce n'est pas prédictible, alors tu es dans un cas ou tu as un état sauvegardé qui change, et donc un input qui va être sauvegardée dans le back.
 
A+,

Non, tu ne contrôles toujours pas que l'utilisateur ne rentre pas plus de 15 nombres.
Et dans ton premier tant que, tu utilises partout tab[j] au lieu de nbLu, alors que accéder à une valeur dans un tableau est plus couteux que accéder à une variable integer... Même si de nos jours, un compilateur devrait au final faire cette optimisation à ta place, autant prêter attention à cela.
A+,

Très cher Gilou,
 
Mille mercis pour toutes ces précieuses informations.
 
A+

Je viens de réaliser que le pseudo code pouvait s'écrire en français... Je l'ignorais. ça fait vraiment bizarre de lire des SI ---- FSI.

Bonjour,

Une remarque en passant.
Question optimisation, travailler avec la variable "nblu" plutôt que "tab[j]".
En effet lire nblu directement, c'est un accès direct à une zone mémoire voir même un registre CPU déjà alimenté.
En revanche, lire tab[j] ça demande à faire un accès pour lire j, un calcul pour déterminer l'emplacement de la ligne J dans le tableau tab, puis enfin un accès mémoire pour lire la-dite valeur.

Sans oublier tous les contrôles de haut niveau (j pas en dehors du tableau, etc.) et les accès supplémentaires si tab n'est ppas sur un segment contigü en mémoire.

Après, le compilateur sera probablement pas débile et comprendra de lui-même qu'il peut trouver la valeur dans "nblu", mais rien ne le garanti.

Par habitude, toujours privilégier le early optimizing plutôt que le late optimizing qui consomme énormément d'énergie pour souvent un piètre résultat : autant partir sur un algo optimisé dès le départ...

--- Edit : mince, j'avais pas vu que gilou avait déjà relevé ce problème