Newsgroup: it.comp.lang.delphi
Titolo: come calcolare con delphi?

esempio immettendo un valore numerico in un campo come si fa a d ottenere in
un campo correlato una percentuale di quel valore?
es
campo del valore numerico    percentuale        risultato
1000                                        20 %                1200
spero di essere stato chiaro
------------------------------
grazie 2000 a chi risponde

"Cappy":
| esempio immettendo un valore numerico in un campo come si fa a d ottenere
in
| un campo correlato una percentuale di quel valore?
|
| es
| campo del valore numerico    percentuale        risultato
|
| 1000                                        20 %                1200
campo * (1+(percentuale/100)) ;)

campo * (1+(percentuale/100)) ;)
Io direi meglio :
campo + ( campo * 20 ) div 100 
--
Andrea Laforgia (ICQ 87230455)
------------------------------ 
#exclude <windows.h>

"Andrea Laforgia":
| >| campo del valore numerico    percentuale        risultato
| >|
| >| 1000                                        20 %                1200
| >
| >campo * (1+(percentuale/100)) ;)
|
| Io direi meglio :
|
| campo + ( campo * 20 ) div 100
a sto punto mettiamo campo * 1.2 ;)

 campo + ( campo * 20 ) div 100
Ciao, potresti dirmi le ragioni (ottimizzazione? struttura? forma?) che ti
portano a preferire (e a dire che sia
migliore) questa scrittura a quella suggerita da Alan Solo ?
Grazie, Davide DG

 campo + ( campo * 20 ) div 100
meglio la prima: se si tratta di valuta funziona anche con l'euro, con la
tua no (non considera i decimali)
Ciao, Sandro

a sto punto mettiamo campo * 1.2 ;)
E in caso di percentuale non conosciuta ?


migliore) questa scrittura a quella suggerita da Alan Solo ?
Il calcolo numerico insegna che quando si esegue una divisione tra due
numeri molto vicini tra loro c'e' una grande perdita di precisione.
Moltiplicando campo per la percentuale si accresce il valore del
dividendo. Inoltre questa e' l'operazione corretta da fare con gli
interi.


meglio la prima: se si tratta di valuta funziona anche con l'euro, con la
Non e' specificato se si tratti di euro o meno.
La divisione tra interi si fa con "div".


 La divisione tra interi si fa con "div".
l'operatore "/" si puo' usare anche con gli interi, ma il risultato sara'
float, ovviamente, e va arrotondato, in caso di campo intero, con round, int
o trunc; non sappiamo la natura del campo, quindi ogni soluzione, per ora,
e' buona.. :)
Ciao, Sandro

 numeri molto vicini tra loro c'e' una grande perdita di precisione.
????
Ciao, Sandro

 wrote in message
news:8s3suh$jh485$1...@ID-43509.news.cis.dfn.de...

Certo che un flame sul calcolo della percentuale non me lo sarei mai
aspettato :-)
Ciao,
Stefano

float
davvero ? :)




E gia' !... :)


 davvero ? :)
ti assicuro!! guarda, non ci credevo neanche io.. ;)
Ciao, Sandro

 E gia' !... :)
l'hai letto nel manuale di Visual Basic eh confessa ;)))
Ciao, Sandro
ps. a parte gli scherzi, hai considerato la dimensione in bit delle
mantisse? i problemi si verificano in particolare con il rapporto tra float
di precisione diversa, e relative mantisse; ma tutto, ovviamente, e' da
rapportare al numero di decimali e quindi alla precisione desiderata per il
risultato

di precisione diversa, e relative mantisse;
Il numero di bit delle mantisse e' indifferente, perche' si puo'
trovare sempre una coppia di numeri tali da riprodurre lo stesso
effetto. In generale, e' sempre vero che due numeri molto vicini tra
loro, divisi o sottratti, portino via gran parte della precisione
(chiaro che si parla di un calcolo che venga compiuto in virgola
mobile).




e' incredibile ! ;)
Scherzi a parte.
Il mio giudizio sull'uso di "/" era relativo al risultato intero,
chiaramente.
<code>
var Dividendo, Divisore, QuozienteIntero : integer ;
    QuozienteReale : real ;
begin
  Dividendo := 3 ;
  Divisore  := 5 ;
  QuozienteIntero := Dividendo / Divisore ; // errato
  QuozienteReale := Dividendo / Divisore ; // corretto
</code>


 mobile).
vuoi dire che 0,2*0,3 (molto vicini tra loro) e' meno preciso che 0,2*9,9
(piu' "lontani") ? E in base a quale regola, di grazia? :)
Ciao, Sandro

"Andrea Laforgia":
| >a sto punto mettiamo campo * 1.2 ;)
|
| E in caso di percentuale non conosciuta ?
si' lo so, e' che tu hai scritto:
| campo + ( campo * 20 ) div 100
... e' esattamente la stessa cosa, solo che c'e'
un'operazione in meno
cmq la mia risposta era lievemente ironica.. :)
Ciao,
Alan Solo

"Zortek"
| > In generale, e' sempre vero che due numeri molto vicini tra
| > loro, divisi o sottratti, portino via gran parte della precisione
| > (chiaro che si parla di un calcolo che venga compiuto in virgola
| > mobile).
|
| vuoi dire che 0,2*0,3 (molto vicini tra loro) e' meno preciso che 0,2*9,9
| (piu' "lontani") ? E in base a quale regola, di grazia? :)
penso che parlasse di divisioni/sottrazioni e non di moltiplicazioni
cmq mi aggiungo alla richiesta 8)

 mobile).
