Qui calcule et renvoie la valeur sin(x) approximativement par la formule

la programmation


Fonction d’écriture avec prototype :
double monPéché(double x, double epsi);
qui calcule et renvoie la valeur sin(x) approximativement par la formule :
péché(x) = – + -… +(-1)n
ici n est le premier entier pour lequel | |  epsi est satisfait.

Ce que j’ai essayé :

   double q3() {
       int x;
       int n = 1;
       double p = 0;
       int dau = -1;
       int tongquat2 = 1.0 / (2 * n + 1);
       while (tongquat2 >= 1e-10) {
           tongquat2 = 1.0 / (2 * n + 1);
           p += -1 * dau * pow(-1, n) * pow(x, 2 * n + 1) / (giaithua(2 * n + 1));
           dau *= -1;
           n++;
       }
       return p;
   }
int main(){
   int x;
   scanf("%d", &x);
   printf("sin(%d)= %.6lf", x, q3());
}

pourquoi le code n’est pas correct ? aidez-moi les erreurs.

Solution 1

Il existe trois types d’erreurs qui pourraient être impliquées ici, et nous n’avons aucune idée de laquelle il s’agit :
1) Erreurs de compilation/liaison : vous essayez de compiler votre application et les problèmes sont signalés avant qu’elle puisse s’exécuter. Si j’essaie de compiler votre code comme indiqué, je dois ajouter ces deux lignes :

C
#include <stdio.h>
#include <math.h>

et ajoutez également une “définition factice” du giaithua fonction pour obtenir une compilation propre du code que vous affichez.
Tant que vous n’avez pas une compilation propre, vous ne produisez pas de fichier EXE et votre application ne peut pas s’exécuter.
2) Erreurs d’exécution : elles empêchent votre application de continuer parce que quelque chose s’est produit et que le système ne peut pas gérer – une erreur “diviser par zéro” peut-être, ou une tentative de lecture d’un fichier qui n’existe pas par exemple. =Le système vous affiche un message d’erreur et tue immédiatement votre application.
Nous ne pouvons pas vous aider à résoudre ce problème sans savoir quel était le message, où il s’est produit et quelles données vous avez saisies pour l’obtenir.
3) Erreurs logiques : cela signifie que vous obtenez des résultats inattendus mais que votre application ne plante pas. Par exemple, si vous vous attendez à ce que votre application donne un résultat de 42 mais qu’elle vous donne 666 à la place.
Nous ne pouvons pas vous aider à résoudre ce problème sans savoir quelle était la valeur, ce que vous espériez obtenir, quand vous l’avez obtenu et quelles données vous avez saisies pour l’obtenir.

Je vais supposer que c’est l’un des deux derniers, et le processus permettant de trouver le problème nécessite que votre code s’exécute avec vos données – ce que nous n’avons ni l’un ni l’autre. Compiler ne signifie pas que votre code est correct ! :rire:

Cela dépend donc de vous, mais vous n’êtes pas seul.
Considérez le processus de développement comme la rédaction d’un e-mail : une compilation réussie signifie que vous avez écrit l’e-mail dans la bonne langue – l’anglais plutôt que l’allemand par exemple – et non que l’e-mail contenait le message que vous vouliez envoyer.

Vous entrez maintenant dans la deuxième étape du développement (en réalité, c’est la quatrième ou la cinquième, mais vous reviendrez aux étapes précédentes plus tard) : les tests et le débogage.

Commencez par regarder ce qu’il fait et en quoi cela diffère de ce que vous vouliez. Ceci est important, car cela vous donne des informations sur la raison pour laquelle il le fait. Par exemple, si un programme est destiné à permettre à l’utilisateur de saisir un nombre et qu’il le double et imprime la réponse, alors si l’entrée/sortie était comme ceci :

Input   Expected output    Actual output
  1            2                 1
  2            4                 4
  3            6                 9
  4            8                16

Ensuite, il est assez évident que le problème vient du bit qui le double – il ne s’ajoute pas à lui-même, ni ne le multiplie par 2, il le multiplie par lui-même et renvoie le carré de l’entrée.
Donc avec ça, vous pouvez regarder le code et il est évident qu’il se trouve quelque part ici :

C#
private int Double(int value)
   {
   return value * value;
   }

Une fois que vous avez une idée de ce qui pourrait ne pas fonctionner, commencez à utiliser le débogueur pour découvrir pourquoi. Placez un point d’arrêt sur la première ligne de la méthode et exécutez votre application. Lorsqu’il atteint le point d’arrêt, le débogueur s’arrêtera et vous confiera le contrôle. Vous pouvez maintenant exécuter votre code ligne par ligne (appelé “single stepping”) et consulter (ou même modifier) ​​le contenu des variables si nécessaire (bon sang, vous pouvez même modifier le code et réessayer si vous en avez besoin).
Pensez à ce que chaque ligne du code doit faire avant de l’exécuter et comparez cela à ce qu’elle a réellement fait lorsque vous utilisez le bouton « Passer par-dessus » pour exécuter chaque ligne tour à tour. Est-ce que ça a fait ce que vous attendiez ? Si c’est le cas, passez à la ligne suivante.
Si non, pourquoi pas ? En quoi est-ce différent ?
Espérons que cela devrait vous aider à localiser quelle partie de ce code présente un problème et quel est le problème.
C’est une compétence qui mérite d’être développée car elle vous aide dans le monde réel ainsi que dans le développement. Et comme toutes les compétences, elle ne s’améliore qu’à l’usage !

Solution 2

Sans avoir à regarder de plus près la fonction q3(), il est déjà clair qu’elle ne peut pas calculer un sin() car aucun paramètre n’est passé.

C
int main() {
    int x;
    scanf("%d", &x);
    printf("sin(%d)= %.6lf", x, q3());
}

//modifier:
Au premier coup d’oeil, le compilateur vous prévient sur ce point :

C
int n = 1;
int tongquat2 = 1.0 / (2 * n + 1);
while (tongquat2 >= 1e-10) { ...

Conversion de “double” en “int”, perte de données possible !
Les types de données concernés ne sont pas adaptés et un débordement arithmétique peut également se produire.

コメント

タイトルとURLをコピーしました