? Algoritmo della funzione Round()

di **piercing** » 16/01/04 14:58

Chi conosce con esattezza la logica dell'arrotondamento di un numero decimale?

Da quanto ho sempre saputo e da 25 esami di ingegneria l'arrotondamento di un numero si fa vedendo:

- se la parte decimale è minore di 50 si arrotonda all'intero inferiore
- se è maggiore o uguale a 50 si arrotonda all'intero superiore

Il discorso differisce in due scuole di pensiero per i numeri negativi.

Ora vi racconto l'algoritmo di Microsoft.... :eeh:

(è anche indicato sui manuali dopo giorni di ricerca!)

Quando la parte frazionaria è uguale a 0,5, viene sempre arrotondata al numero pari più prossimo. 0,5, ad esempio, viene arrotondato a 0, mentre 1,5 viene arrotondato a 2.

Qualcuno sà il motivo storico o la provenienza di quest'algoritmo???

di **ezechiel2517** » 16/01/04 15:04

Non credo di aver capito pier!!! :-?

Nell'esempio che citi i numeri sono positivissimi!!!

L'hai trovata online?? Se si dove?

di **piercing** » 16/01/04 15:10

Non è il fatto che sia positivo e negativo (parliamo solo di positivi).

La frase è tratta dal Manuale Microsoft di VBScript.

Nel mio caso me ne sono accorto dopo ore di debug di un VBA di Excel.

Leggi quello che scrivono... chiunque di noi direbbe che 0,5 si arrotonda ad uno... M$ lo arrotonda a 0 perchè è un numero PARI.

:eeh:

di **ezechiel2517** » 16/01/04 15:14

Ah..ok allora avevo capito!!! Anche io arrotonderei 0.5 a 1!
La risposta che ti posso dare e': non ne ho idea!!!

Immagino che avrai gia cercato sul web e quindi non ci provo neanche!!!

di **piercing** » 16/01/04 15:17

E se non lo sai te... che sei l'Oracolo, nonchè gran guru del VBA non mi resta che implementare l'algoritmo corretto a manina.

Particolarità: la funzione ARROTONDA di Microsoft funziona come da standard...

di **ezechiel2517** » 16/01/04 15:25

Non credo tu ne abbia bisogno....ma ci ho provato anche (sono curioso come una scimmia!!

)

e se nella macro usassi la funzione arrotonda invece che il round()??

di **pjfry** » 16/01/04 15:26

trunc+1 per i positivi dovrebbe andare, no?
il motivo storico forse è da cercare in qualche codifica che usano per i decimali, chissà...

di **pjfry** » 16/01/04 15:35

pjfry ha scritto:trunc+1 per i positivi dovrebbe andare, no?

insomma... solo se il decimale è .5 , ovviamente...

di **piercing** » 16/01/04 18:53

beh.... la funzione esatta è questa se dovesse mai servire:

Codice: Seleziona tutto: If (Importo - Int(Importo)) < 0.5 Then Importo = Int(Importo) Else Importo = Int(Importo) + 1

Con le dovute cautele in caso di Importo < 0

di **pjfry** » 16/01/04 22:17

ho trovato della roba
l'algoritmo si chiama "banker's rounding", sembra assurdo ma è studiato per evitare errori quando si sommano tanti numeri arrotondati (lavorando con i computer lo sono praticamente tutti...)
il discorso pari e dispari serve solo per pareggiare le probabilità
in pratica se sommi tanti numeri arrotondati con questo algoritmo, statisticamente, il 50% è verso l'alto e il 50% verso il basso...
esempio:
1.15+1.25=1.4
arrotondo ad una cifra con il metodo 'ingegneristico' : 1.2+1.3=1.5
arrotondo ad una cifra con il metodo 'del banchiere' : 1.1+1.3=1.4

di **Plettro** » 17/01/04 14:19

Forse 2,4 a ingegneria e 2,5 in banca... no PJ ? ;-)

Comunque non mi torna con quello che sostiene pier...dovrebbe fare:
1,2 + 1,2 = 2,4 se scegli la cifra PARI più prossima no?

Mah! L'esame di analisi numerica mi ha sempre fatto c****e! E ho dimenticato quasi tutto.
Comunque anche OpenOffice fà come Excel mi sembra di vedere.

di **Plettro** » 17/01/04 14:23

