Newsgroup: it.comp.lang.vo-clipper
Titolo: Confronto di velocità

Cari amici, ho fatto un confronto in velocità dal quale è risultato che
la mia proposta è quasi quattro volte più veloce di quella di Diego
(mentre la ROUND() originale è oltre tre volte più veloce della mia...
:-( ). Naturalmente bisogna vedere quale di queste funziona bene...
EMG
PS. Quella di Davide non l'ho misurata in quanto si vede ad occhio che è
molto più lenta... :-)
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

:-( ). Naturalmente bisogna vedere quale di queste funziona bene...
quella che funziona meglio è senz'altro quella proposta da te.
Non ho trovato casi in cui fallisca (tranne quanto segue...)
Tra l'altro, oltre ad essere più veloce, è compatta, essenziale e
combina a meraviglia la STR() con la VAL().
Per quanto mi riguarda, soddisfa pienamente le mie esigenze.
Tutte le soluzioni sbagliano nel caso che vi sia una sequenza
consistente di 9 nella parte decimale.
Ad esempio, il numero 1.14999..., ormai diventato un "caso" (ma di cui
non conosciamo la reale incidenza nella pratica, come si chiedeva
Davide), dopo dodici 9 fa sbagliare la mia funzione, e dopo tredici 9
anche quella di Enrico.
Personalmente, penso che il risultato ottenuto sia comunque ottimo, e,
salva restando la possibilità che qualcuno trovi altre possibilità o
migliori l'esistente, più che soddisfacente.
Riporto, come chiesto da Enrico, un caso (ma ne avevo incontrati
parecchi) in cui la INT() restituisce un valore arrotondato.
Il caso che riporto è ancora quello dell' 1.1499... con quattordici 9,
ma sono pressochè certo che sia successo anche con numeri dove la
sequenza non era nè così lunga, nè composta da 9.
A := 1.11499999999999999
? INT( A * 1000 )  ===> 1150
Ora, essendo sabato, dopo una settimana passata a chiacchierare con i
clienti, a discutere con i colleghi, a girare di qua e di là, vi
saluto e vado a lavorare....
ciao

Enrico,
mi era sembrato di capire che il problema era quello di sostituire
in toto la "round" del clipper e quindi con un arrotondamento alla 308 cifra
decimale, numeri negativi, positivi ecc.
Che la percentuale di arrotondamento errato fosse uguale a zero.
La discussione vedo che e' passata alla percentuale di errori che si possono
verificare nel programma "TOT" e valutare se questa o quella soluzione sono
piu' opportune.
Per me senza dubbio quella con la soluzione EPS.
L'ultima tua versione non considera questi casi:
round2(1.1,2)
 
round2(1.11,3)
ecc.
Mario
-- 
Posted from 
ppp-62-10-143-125.dialup.tiscali.it
 [62.10.143.125] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ? INT( A * 1000 )  ===> 1150
Presto spiegato: prova a togliere la INT() e vedrai che ottieni lo
stesso risultato. Quindi la colpa non è della INT() ma di qualcosa che
sta più in basso.
EMG


 ecc.
Vero. Ma ho appena postato una soluzione che invece ne tiene conto.
Provala e fammi sapere. Tra l'altro potrebbe essere utile anche a voi
che utilizzate VO, o sbaglio?
EMG


 > ? INT( A * 1000 )  ===> 1150
non ne sono certo al 100%, ma mi sembra di aver capito che non č possibile
rappresentare in Clipper un numero che abbia piů di 16 cifre significative,
siano esse intere o decimali. In questo caso, A ne ha 18.
Provate a fare
? round( 1234567890.1234567890 , 10 ).
Ciao.
Davide.

 Per me senza dubbio quella con la soluzione EPS.
vorrei anch'io che la questione fosse in questi termini, ma non lo č.
La soluzione con l'EPS non funziona per numeri molto "probabili" tipo
128,015 ; 128,045 ; 128,075 ; 128,105 .
Io, a differenza di Enrico, mi acconterei anche di una soluzione non
"perfetta", ma che risolva tutti i casi che, in tema di Euro, possono
capitare, piů o meno frequentemente. Se si trova la soluzione perfetta
comunque, ben venga.
Ciao.
Davide.

 che utilizzate VO, o sbaglio?
Ho iniziato ad utilizzare V025 da un mese nonostante e' piu di un anno che
l'ho acquistato.
Comunque ho altri problemi ma non quelli dipendenti dalla Round()
Round(1.11499999999999,2) --> 1.11
Round(1.265,2)--> 1.27
Mario
-- 
Posted from 
ppp-62-10-140-215.dialup.tiscali.it
 [62.10.140.215] 


Scusate per nAgg intendevo il valore :
nAgg := 0.00000000001234567890123456789
Mario
-- 
Posted from 
ppp-62-10-137-46.dialup.tiscali.it
 [62.10.137.46] 


 Round(1.265,2)--> 1.27
Ah, mi sembrava di ricordare, da una prova riportata da qualcuno, che
anche VO avesse gli stessi problemi con la ROUND(). Comunque, visto che
la versione 5.3b del Clipper sembra non averne è anche comprensibile che
neanche VO li abbia.


 nAgg := 0.00000000001234567890123456789
Stesso discorso. Se fai un po' di test (che io ho appena fatto) ti
accorgi che non c'č verso di far trattare al Clipper piů di 16 cifre
significative.
