Fréquence (Nombre d'occurences)

Version imprimable

2 pièce(s) jointe(s)

Bonsoir,
voici mon énoncé :
Pièce jointe 163811

Voici mon programme:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#include <stdio.h>
#define MAX 10
 
int main()
{
int i;
float reel[MAX];
float compteur[MAX]={0};
 
 
for(i=0; i<MAX; i++) {
  printf("entrer un reel:");
  scanf("%f", &reel[i]); 
                           }
 
for(i=0; i<MAX; i++)
{ 
  if(reel[0]==reel[i])
  compteur[0]++;
  else if(reel[1]==reel[i])
  compteur[1]++;
  else if(reel[2]==reel[i])
  compteur[2]++; 
  else if(reel[3]==reel[i])
  compteur[3]++;
  else if(reel[4]==reel[i])
  compteur[4]++;
  else if(reel[5]==reel[i])
  compteur[5]++;   
  else if(reel[6]==reel[i])
  compteur[6]++; 
  else if(reel[7]==reel[i])
  compteur[7]++; 
  else if(reel[8]==reel[i])
  compteur[8]++; 
  else if(reel[9]==reel[i])
  compteur[9]++; 
}
 for(i=0;i<MAX;i++) 
printf("Le nombre %.0f apparait %.0f fois \n",reel[i],compteur[i]);
 
}

Et voici ce qu'il affiche :
Pièce jointe 163812

Comment faire pour que le programme n'affiche pas 2fois le même réel ?

Merci

14/12/2014, 09h45
gerald3d

Bonjour.

Tu peux déjà interdire lors, de la saisie, la redondance des nombres saisies.
14/12/2014, 13h09
Makunuchi

Je ne comprends pas
14/12/2014, 14h41
gerald3d

Au temps pour moi. Tu as raison de ne pas comprendre ma réponse. Elle est totalement à côté de la plaque :oops:.

Un autre idée alors : mémoriser les nombres que tu testes. À chaque test d'un nouveau, tu vérifies si tu ne l'as pas déjà évalué.
14/12/2014, 16h39
Makunuchi

Comment dois-je les mémoriser ? avec des variables tampon ?

On peut suivre, par exemple, l'algo suivant :

Soit nElem le nombre d'éléments placés dans le tableau reel.
- Initialiser nElem à 0
- Initialiser le tableau compteur[] à 0
- Faire MAX fois :
   - Lire une valeur val
   - Regarder si val a déjà été entré :
     Si val est égal à reel[i] pour  0 <=  i <= nElem-1 :
           - incrémenter compteur[i]
     Sinon :
           - placer val dans reel[nElem],
           - incrémenter compteur[nElem], 
           - incrémenter nElem
- Afficher pour i = 0..nElem-1 reel[i] et compteur[i]

15/12/2014, 09h44
Sve@r
Citation:

Envoyé par Makunuchi

Comment dois-je les mémoriser ? avec des variables tampon ?

Bonjour

C'est un petit peu le but des variables que de servir à mémoriser ce dont on a besoin. Et puis ton truc avec ton compteur[0], compteur[1], compteur[2] etc c'est un peu à la ramasse. Tu ne sais donc pas utiliser les boucles ???

Ceci dit c'est un petit peu complexe parce que l'on parle de "réels" (j'avais au départ rapidement lu et compris "entier"). Donc les réels c'est galère car "0.1" et "0.01" ce sont deux réels différents

Si moi je devrais écrire ce code, je déclarerais une structure contenant
- le réel
- son nombre d'occurences
Puis je définirais un tableau de 10 "structures de ce type". Ensuite pour chaque réel saisi, suffirait de regarder s'il est dans le tableau et si c'est le cas, incrémenter son nombre d'occurences sinon l'y rajouter. C'est un peu ce que diogene a fait sauf que lui il gère deux tableaux parallèles alors que moi je gère un tableau dont chaque élément contient deux items...

Bonjour,

Si je peux me permettre,si demain ton programme évolue et passe à mille saisie,vas tu faire mille clause if/else:
Code:

1 2 3 4 5 6 7 8 9 10 11 for(i=0; i<MAX; i++) { if(reel[0]==reel[i]) compteur[0]++; else if(reel[1]==reel[i]) compteur[1]++; else if(reel[2]==reel[i]) compteur[2]++; else if(reel[3]==reel[i]) compteur[3]++; .......
Chose a éviter en programmation et à ne jamais oublier!
Je pense que la pré- programmation(au sens restreint du terme :se limitant à l'aspect technique et algorithmique) est plus importante que la programmation.
En effet si je lis bien ton énoncé,le but est uniquement d'afficher le nombre d’occurrence des saisies et non pas de restituer la saisie dans l'ordre de saisie.Dans ce cas,je préféré la solution de Sve@r qui lui propose un structure(qui peut aussi contenir les positions des saisies si nécessaire) voire même une liste chaînée pour éviter de gâcher de la mémoire inutilement

Citation:

Puis je définirais un tableau de 10 "structures de ce type

car dans le cas d'une saisie répétée du même réel,seulement le premier élément sera utilisé sur les dix!
Ceci dit,je pense que pour le reste je suis en phase avec les autres propositions concernant le fonctionnement de ton programme:
Il faudra quelques fonctions pour:
- vérifier et incrémenter si la saisie existe
-créer un élément(valeur et compteur) et l' insérer dans la chaîne si la saisie n'existe pas.
-afficher les couples valeur/compteur
-peut être par la suite supprimer un élément de la liste....

Ainsi l'utilisation des listes chaînées me semble optimale et te permettra d'avoir une bonne gestion de la mémoire,un code évolutif et un but atteint.
:aie:

17/12/2014, 18h02
johnlobs

Une petite question Diogène:

Citation:

Afficher pour i = 0..nElem-1 reel[i] et compteur[i]

Ceci supposait une allocation dynamique de la mémoire pour les tableaux reel et compteurs???
Je dis ça parce que j'ai vu :

Citation:

-Initialiser nElem à 0
-Initialiser le tableau compteur[] à 0

;)
17/12/2014, 18h28
Sve@r

Citation:

Envoyé par johnlobs

...voire même une liste chaînée pour éviter de gâcher de la mémoire inutilement

Attention aux "fausses bonnes idées". Est-ce qu'on doit vraiment écrire toute une gestion de liste chainée (qui nous fait perdre la possibilité d'accéder directement à l'élément [x]) pour éviter de gâcher (au pire) 9x12 (8 octets pour le réel et 4 pour son compteur) soit 108 octets ?

Les listes chainées ont beaucoup d'avantages (dont un très appréciable qui est de ne pas avoir besoin d'un "bloc contigü" de mémoire dans le cas d'une grosse quantité de données qui arrivera au compte-gouttes car dans ce cas travailler avec du realloc devient alors très coûteux) mais c'est quand-même un truc assez conséquent à mettre en oeuvre qui va alourdir le ratio "quantité de code/efficacité au résultat". Et donc quand le max est déjà connu, on peut alors rester au plus simple même si définir un tableau "max" entrainera un gachis qui se révèlera finalement peut-être pas si catastrophique que ça...
18/12/2014, 11h53
johnlobs

Je suis tout à fait d'accord avec toi sur certains points et tout ce que tu dis est vrai.;)
Mais je préfère personnellement perdre du temps à écrire du bon code qui sera évolutif et très performant.

Citation:

qui nous fait perdre la possibilité d'accéder directement à l'élément [x]

Le but n'est pas d’accéder "directement" à l’élément[x] mais plutôt de répondre au problème avec une gestion optimale des moyen mis en oeuvre car ton exemple me plait bien

Citation:

9x12 (8 octets pour le réel et 4 pour son compteur) soit 108 octets

Il faut toujours, pour se baser sur des chiffre, remplacer le 9 par x(avec x>=0) pour garantir une vision assez proche de la réalité et on comprendra très vite que plus x grandi plus ce gâchis de mémoire devient colossal.Ceci étant dit je pense peut être que pour cet exercice une structure peut suffire mais j'essaye juste d'inciter les gens à faire les bons choix et travailler comme si leur programme était important pour les faire prendre les bonne habitudes .
18/12/2014, 20h26
diogene

Citation:

Envoyé par johnlobs

Une petite question Diogène:
...
Ceci supposait une allocation dynamique de la mémoire pour les tableaux reel et compteurs???
Je dis ça parce que j'ai vu :...

Cela ne supposait rien du tout en ce qui concerne le mode d'allocation des tableaux