[C- vari] Enigma approssimazioni

[TuLKaS85]

Salve, sono alle prese con un problema da cui non riesco a venirne fuori.

Ci vorrebbe qualcuno esperto con il sistema floating point.
Uso diversi linguaggi tra cui C, Fortran e Matlab.
La questione è la seguente, ho una riga di codice che dipende da una sola variabile, questa variabile è IDENTICA in tutti e tre gli ambienti sopra citati.
L'output purtroppo anche se di pochissimo, è diverso.

Per apprezzare queste differenze sono andato ad osservare le rappresentazioni esadecimali di queste variabili double.

il codice che segue è il medesimo tra tutti gli ambienti (fidatevi), le prime due righe sono quelle originali, le altre sono delle derivazioni, che dovrebbero produrre lo stesso risultato, almeno a livello matematico.

Osservate e giudicate:
(absc1 e absc2 sono dei valori double impostati che ovviamente non cambiano tra i vari casi sotto elencati )

// 1
tabsc1 = (1-absc1)/absc1;
tabsc2 = (1-absc2)/absc2;
// 2
tabsc1 = (0.5/absc1-1+0.5/absc1);
tabsc2 = (0.5/absc2-1+0.5/absc2);
// 3
tabsc1 = (1.0/absc1-1.0);
tabsc2 = (1.0/absc2-1.0);
// 4
tabsc1 = ((0.5-absc1)/absc1+0.5/absc1);
tabsc2 = ((0.5-absc2)/absc2+0.5/absc2);


valori in esadecimale di
absc1
3FE0117FD8ACBD94
absc2
3FDBDD4FCDF1D0EB

Risultati di tabsc1 e tabsc2

Compilatore C: gcc (Codeblock)

tabsc1 tabsc2

3FEFBA4CD894D781 3FF4BFD02B02FEDB

3FEFBA4CD894D781 3FF4BFD02B02FEDB

3FEFBA4CD894D781 3FF4BFD02B02FEDB

3FEFBA4CD894D781 3FF4BFD02B02FEDB

Compilatore Intel Visual Fortran :

3FEFBA4CD894D781 3FF4BFD02B02FEDA

3FEFBA4CD894D782 3FF4BFD02B02FEDA

3FEFBA4CD894D782 3FF4BFD02B02FEDA

3FEFBA4CD894D782 3FF4BFD02B02FEDA

Matlab :

3FEFBA4CD894D781 3FF4BFD02B02FEDA

3FEFBA4CD894D782 3FF4BFD02B02FEDA

3FEFBA4CD894D782 3FF4BFD02B02FEDA

3FEFBA4CD894D782 3FF4BFD02B02FEDA


le differenze riguardano gli ultimi 4 bit della mantissa, anzi gli ultimi due.
Quali sono i valori esatti ?? quelli di C ? o quelli degli altri 2 ambienti ?
Da notare che con il primo valore di absc1 cambiando le formule si riescono ad ottenere due risultati differenti anche in Matlab e Fortran...

[cionci]

tabsc1 = (1.0-absc1)/absc1;
tabsc2 = (1.0-absc2)/absc2;
// 2
tabsc1 = (0.5/absc1-1.0+0.5/absc1);
tabsc2 = (0.5/absc2-1.0+0.5/absc2);
// 3
tabsc1 = (1.0/absc1-1.0);
tabsc2 = (1.0/absc2-1.0);
// 4
tabsc1 = ((0.5-absc1)/absc1+0.5/absc1);
tabsc2 = ((0.5-absc2)/absc2+0.5/absc2);

[TuLKaS85]

usare 1 o 1.0 in c da gli stessi risultati, in fortran uso le opportune costanti
1d+00 anche in matlab non cambia nulla.

[cionci]

Io credo che sia solo una questione riguardante l'ordine in cui vengono effettuate le varie operazioni.

[||ElChE||88]

Non potrebbe essere per via dell'arrotondamento?

[TuLKaS85]

Io credo che sia solo una questione riguardante l'ordine in cui vengono effettuate le varie operazioni.

in che senso ?
cioè dici che se faccio prima il secondo blocco , per esempio ottengo risultati differenti ?

[TuLKaS85]

Non potrebbe essere per via dell'arrotondamento?

potrebbe, ma vorrei capire bene il motivo, si tratta di operazioni di divisione e moltiplicazione, i sistemi aritmetici sono standard, comuni a tutti e tre ambienti.

[||ElChE||88]

i sistemi aritmetici sono standard, comuni a tutti e tre ambienti.
In C c'è una macro che cambia valore a seconda del tipo di arrotondamento usato (FLT_ROUNDS - float.h). C'è qualcosa di simile in Matlab?

[cionci]

