Discussion :

[arkate]

Bonjour, j'ai un exercice où j'ai quelques difficulté dessus, je ne comprend pas ce que mon prof me demande de faire, j'ai juste réussi la question 1), je vous fournis le début du sujet avec les questions dont je n'ai pas compris. Merci d'avance de votre aide.

[Bousk]

Nous ne réalisons pas les exercices.

[bacelar]

Nous ne réalisons pas les exercices.

T'as raison, mais putain, c'est quoi ce code tout pourri !!!

Le C/C++, ça n'existe pas, sauf pour les ignorants (donc les RHs, et, visiblement, pour les prof. d'Université qui confondent Mathématiques et Informatique apparemment).
Franchement, ce code, en C, c'est 0/20, car il ne compile même pas.
En C++, c'est 2/20 en étant gentil, parce que c'est littéralement une ou plusieurs mauvaises pratiques à chaque ligne, belle performance !!!

2 -
La phase d'initialisation, c'est jusqu'au while (non compris).
La phase "répétitive" c'est le while et son contenu.

3 + 4
Remplacer l'appel à la fonction "carre" à une fonction factorielle que vous implémenterez.
ou pas :http://www.cplusplus.com/forum/unices/33379/
Mais bon, elle va vite explosée avec un overflow sur les entiers, votre fonction "factorielle", mais bon, à la vue de la "qualité" du code de votre prof., il va pas nous casser les roubignoles.

[Mat.M]

bah c'est pas compliqué si tu as le signe sigma cela signifie faire une somme sur une domaine de définition donc il faut voir si cette expression est valide sur le domaine de définition ce qui vérifie le théorème.
Ensuite en pratique une somme mathématique c'est faire une boucle

T'as raison, mais putain, c'est quoi ce code tout pourri !!!

ce n'est pas une raison pour dénigrer et mépriser le travail des autres

[bacelar]

ce n'est pas une raison pour dénigrer et mépriser le travail des autres

OK, mais là, c'est un prof. qui code à la truelle, pour, au mieux, complexifier inutilement son exercice, mais au pire faire prendre de sales habitudes à ses ÉLÈVES.

[Seabirds]

Bonsoir !

Nous ne réalisons pas les exercices.

Oui, Bousk a raison: si j'ai bien appris une chose sur ce forum, c'est qu'on ne te résoudra pas tes exercices. Il faut que tu viennes avec une ébauche de solution, et que tu commences la discussion en abordant un point particulier que tu n'as pas compris.

OK, mais là, c'est un prof. qui code à la truelle, pour, au mieux, complexifier inutilement son exercice, mais au pire faire prendre de sales habitudes à ses ÉLÈVES.

Heu c'est vrai que le code m'a un peu étonné Mais pour la défense des enseignants-chercheurs, il est apparemment très compliqué de suivre les évolutions des langages et bonnes pratiques si on y passe pas un temps considérable (autrement dit, si ce n'est pas notre coeur de métier). Or, plus on avance dans la carrière universitaire, plus les contours du coeur de métier se floutent : administration, évènementiel, demandes de financements, encadrement et autres responsabilités (direction des laboratoires, conseils scientifiques, réunions pédagogiques... ) se surajoutent et viennent compliquer la tâche de se maintenir à jour des pratique de développement.
La (malheureuse) conséquence est que les profs sont débordés et que les étudiants auront des lacunes. J'imagine que le problème est bien connu, il est régulièrement abordé sur le forum. Etant moi-même en tout début de carrière universitaire, je risque fort d'enseigner dans le futur lointain un style de code vieux de C++14, ce que je vivrais assez mal, et je serais donc curieux de savoir si vous aviez une solution à proposer


Arkate, pour savoir pourquoi ce code provoque quelques réactions passionnées, je t'invite à lire les lignes suivantes. Bacelar, entre deux grognements de protestation, t'a déjà beaucoup aidé pour les questions 2,3 et 4.

1) Ne prends pas l'habitude de mettre using namespace std;, surtout si tu débutes. Cela t'évitera pas mal de problèmes, pour peu que tu acceptes de préciser l'espace de nom auquel appartiennent les fonctions que tu utilises (c'est à dire écrire par exemplestd::cout au lieu de cout). C'est je crois un prix très raisonnable

2) Evite d'inclure les fichiers en ".h", comme dans include <math.h>, qui d'après ce que j'ai compris sont plutôt des trucs hérités de C. Tu leur préfèreras leur équivalent C++ en utilisant include <cmath>. Je n'ai pas trouvé d'utilité à inclure stdlib.h.

3) La fonction pour calculer le carré d'un nombre ne me semble pas très utile dans ce code. Tu peux simplement calculer n*n.

4) Ne déclare JAMAIS deux variables sur une même ligne, ni même deux instructions par lignes. Ca mène à du code relou à lire, où le nombre de variable déclarées est difficile à cerner. Je me suis par exemple planté en simplement recopiant les lignes 10 et 11 du code fourni, parce qu'elles sont trop denses.

5) Perso, j'aime bien calculer mes variables bien avant de les sortir en console, en leur donnant un nom clair. Du coup je me fais une idée différente de la valeur d'une variable qui serait nommée pi ou pi_approx La première nous incite à croire qu'elle désigne la "vraie" valeur de pi, alors qu'on anticipe que la seconde serait plutôt sa valeur approchée par un algorithme. En passant, chose amusante, une valeur assez précise de PI est donnée par <cmath> en utilisant M_PI. Ca m'a paru utile.

