[C- vari] Enigma approssimazioni

[TuLKaS85]

allora, usando codeblock, senza particolari opzioni, lasciando tutto com'è, e lavorando solo su double ottengo in modalità debug gli stessi risultati che ottieni tu utilizzando long double in mod. debug e release -O

cioè:

Input:
0.502136157219797 = 3FE0117FD8ACBD94
0.435382796399849 = 3FDBDD4FCDF1D0EB

Metodo 1:
0.991491721163342 = 3FEFBA4CD894D781
1.296829383863886 = 3FF4BFD02B02FEDB

Metodo 2:
0.991491721163342 = 3FEFBA4CD894D781
1.296829383863886 = 3FF4BFD02B02FEDB

Metodo 3:
0.991491721163342 = 3FEFBA4CD894D781
1.296829383863886 = 3FF4BFD02B02FEDB

Metodo 4:
0.991491721163342 = 3FEFBA4CD894D781
1.296829383863886 = 3FF4BFD02B02FEDB

come mai ?? eppure guardando le opzioni di compilazione debug nn c'è nulla impostato a parte il -g ...

comunque se metto tutto long double non mi funziona il codice, xkè penso la storia dei 2 puntatori int nn vada bene in quanto non c'è + corrispondenza, long double sono 80 bit mentre 2 int arrivano a 64 giusto ?

[cionci]

Ottieni gli stessi risultati solo per il solito motivo dell'ordine delle istruzioni: essendo il compilatore una versione diversa, il codice prodotto è diverso.

Funziona con i long double, ma devi usare i double per la conversione, dopo assegni a long double.
Come ho fatto io nel codice.

Tu devi in ogni caso fare la verifica con le varie opzioni in release.

[TuLKaS85]

allora, lavorando con i double ottengo gli stessi risultati utilizzando le opzioni standard in debug mode, in release -O -O1 -O2

questi risultati sono gli stessi che ottengo normalmente utilizzando i double e le opzioni standard del debug.

con -O3 ho risultati sballatissimi, in quanto non vengono restituiti gli esatti valori di input...

Input:
0.502136157219797 = 77BE285077C05C94
0.435382796399849 = 0022FFE0FFFFFFFF

allora ora voglio capire una cosa, a cosa servono queste ottimizzazioni, dovrebbero velocizzare il programma ?

come mai il mio codeblock non da risultati diversi se uso double e long double ?

il problema non era causato dal fatto che l'fpu lavora a 80 bit e noi mettendoli in un double perdiamo precisione ?

[cionci]

Dipende dal compilatore, non da Code::blocks.
Le opzioni servono per rendere il codice più veloce, evidentemente in quella versione del compilatore, l'ottimizzazione non interviene.

E' possibile anche che gcc su Windows non abbia il supporto ai long double.
Per vederlo fai questa prova:

printf("%d", sizeof(long double));

Deve ritornare 10.

Con -O3 succedeva anche a me. Probabilmente il compilatore interviene in qualche modo modificando il codice generato. Imho quindi escludi -O3, che già ti fa partire con un errore più alto (oppure no, magari quella rappresentazione floating point è molto più vicina al numero reale che vuoi rappresentare, chi lo sa )

Nota che il codice che uso per la conversione potrebbe non funzionare più se cambi tipologia di macchina, ad esempio passando da una macchina Little Endian a Big Endian: http://en.wikipedia.org/wiki/Endianness

[TuLKaS85]

codeblock mi dice che il size di un long double è 12 !!

ho fatto anche le prove direttamente sotto ubuntu, utilizzando gcc da terminale, long e double non mi danno distinzioni, se comincio a giocare con le ottimizzazioni varia qualcosa...

comunque sta storia dei double ? anche sotto ubuntu sizeof (long double) mi da 12 !

Originariamente inviato da cionci

Con -O3 succedeva anche a me. Probabilmente il compilatore interviene in qualche modo modificando il codice generato. Imho quindi escludi -O3, che già ti fa partire con un errore più alto (oppure no, magari quella rappresentazione floating point è molto più vicina al numero reale che vuoi rappresentare, chi lo sa )

-o3 altera il valore di input calcolato a partire dagli esadecimali, quello di partenza e di ritorno non è lo stesso valore, quindi inutile osservare i risultati delle operazioni.

[cionci]

Originariamente inviato da TuLKaS85

codeblock mi dice che il size di un long double è 12 !!

comunque sta storia dei double ? anche sotto ubuntu sizeof (long double) mi da 12 !

Va bene, perché allineano ai 4 byte successivi

[TuLKaS85]

Originariamente inviato da cionci

[code]

L'FPU dei processori x86 internamente lavora SEMPRE a 80 bit. Di conseguenza trasferire un risultato intermedio su un double a 64 bit porta ad un perdita di precisione. Quindi diventa chiaro che il risultato dipende sia dall'ordine di esecuzione delle operazioni, sia da come viene costruito il risultato.