In C c'è una macro che cambia valore a seconda del tipo di arrotondamento usato (FLT_ROUNDS - float.h). C'è qualcosa di simile in Matlab?
Ma dove verrebbe usato l'arrotondamento in quelle istruzioni ?

[TuLKaS85]

in C c'è l'approsimazione al più vicino, in matlab e fortran nn saprei, penso sia uguale...

[tiMo]

benvenuto nel magico mondo della Floating-Point Arithmetic. :)

Credo che un buon punto di partenza sia questo riferimento

David Goldberg (1991), “What Every Computer Scientist Should Know About Floating-Point Arithmetic”, ACM Computing Surveys, 23/1, 5–48, also available via http://docs.sun.com/source/806-3568/ncg_goldberg.html.

To quote from “The Elements of Programming Style” by Kernighan and Plauger:

10.0 times 0.1 is hardly ever 1.0.

In breve, ci sono numeri che hanno una rappresentazione decimale esatta, ad esempio 1/2 = 0.5. Altri numeri non hanno una rappresentazione decimale esatta, ad esempio 1/3 = 0.3 periodico. Questi ultimi numeri sono soggetti a troncamento e hanno una rappresentazione che dipende dalla precisione del OS e del compilatore. Il tipo di operazione che si esegue su di essi determina una perdita ulteriore di precisione e questo spiega perchè ottieni risultati diversi quando fai operazioni diverse che dovrebbero restituire lo stesso valore.

Infine, compilatori diversi hanno precisioni diverse di default e/o usano rappresentazioni diverse (non sono esperto di compilatori però) e questo spiega perchè ottieni risultati diversi anche usando compilatori o software differenti.

Ciao

tiMo

[cionci]

Mi potresti dire i valori di absc1 e absc2 ?

[TuLKaS85]

grazie per le risposte :)

x timo

i numeri di partenza, sono identici fino all'ultimo bit su tutti i compilatori.
Quindi sono le operazioni effettuate che pregiudicano il risultato differente, purtroppo siamo ancora sul vago, ho bisogno di una risposta + precisa.
Devo capire come fare ad ottenere gli stessi identici valori , o se ciò è impossibile, devo capire bene la causa...

x cionci

valori in esadecimale di
absc1
3FE0117FD8ACBD94
absc2
3FDBDD4FCDF1D0EB

in decimale rappresentazione double, ma quella esadecimale è + accurata
absc1
0.502136157219797
absc2
0.435382796399849

[tiMo]

grazie per le risposte :)

x timo

i numeri di partenza, sono identici fino all'ultimo bit su tutti i compilatori.
[...]



beh, questo lo davo per scontato :)



Quindi sono le operazioni effettuate che pregiudicano il risultato differente,
purtroppo siamo ancora sul vago, ho bisogno di una risposta + precisa.
Devo capire come fare ad ottenere gli stessi identici valori , o se ciò è impossibile, devo capire bene la causa...

[...]



lo puoi capire studiando a fondo il riferimento che ti ho fornito. Alcune operazioni ti portano a una perdita di precisione più di altre, non ci sono regole fisse, dipende da caso a caso. Dovresti usare la formula che ti rende minima la perdita di precisione.
Una prima idea la puoi avere confrontando i risultati delle varie formule con quelli ottenuti simbolicamente (Mathematica, Maple, o Matlab symbolic math toolbox).

Appunto, se la precisione è la tua priorità allora ti consiglio di lavorare in modo simbolico con Mathematica oppure lavorare in alta precisione

http://crd.lbl.gov/~dhbailey/mpdist/

Mathematica è fra i migliori software in questo senso, perchè cerca di controllare automaticamente la perdita di precisione, vedi anche

http://reference.wolfram.com/mathematica/tutorial/ArbitraryPrecisionNumbers.html

buona lettura

tiMo

[TuLKaS85]

ok grazie, io + che risolvere il problema, che comunque non è molto rilevante ai fini del risultato finale, devo capire a livello teorico cosa succede a quei bit finali.

Mi sà che mi devo vedere per bene il primo articolo che mi hai postato !!

:D

[tiMo]

ok grazie, io + che risolvere il problema, che comunque non è molto rilevante ai fini del risultato finale, devo capire a livello teorico cosa succede a quei bit finali.

Mi sà che mi devo vedere per bene il primo articolo che mi hai postato !!

:D

per la versione in pdf:

http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf

ciao

tiMo

[cionci]

#include <stdio.h>

void printDouble(double d)
{
int *i = (int *)&d;
printf("%.15lf = %08X%08X\n", d, i[1], i[0]);
}

double buildHexDouble(char *str)
{
int i[2];

sscanf(str, "%08X%08X", &i[1], &i[0]);

return *(double *)&i;
}


