Seno, coseno e tangente in c++

[Davone98]

Ciao a tutti, sono nuovo nel forum. Stavo provando a creare un programma, appunto in c++, dove ad esempio dati in input il lato a, b e l'angolo alfa, di un triangolo qualunque, dia in output il lato c, l'angolo gamma e beta. Il problema nasce nella risoluzione dell'angolo beta, e di conseguenza nell'angolo gamma. Vi lascio comunque sotto il codice da me utilizzato. Spero mi possiate aiutare a capire l'errore

#include <iostream>
#include <windows.h>
#include <conio.h>
#include <cmath>
using namespace std;
int main ()
{ 
system ("color 1e");
double const rad=0.017453292519943295769236907684886;
double a, c, b, alfa, beta, gamma, risultato;
        cout<<"Inserisci il lato b del trinagolo ";
          cin>>b;
         cout<<"Inserisci il lato c del trinagolo ";
         cin>>c;
         cout<<"Inserisci in gradi l'angolo alfa del trinagolo ";
         cin>>alfa;
         risultato=rad*alfa;
         a=sqrt(b*b+c*c-2*c*b*cos(risultato));
         beta=cos((a*a+c*c-b*b)/2*a*c);
         gamma=180-beta-alfa;
         cout<<"Il lato a vale "<<a<<endl;
         cout<<"L'angolo beta vale "<<beta<<endl;
         cout<<"L'angolo gamma vale "<<gamma<<endl<<endl;
system ("pause");
return (0);
}

[ing82]

#include <cmath>

non è che sia un esperto, quindi non ho idea di cosa non funzioni nel tuo progr, però io di solito uso

#include <math.h>

in cui è definita anche la costante pigreco (M_PI), evitando di inserire a mano tutto quel valore per la trasformazione dell'angolo.
Se ti può essere utile...
Ciao

P.S. magari M_PI funziona anche in cmath, magari sono paraticamente la stessa cosa, spero che qualcuno ci illumini.

[Davone98]

ok, grazie

[Davone98]

comunque beta si dovrebbe calcolare così:
beta=acos((a*a+c*c-b*b)/2*a*c);

[ing82]

comunque beta si dovrebbe calcolare così:
beta=acos((a*a+c*c-b*b)/2*a*c);

Senza metterci più di tanto la testa, ma il problema mi sembra matematico, non di programmazione.
La formula per il calcolo di beta mi sa che è più corretta così

beta=acos((a*a+c*c-b*b)/(2*a*c));

Inoltre, se vuoi i risultati in gradi, devi ricordarti di trasformare beta in gradi prima di usarlo per calcolare gamma.

Fai sapere

[ing82]

...
double const rad=0.017453292519943295769236907684886;
double a, c, b, alfa, beta, gamma, risultato;
cout<<"Inserisci il lato b del trinagolo ";
cin>>b;
cout<<"Inserisci il lato c del trinagolo ";
cin>>c;
cout<<"Inserisci in gradi l'angolo alfa del trinagolo ";
cin>>alfa;
risultato=rad*alfa;
a=sqrt(b*b+c*c-2*c*b*cos(risultato));
beta=acos((a*a+c*c-b*b)/(2*a*c))/rad;
gamma=180-beta-alfa;
cout<<"Il lato a vale "<<a<<endl;
cout<<"L'angolo beta vale "<<beta<<endl;
cout<<"L'angolo gamma vale "<<gamma<<endl<<endl;
system ("pause");
...

testato col classico triangolo rettangolo di lati 3-4-5

[Samuele_70]

Scusate ma cosa sarebbero tutti questi "trinagoli" ?

[ing82]

Scusate ma cosa sarebbero tutti questi "trinagoli" ?

Avevo notato, comunque cercando su Google ho visto che i trinagoli sono una nuova figura geometrica scoperta dal nostro Davone98, che ha tre lati, tre angoli, tre vertici, tre altezze, un'area, un perimetro, la somma degli angoli interni pari a 180°: ma sbaglio o assomiglia molto a un triangolo?

@ Davone98: non voglio prenderti in giro, volevo solamente seguire lo spirito (che io ho interpretato ironico) di Samuele_70 con la sua osservazione.

[M.A.W. 1968]

...la somma degli angoli interni pari a 180°...

Questo è vero solo nella banale geometria euclidea. Nelle assiomatizzazioni alternative, variando il postulato delle parallele, cambia anche la somma degli angoli interni di un triangolo: nelle geometrie riemanniane (ellittica e sferica) tale somma eccede l'angolo piatto, e per contro nella geometria iperbolica di Lobacevskij-Bolyai la somma in questione non raggiunge i fatidici 180°.

Comunque, tornando all'argomento della discussione, math.h sta al C come cmath sta al C++: sono header alternativi e mutuamente esclusivi, come spesso è il caso per i due distinti linguaggi.


PS: Le terne pitagoriche (intere) sono ovviamente fondamentali, ma è sempre meglio svolgere test estensivi su valori razionali o reali, perché questo genere di implementazioni naif dette anche ho-copiato-la-formuletta-come-era-scritta-sul-manuale-di-analisi è soggetto ad approssimazioni a volte sorprendenti. In generale, oltre a dover rispettare religiosamente le regolette di precedenza degli operatori aritmetici, è meglio studiare a fondo un testo di calcolo numerico (meglio che niente, questo paper) prima di lanciarsi nella programmazione matematica o nella geometria analitica con valori floating point IEEE 754. Quasi sempre è necessario riorganizzare le operazioni in modo del tutto controintuitivo per ottenere risultati minimamente affidabili - anche in casi banalissimi.

La frase che ho sentito più spesso dai miei clienti e datori di lavoro nella prima quindicina d'anni della mia carriera, a cavallo tra il termine degli studi e i primi anni di apprendistato, è stata "Ah, menomale che è arrivato lei, abbiamo giusto un problemino con XYZ" dove XYZ è un qualsiasi artefatto informatico che contiene la sottoespressione "floating point". Naturalmente il "problemino" in questione, ad una prima sommaria analisi, appariva richiedere dai sedici a venti mesi/uomo di lavoro. Dopo avere analizzato un buon 30% del codice, ho praticamente sempre deciso di riscrivere tutto da capo.

In giro, soprattutto in quei tempi pionieristici, c'erano tanti programmatori bravissimi col COBOL, il FORTRAN, il BASIC e magari anche l'assembly, ma nessuna reale competenza nel campo del calcolo numerico applicato, dell'aritmetica computazionale low level e della progettazione della risoluzione numerica (rational, fixed point, floating point binario o decimale...) in funzione del risultato e dei tempi di calcolo desiderati. Anche oggi i manuali di calcolo e quelli di stabilità dei metodi numerici sono tra i meno letti ed apprezzati, paradossalmente proprio da chi ha bisogno del computer per scrivere procedure di calcolo anche corpose, dagli ingegneri ai fisici ai biochimici. Sì, Matlab e affini fanno quasi tutto, ma il problema spesso è proprio quel "quasi".

[Samuele_70]

Era solo una battuta, facile e scontata, tanto per sorridere un poco, in fondo, a volte, tutti facciamo di questi sfrondoni