Scusa PJ ovviamente volevo segnalare solo il 2 ...ma l'ordine è inverso... Arghh

2,4 in banchiere e 2,5 per gli ingegneri.
Accidenti all'edit che non c'è!
ciao ciao

di **pjfry** » 17/01/04 14:59

d'oh! ho sbagliato + o - tutto :lol:

effettivamente con il banker's è:
1.2+1.2=1.4
però è la dimostrazione involontaria che sarebbe lo stesso scegliendo il dispari + vicino invece del pari

di **Plettro** » 17/01/04 15:03

Ah ah ah !!
E' vero...o meglio mi rattrista pensare a Pier che ci batte il capo...se le cose stanno in questo modo...
Ciao mitico PJ

di **piercing** » 17/01/04 21:03

beh plettro... non ti rattristare... tutto si risolve... ;-))

basta scriversele a mano le funzioni...

mi rimaneva però davvero strano questo sistema di calcolo... e sinceramente ancora l'ho capito poco... non vedo cosa cambi al banchiere nel prendere il pari o il dispari o tutti e due... boh...

poi con i mezzi moderni in cui non è un problema il numero dei decimali ne capisco ancora meno l'utilità...

la cosa stranissima è che sia l'algoritmo di default di una funzione tanto comune...

Qualcuno che ha visual basic mi dice se si comporta nello stesso modo? o si sono proprio sbagliati i programmatori del VBScript visto che anche Excel - nel quale poteva anche avere un senso - l'algoritmo utilizzato è quello canonico?

di **pjfry** » 17/01/04 21:29

mi pare di aver letto che lo usa pure openoffice, sbaglio? sicuro che excel usi quello canonico?
in visualbasic te lo provo lunedì se mi ricordo...

al banchiere dovrebbe convenire perchè su un gran numero di somme 'statisticamente' si fà un errore di approssimazione minore... come tutta la roba statistica però ti accorgi dell'utilità quando il numero di fattori tende all'infinito :neutral:

di **piercing** » 18/01/04 00:52

sicurissimo pj....

proprio perchè stavo trasformando una funzione ARROTONDA() in una function in VBA... tutto il problema è nato da li...

resta il fatto che da almeno cinque anni faccio ai clienti programmi sbagliati... :eeh:

(in particolare mi riferisco ad ASP).

Chi l'ha detto che su un gran numero di somme l'errore viene minore...??

di **pjfry** » 18/01/04 01:02

giusto, ho provato... cancelliamo il topic prima che i clienti ti sgamino? :lol:

l'errore viene minore perchè il 5 stà nel mezzo... il fatto di arrotondarlo per eccesso è una convenzione ma se ci pensi non è mica tanto giusta... prendi l'esempio che ho postato sopra per esempio (vabbè che ho perso tutta la credibilità che potevo avere facendo 1+1=1 :oops:

)
su un gran numero di somme dovresti avere una distribuzione uniforme dell'ultimo decimale (quello da arrotondare, diciamo che sia uno solo tanto poi il ragionamento è ricorsivo, credo)... avrai un 10% di 0, un 10% di 1, ... 10% di 5 ... 10% di 9
lo zero non dà errori, gli errori per i decimali da 1 a 4 bilanciano quelli per i decimali da 6 a 9... e il 5 fà casino se lo arrotondi sempre per eccesso, no? se invece lo arrotondi una volta su e una giù (cosa che statisticamente succede... avrai 50% dispari e 50% pari) in pratica non dà errori come lo zero...
probabilmente se mi becca un matematico si mette a piangere, ma a me il ragionamento fila

di **ezechiel2517** » 19/01/04 09:52

Il ragionamento di PJ potrebbe funzionare se i numeri sono equamente distribuiti.
Ma se sono numeri molto simili allora la distribuzione dei decimanli non e' piu' uniforme!!

di **pjfry** » 19/01/04 10:07

ezechiel2517 ha scritto:Il ragionamento di PJ potrebbe funzionare se i numeri sono equamente distribuiti.
Ma se sono numeri molto simili allora la distribuzione dei decimanli non e' piu' uniforme!!

beh certo, per questo si parla di grandi numeri no?

? Algoritmo della funzione Round()

? Algoritmo della funzione Round()

Topic correlati a "? Algoritmo della funzione Round()":

Chi c’è in linea