avete mai pensato agli insetti come automi non deterministici ?
--
web:    
http://gnaffy.tripod.com/
e-mail: Gna...@Wappi.com
e-mail: 
bmq...@tin.it
ICQ#:  76488613

 interi.
La tua funzione è errata. Ha un dominio ristretto, perde troppa precisione.
F_Laforgia (campo) =    campo + ( campo * 20 ) div 100
Il secondo addendo è un intero. Ora, dato che non è stato imposto alcun
limite a riguardo,
in teoria potrebbe andare bene. Ma non cosideri 2 cose :
A)  (campo * 20) div 100  ritorna un risultato APPROSSIMATO, quindi tutto il
tuo
     discorso sulla perdita di precisione nelle divisioni tra reali viene a
cadere, in quanto
     introduci una notevole perdita di informazione, il cui ordine di
grandezza è molto
     maggiore dell'errore di cui tu parli.
B)  Il simbolismo "X%Y" indica (correggimi se sbaglio...) :
      Risultato Ideale (privo di approssimazioni) = Y per (X segno di
frazione 100).
 Y è un numero reale, giacchè la parte frazionaria X | 100  non ha nessun
motivo di essere
 arrotondata o troncata alla sua parte intera; questo per il simbolismo
stesso.
La tua funzione non "funziona" : per il semplice fatto che ha un dominio
ristretto
non solo ad alcuni reali, ma è addirittura nel campo degli interi !!
Prova a calcolare il 20 percento di 10001 con la TUA funzione... vedi che ti
perdi
delle informazioni ?
********* IMHO ***********
Per cui la prima soluzione proposta da Alan Solo mi sembra di gran lunga
migliore e la tua,
invece (ma questa è una nota *personale* e non tecnica), mi sembra solo un
tentativo mal
riuscito di "correggere" qualcosa di giusto.
Sperando di non aver offeso nessuno, faccio notare, in anticipo, che, almeno
per quanto
riguarda la prima parte, ho espresso solo considerazioni tecniche.
Ciao,  Davide DG

"Davide DG":
| A)  (campo * 20) div 100  ritorna un risultato APPROSSIMATO, quindi tutto
il
| tuo
|      discorso sulla perdita di precisione nelle divisioni tra reali viene
a
| cadere, in quanto
|      introduci una notevole perdita di informazione, il cui ordine di
| grandezza è molto
|      maggiore dell'errore di cui tu parli.
gia' penso che il punto cruciale sia proprio questo, se si usa div,
si e' nel campo degli interi, quindi il discorso crolla...
| Sperando di non aver offeso nessuno [...]
lo spero anch'io ! :)
Ciao! :)
Alan Solo

(piu' "lontani") ? E in base a quale regola, di grazia? :)
Innanzitutto sto parlando di "divisioni", ovvero di "sottrazioni" e
non di moltiplicazioni (ovvero di addizioni), ovvero sto parlando di
meccanismi tali che possono portare ad una riduzione della precisione.
Non si valuta quanto siano vicini tra loro due numeri, ma quanto la
precisione del calcolo finale sia accettabile.
Una divisione del tipo : 992/993 offre di sicuro un risultato molto
poco preciso. Se non credi a quello che dico, consulta uno qualsiasi
dei libri sull'argomento (calcolo numerico, per la precisione).


 dei libri sull'argomento (calcolo numerico, per la precisione).
... Scusa... ma hai letto il mio post sull'inutilitą di tale attenzione alla
precisione
considerando l'imprecisione della _tua_ formula ?
Ciao, Davide DG

scherzando e non ho capito che non stavi scherzando e cio' che dicevi ;)
No, non sta scherzando e ha ragione da vendere! La FPU (Floating Point
Unit o unità in virgola mobile), ovvero il processore che affianca la
CPU gestendo tutti i comandi per il calcolo decimale, per ovvie
ragioni conserva sempre meglio le cifre più 'pesanti' del numero che
non quelle dopo la virgola. Questo succede preché è costretta a
restituire sempre con precisione la parte intera di un numero mentre
non succede altrettanto per le cifre dopo la virgola che spesso e
volentieri vengono perse dopo operazioni che aumentano l'ordine di
grandezza degli operandi. Es.:
la FPU, molto spesso approssima 2,000000000000000001 / 2 come 1. Non
può più fare la stessa cosa se l'operazione è
2000000000000000001 / 2000000000000000000 poiché non è più possibile
approssimare gli operandi.
Regola generale: mantenere l'esponenziale sempre sul valore minimo che
consente di vedere tutte le cifre decimali compatibilmente con il
numero memorizzato.
Quindi a% di x è molto più preciso come x * a / 100 che non come
 x / 100 * a.
Ciàh...!

| Quindi a% di x è molto più preciso come x * a / 100 che non come
|  x / 100 * a.
stiamo cadendo nel ridicolo,
ma se x * a e' molto vicino a 100 ? :)
Ciao!
Alan Solo

ma se x * a e' molto vicino a 100 ? :)
Il problema ovviamente non si trova nella applicazioni che per il
momento realizziamo io o te. Si pone, invece quando sullo stesso dato
deve essere eseguito un numero considerevole di calcoli in cascata: un
errore nel primo, un errore nel secondo e arrivi alla fine con un
risultato con errore apprezzabile (nel senso che si fa notare!!!).
Ciàh...!