int main()
{

double absc1 = buildHexDouble("3FE0117FD8ACBD94");
double absc2 = buildHexDouble("3FDBDD4FCDF1D0EB");

printf("Input:\n");
printDouble(absc1);
printDouble(absc2);

printf("\nMetodo 1:\n");
printDouble((1.0-absc1)/absc1);
printDouble((1.0-absc2)/absc2);

printf("\nMetodo 2:\n");
printDouble((0.5/absc1-1.0+0.5/absc1));
printDouble((0.5/absc2-1.0+0.5/absc2));

printf("\nMetodo 3:\n");
printDouble((1.0/absc1-1.0));
printDouble((1.0/absc2-1.0));

printf("\nMetodo 4:\n");
printDouble(((0.5-absc1)/absc1+0.5/absc1));
printDouble(((0.5-absc2)/absc2+0.5/absc2));
printf("\n");

return 0;
}
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


Ora il mio eseguibile è in formato Release con ottimizzazione -O2 o -O3 (ottimizzazione massima):

Input:
0.502136157219797 = 0000000000400AD0
0.435382796399849 = 3FE0117FD8ACBD94

Metodo 1:
0.991491721163342 = 3FDBDD4FCDF1D0EB
1.296829383863886 = 3FEFBA4CD894D781

Metodo 2:
0.991491721163342 = 3FF4BFD02B02FEDA
1.296829383863886 = 3FEFBA4CD894D782

Metodo 3:
0.991491721163342 = 3FF4BFD02B02FEDA
1.296829383863886 = 3FEFBA4CD894D782

Metodo 4:
0.991491721163342 = 3FF4BFD02B02FEDA
1.296829383863886 = 3FEFBA4CD894D782

Ottimizzazione -O1:

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

Come vedi a seconda delle ottimizzazioni scelte i risultati sono diversi !!!
E' semplice anche capirne il motivo. 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.

Ora vediamo di sfruttare questi 80 bit:

long double absc1 = buildHexDouble("3FE0117FD8ACBD94");
long double absc2 = buildHexDouble("3FDBDD4FCDF1D0EB");

Risultato con ottimizzazione -O:

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

Risultato con ottimizzazione -O2:

Input:
0.502136157219797 = 0000000000400B00
0.435382796399849 = 3FE0117FD8ACBD94

Metodo 1:
0.991491721163342 = 3FDBDD4FCDF1D0EB
1.296829383863886 = 3FEFBA4CD894D781

Metodo 2:
0.991491721163342 = 3FF4BFD02B02FEDB
1.296829383863886 = 3FEFBA4CD894D781

Metodo 3:
0.991491721163342 = 3FF4BFD02B02FEDB
1.296829383863886 = 3FEFBA4CD894D781

Metodo 4:
0.991491721163342 = 3FF4BFD02B02FEDB
1.296829383863886 = 3FEFBA4CD894D781

Risultato in forma di Debug (no ottimizzazione):

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

[TuLKaS85]

wow grazie mille cionci, ma ora ti devo chiedere alcune cose :)

allora non ti dico il mio metodo per recuperare l'input double dall'esadecimale :P

voglio capire il tuo

con sscanf sovrascrivi gli indirizzi delle due posizioni dell'array con i due valori esadecimali, ora non capisco da dove esce il numero floating point.
&i[0] contiene la prima parte della rappresentazione hex &i[1] la seconda...
facendo il cast come esce fuori un valore double non l'ho capito...
me lo spiegheresti gentilmente ??
return *(double *)&i; ???????

Poi vedo che i miei risultati GCC (codeblock) si trovano con i tuoi long double e ottimizzazione -O , vorrei provare il tuo codice direttamente su linux, ma come imposto l'ottimizzazione ? e cosa vuol dire lanciare un codice con ottimizzazione-0 -02 ecc... ?

scusa l'ignoranza ma non ho mai avuto a che fare con queste cose...

[cionci]

Su Linux puoi usare anche Code::Blocks ;)
Per passare i parametri per l'ottimizzazione puoi andare (anche su Windows) in Build options -> selezioni Release e ci sono tutte le opzioni per il compilatore.
Setta solo una opzione -O alla volta.
Vanne settate in Release perché in debug se le imposti non funziona bene il debugger.

Per il cast è semplice. Due int sono 8 byte, esattamente quanto un double. Facendo il cast a double del puntatore al primo elemento del vettore ottieni quindi un puntatore ad una zona di memoria che contiene i due elementi. Metti l'asterisco davanti ed ottieni il double che viene copiato per valore nel risultato ritornato dal return.

[cionci]

Ah...già che ci sei, se lavori con i long double, usa i literal mettendo una "elle" dopo ;)

(1.0l - absc1) / absc1

Ovviamente tutti i double devono diventare long double.

[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 :D)

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 !



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 :D)


-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]

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]

[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]

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

Vero è :mad:

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]

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 :doh:
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!