Partiamo dal principio.
Avevo notato che lo stesso codice dava risultati leggermente differenti a seconda del linguaggio utilizzato.

Matlab e Fortran vanno di pari passo mentre C prende un altra strada.

Mi sono concentrato principalmente sul C per comprendere cosa succede a questi bit, ed ho visto che anche utilizzando i long double i risultati non cambiano, quindi presumo che in qualche modo il risultato corretto sia proprio quello di C . Inoltre C riesce a dare i risultati corretti anche senza scomodare i long double...

Questo però succede al mio C sia codeblock che quello sotto ubuntu...
il tuo test invece mostra risultati diversi... che compilatore usi ?

il tuo primo test, quello senza ottimizzazioni, senza l'uso dei long da gli stessi output che a me da il fortran e il Matlab, e questo mi disorienta tutto il discorso...

[cionci]

gcc su Ubuntu

Vedi, secondo me parti da una considerazione errata. Non esiste il risultato corretto: tutti i risultati sono approssimazioni.
Però esiste sicuramente una sequenza di operazioni floating point che minimizza l'errore.

[TuLKaS85]

non sò codeblock che versione di gcc usi, ma su ubuntu io ho la 4.2.3, sembra una versione un pò datata, mi sà che devo aggiornare...

tu che versione hai ? se riesco a mettermi nelle tue stesse condizioni di partenza, ed ottenere quei risultati penso di aver risolto.

Matlab e fortran danno gli stessi risultati che ottieni tu... se anche io ci riesco sono a cavallo

[cionci]

gcc (Ubuntu 4.3.2-1ubuntu12) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Code::Blocks c'è anche per Linux eh

La versione che si scarica con Code::Blocks per Windows è datata...è la 3 e qualcosa.

[Vincenzo1968]

Originariamente inviato da cionci

...
La versione che si scarica con Code::Blocks per Windows è datata...è la 3 e qualcosa.

Vero è

Da qui

http://www.tdragon.net/recentgcc/

è possibile scaricare la versione 4.3.3 per Windows. Ma attenzione, come puoi leggere nel sito, si tratta di una versione non ufficiale.

[TuLKaS85]

Originariamente inviato da =cionci

Compilatore GCC su Linux.
L'output che ottengo con l'eseguibile in formato Debug (no ottimizzazioni) è:

Input:
0.502136157219797 = 3FE0117FD8ACBD94
0.435382796399849 = 3FDBDD4FCDF1D0EB

Metodo 1:
0.991491721163342 = 3FEFBA4CD894D781
1.296829383863886 = 3FF4BFD02B02FEDA

Metodo 2:
0.991491721163342 = 3FEFBA4CD894D782
1.296829383863886 = 3FF4BFD02B02FEDA

Metodo 3:
0.991491721163342 = 3FEFBA4CD894D782
1.296829383863886 = 3FF4BFD02B02FEDA

Metodo 4:
0.991491721163342 = 3FEFBA4CD894D782
1.296829383863886 = 3FF4BFD02B02FEDA

allora ho installato ubuntu 10 che per default porta gcc 4.3.2 (installato come guest con vm-ware su windows xp)

gcc -v mi da quanto segue

i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)

eppure i valori escono sempre gli stessi...
speravo di trovarmi con i tuoi invece escono gli stessi che uscivano sia con codeblock che con il gcc 4.2.3

stesso compilatore stesso codice... stavolta come la mettiamo ?? non voglio pensare che il problema sia avere ubuntu sotto virtual machine...

[cionci]

Già...io ho Ubuntu a 64 bit
Quindi è un altro compilatore, che genera codice ancora diverso.

[TuLKaS85]

ah ok..
penso di poter installare ubuntu 64 bit sotto virtual machine, ormai devo provare ! Ma in generale è possibile installare un S.O a 64 bit su una macchina con processore normale ? Cioè capisco che è un idiozia, ma a livello di funzionamento penso partirebbe lo stesso o no ?

seconda domanda...

devo capire code::block che versione di gcc utilizza, non riesco a trovarla da nessuna parte.

[cionci]

Su Windows nella directory bin c'è l'eseguibile del gcc, basta dargli gcc -v, ma come ti ho detto è un 3.qualcosa.

Solitamente sulla virtual machine devi avere anche il tuo sistema operativo a 64 bit. Dipende cosa intendi per processore normale...qualsiasi processore degli ultimi anno è compatibile con i 64 bit.

[TuLKaS85]

si infatti è la 3.4.5

cmq hai ragione , intendevo processori come i vecchi pentium 4, prima dell'avvento dei dual quad ecc...

vabbè grazie mille, concludo la questione dando la colpa delle differenze ai compilatori!