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°.Originariamente inviata da ing82
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".
Rispondi quotando