6) Ultimes détails, la fonction std::abs (et pas std::fabs) est suffisante, et traditionnellement on retourne un 0 à la fin du main.

En corrigeant tous ces points, je te propose une nouvelle version de code, que tu peux compiler et exécuter. Evidemment je suis bien moins calé en C++ que les autres, ils me corrigeront si nécessaire

Bon courage !

Fichier file.cpp :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
//  compiles with g++ file.cpp -std=c++14 -Wall
#include <iostream>
#include <cmath>
 
int main(){
 
  double seuil;
  std::cout << "Saisir le seuil de convergence du calcul:" << std::endl;
  std::cin >> seuil;
 
  double somme = 0;
  int n = 1;
  double valeur = 1.0/(n*n);
 
  int iter_max;
  std::cout << "Nombre maximum d'itérations acceptable:" << std::endl;
  std::cin >> iter_max;
 
  while( valeur > seuil && n < iter_max ){
    somme += valeur;
    n++;
    valeur = 1.0/(n*n);
  }
 
  double pi_approx = std::sqrt(6*somme);
  double precision = std::abs(M_PI - pi_approx);
  std::cout << "Seuil de convergence: " << seuil << "\n"
            << "Coût (nombre d'itérations): " << n << "\n"
            << "Valeur approchée de pi: " << pi_approx << "\n"
            << "Précision:" << precision << std::endl;
 
  return 0;
}

Exemple d'output:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Saisir le seuil de convergence du calcul:
0.0000001
Nombre maximum d'itérations acceptable:
10000
Seuil de convergence: 1e-07
Coût (nombre d'itérations): 3163
Valeur approchée de pi: 3.14129
Précision:0.000301969

[arkate]

Bonjour, merci pour toutes vos réponses je ne pensais pas que ce code allait lancer autant de polémique ahah, mais vos réponses m'ont permis d'avancer dans l'exercice.

[koala01]

Heu c'est vrai que le code m'a un peu étonné Mais pour la défense des enseignants-chercheurs, il est apparemment très compliqué de suivre les évolutions des langages et bonnes pratiques si on y passe pas un temps considérable (autrement dit, si ce n'est pas notre coeur de métier). Or, plus on avance dans la carrière universitaire, plus les contours du coeur de métier se floutent : administration, évènementiel, demandes de financements, encadrement et autres responsabilités (direction des laboratoires, conseils scientifiques, réunions pédagogiques... ) se surajoutent et viennent compliquer la tâche de se maintenir à jour des pratique de développement.
La (malheureuse) conséquence est que les profs sont débordés et que les étudiants auront des lacunes.

Quand quelqu'un veut apprendre la menuiserie, l'électricité, la mécanique ou la boulangerie, on va le fourrer dans les pattes de profs dont c'est le métier, qui ont -- pour la plupart -- généralement au minimum une dizaine d'années d'expérience dans leur domaine, et qui pourront aider efficacement l'élève à gagner en compétence.

Et je sais de quoi je parle (même si cela remonte à plus de vingt ans, et que les choses ont sans doute évolué depuis), vu que c'est une filière que j'ai moi même suivie à l'époque.

Mais, dés lors, pourquoi demandons nous à des profs qui sont très certainement très compétents dans leur domaine de donner des cours dans une matière qu'ils ne maîtrisent absolument pas et pour laquelle ils n'ont ni le temps ni -- on peut le craindre -- l'envie de se tenir à jour

Pourquoi ne pas faire appel à des techniciens professionnels, qui restent à jour "par la force des choses" dans leur domaine de compétences pour fournir une fournir une formation "de base" (voire plus complète si besoin/ si le temps s'y prête) aux élèves

Pourquoi les universités semblent-elles persuadées qu'il n'y a qu'en recevant des cours de la part d'un BAC+7 que ses futurs BAC+7 pourront apprendre quoi que ce soit

J'imagine que le problème est bien connu, il est régulièrement abordé sur le forum. Etant moi-même en tout début de carrière universitaire, je risque fort d'enseigner dans le futur lointain un style de code vieux de C++14, ce que je vivrais assez mal, et je serais donc curieux de savoir si vous aviez une solution à proposer

Comme tu as déjà conscience du risque, tu as de bonnes chances de l'éviter... D'autant plus que tu as eu "le bon gout" de t'intéresser aux évolutions.

Il se peut (je ne suis pas devin, hein ) que tu n'aies pas ** assez ** de temps à consacrer au fait de rester parfaitement à jour en C++, ne serait-ce que parce que tu as "autre chose" à faire, mais ta situation sera en tout cas bien moins catastrophique que celle de profs qui ont appris C++ alors qu'il n'était pas encor standardisé et qui ne se sont jamais mis à jour

Mais, pour te donner une idée: cela fait plus de quinze ans que l'on se bat pour éviter l'amalgame "C / C++" en disant que ce sont deux langages totalement différents, et que si C++ ne renie absolument pas ses origines et qu'il offre une certaine compatibilité avec C, il faut le considérer comme un langage à part, et que les habitudes issues du C sont mauvaises (pour ne pas dire pire) en C++.

Toi, tu as déjà "franchi cette étape". Ce que l'on voudrait, c'est que d'autres vieux tromblons, couverts de poussière et de toiles d'araignées finissent par s'en rendre compte