Newsgroup: it.comp.lang.c
Titolo: cosa c'e' che non va?

Ciao a tutti,
qualcuno mi spiega perche' un codice banale come questo (conversione
lire-euro) non funziona? da' risultati assurdi!!
----------------------------------------------------------------------------------------------------------------------------------------------------------
...
{
  long double euro;  //float euro;
  int lira = 0;
  euro = convertLE(lira);
  printf("%Lf",euro);                     <- forse e' qui il problema?
  while (!getchar() == '\n');
  return 0;
}
...
long double convertLE(int lira) //float convertLE(int lira)
{
 long double euro;  //float euro;
 euro = lira * 1936.27;
 return euro;
}
----------------------------------------------------------------------------------------------------------------------------------------------------------------
se per esempio:
lira = 1;
in output ho: (valore della variabile euro)
-2053748445326946600000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000.000000
dove sbaglio?
grazie a tutti,
Paolo.

dove sbaglio?
Non lo so, controlla se e come il tuo compilatore supporta i long
double e come la print li deve visualizzare.
Meglio usare:
int lira = 1;

Ciao a tutti,
[...errore legato all'utilizzo di printf con i long double, con
compilatore mingw]
avevi perfettamente ragione, Goodidea!
come chiarito in 
http://www.mingw.org/MinGWiki/index.php/long%20double
,
il mingw non supporta, all'interno del printf, i long double! bisogna
castare a double il valore da mettere a video..
grazie per il supporto,
Paolo.
--
"Ma sono io che comincio a camminare come il mio avatar SL, o lui che
ha sempre camminato come me?". @@@;-)

  euro = lira * 1936.27;
che dovrebbe essere
euro = lira / 1936.27
(purtroppo... ;-))
Benjamin

 (purtroppo... ;-))
oh my god, e' vero ;-D
ecco perche' mi sento cosi' povero ultimamente @@@:-)
grazie mille a tutti x il supporto,


 ecco perche' mi sento cosi' povero ultimamente @@@:-)
Probabilmente ti senti povero anche perché perdi cifre significative nel
trattare il denaro come double. I formati a virgola mobile, per gli errori
di precisione a cui sono sottoposti, non sono la scelta ideale per
memorizzare importi. Bisognerebbe ricorrere a convenzioni specifiche, per
esempio quella di memorizzare gli importi come centesimi usando un intero.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

"Andrea Laforgia" <x...@xx.xx> ha scritto nel messaggio 
news:fgmrev$93e$1...@news.newsland.it...

Un double (IEEE) ha una precisione relativa di 2^(-52), pari a circa 
4*10^(-16),
piu' che sufficiente per immagazzinare anche i femtocentesimi.....
A meno di utilizzare nanoeuro come valuta (e che si puo' sempre scalare
con un fattore multiplicativo, chimato, diciamo "guadagno" fittizio :-)  )
non vedo come possa essere apprezzabile l' arrotondamento.
Usado un float in singola precisione l' errore e' di 2^(-23) , circa 10^(-7)
ovvero 0.000001? (Pari a 1 micro Euro) ;-)
Parlando di acquisizione dati, invece ci possono essere dei casi in cui
l' errore di arrotondamento di un float non e' accettabile e anche quello
di un double  puo' essere significativo, ma non credo siano proprio casi
comunissimi.......
Bye
Brix

piu' che sufficiente per immagazzinare anche i femtocentesimi.....
I tipi a virgola mobile non si usano *MAI* per memorizzare importi in
valuta. Si usano tipi interi o rappresentazioni BCD. Lo fa Delphi, ad
esempio, con il Currency (che è un finto virgola mobile, nel senso che
è un Int64), lo fa COBOL con i COMP-3, lo fanno i database con le
colonne DECIMAL.

"Andrea Laforgia" <a.laf...@andrealaforgia.it.invalid> ha scritto nel 
messaggio news:7ue9j39o3dfuhi1nl...@4ax.com...

Non saprei, non sviluppo gestionali , per cui mi fido: ma anche i gestionali
arrotondano, no ? Almeno la mia banca lo fa e con un arrotondamento
infinitamente peggiore dell' errore massimo commesso da con un double :-(
Brix

arrotondano, no ?
Arrotondano dei valori esatti.

 ovvero 0.000001? (Pari a 1 micro Euro) ;-)
Questo è vero per cifre vicine a zero. Ma su cifre di milioni l'errore 
arriva già ai centesimi.
E.

 arriva già ai centesimi.
Vero. E poi, su operazioni ripetute, l'  errore medio di arrotondamento 
tende a crescere (statisticamente) con la radice quadrata del numero di 
operazioni. Nessuno avrebbe piacere di perdere quantità  arbitrariamente 
grandi di denaro denaro per questo...
In ogni caso,  in contabilità  le cifre devono torare tutte. Non 
esistono pareggi di bilancio  "entro l'arrotondamento". :-)
Giorgio

 pareggi di bilancio  "entro l'arrotondamento". :-)
Basta prendere la cifra mancante e la contabilizziamo sotto la voce spese 
varie  :-)
Una cusiosita': ma i conti, che comprendono sicuramente le 4 operazioni
elementari e magari qualche potenza e logaritmo, come sono fatti ?
C'e' qualche pacchetto particolere dedicato o sono in floating point?
Perche' in questo caso non capisco bene dove sia il problema: se ri-converto
i risultati in intero, di sicuro introduco un errore ulteriore...e poi 
dovrei
ri-convertire il numero in float per altre operazioni ????????
Anche ammesso per assurdo che ogni volta il valore sia arrotondato sempre
per eccesso (ad esempio), per arrivare a poche decine di Euro di errore devo
arrivare a fare sullo stesso numero 4*10^16 manipolazioni, tutte che 
sbagliano
nello stesso senso sempre....
Un simile numero di transazioni, supposto che fosse eseguita da un solo 
calcolatore,
per semplificare, ammettendo di prendere 1microsecondo per elaborazione, non
tenendo conto di tempi di memorizzazione, passaggi su disco o su rete, 
prendera'
1*10^(-6)*4*10^16 secondi, se non ho fatto male i conti sono circa 12683 
anni...
un poco irrealistico mi pare....oppure 1 anno usando 12683 computer in 
parallelo.
E questo usando un long, se si usasse un long double l' errore si ridurrebbe
ancora.
Oltretutto, anche tenendo la parte decimale in un intero, ci sono dei casi 
in cui
e' necessario arrotondare, i numeri periodici non possono essere 
rappresentati
esattamente, ad esempio (o potrebberero essere rappresentati come 
frazioni?).
 Sarei curioso di avere un parere autorevole sulla cosa, tanto per levarmi
qualche dubbio, grazie.
Brix

 elementari e magari qualche potenza e logaritmo, come sono fatti ?
si reimplementano gli algoritmi.
per darti un'idea, cerca "bignum" con google.

C'e' qualche pacchetto particolere dedicato o sono in floating point?
Come già detto, non si usano numero floating point, quindi non si
converte mai nulla in fp. 

"camillo" <a@o.y> ha scritto nel messaggio 
news:MxmZi.166056$%k.30...@twister2.libero.it...

Grazie, interessante.. i bignum da quello che leggo sono dei numeri(anche 
fp) con con
base /mantissa (Numeratore/denominatore) allargata ab libitum per conseguire
la precisione voluta. C'e' anche un pacchetto Gnu. Tra tutte le applicazioni 
citate
pero' mancano quelle finanziarie ;.)
byte
Brix

 pero' mancano quelle finanziarie ;.)
a quali ti riferisci?

 frazioni?).
I numeri non vengono rappresentati come frazioni, ma in forma decimale.
In questo modo le operazioni di somma, sottrazione e moltiplicazione non 
introducono errori. LA divisione invece puo' dare errori. Ad esempio 
quando ti vengono calcolati gli interessi, moltiplicano il tuo capitale 
per il numero di giorni in cui lo tieni depositato (i famosi numeri 
creditori) e quindi applicano la percentuale di interesse. In 
quest'ultima operazione si introduce un errore (che può essere al 
massimo di un centesimo, visto che i conti sono fatti in centesimi) 
dovuto ad una divisione. La mia banca approssimava gli interessi per 
difetto (a favore della banca!). Dopodichè deduceva la tassa 
dall'interesse risultante. Anche questo produce un errore che di nuovo 
viene addebitato al cliente.
Mi ricordo queste sottigliezze perché la mia vecchia banca mi dava degli 
interessi così bassi (tipo 6 centesimi) da essere quasi dimezzati a 
causa di queste approssimazioni.
Comunque questi errori non falsano i conti. L'importante, per la banca, 
è che i trasferimenti da un conto all'altro avvengano sempre mantenendo 
il totale costante. Questo è garantito se si lavora con gli interi, non 
lo sarebbe se si lavorasse con i float.
E.