Newsgroup: it.comp.java
Titolo: [NEWBIE] Java e SW Gestionale

Salve a tutti,
mi sono affacciato da pochissimo tempo al mondo Java per motivi di
studi universitari ,
nonostante abbia una certa esperienza nel mondo dell' informatica e
della programmazione (ho programmato in Pascal, C, C++ (a livello
didattico) e, per motivi professionali, sono 5 anni che programmo quasi
esclusivamente in Cobol (+SQL Embedded su DB2 AS/400).
Il perché del Cobol è presto detto: lavoro per una società che
sviluppa applicativi bancari e in questo ambiente non penso che
rappresentiamo un' eccezione, anzi.
Premesso questo mi sono trovato un po' spiazzato nel verificare l'
annoso problema di arrotondamento dei double quando i numeri sono
espressione di importi con una precisione prestabilita (ad esempio
importi in Euro), argomento che ho verificato essere stato trattato in
passato molto più volte.
Premetto che, conoscendo la rappresentazione dei double in virgola
mobile, capisco il perché di questi "problemi" e non dico che è un
bug di Java, perché è un problema di rappresentazione dei numeri in
virgola mobile.
Ho verificato che spesso nel newsgroup si fa riferimento alla classe
BigInteger come soluzione al problema, per normalizzare il risultato al
numero di cifre decimali necessario.
Ho anche fatto un paio di prove utilizzando questa classe, ma rimango
dubbioso sull' effettivo utilizzo su casi un po' più complessi. Non so
se qualcuno del newsgroup ha mai sviluppato applicazioni gestionali,
dove è fondamentale che 1+1 faccia sempre 2 e non 1.999999......
Il buon vecchio Cobol con i suoi evidenti limiti permette di definire,
oltre ai float, anche (forse sarebbe meglio dire soprattutto) variabili
con precisione FINITA (come SQL del resto) (per chi conosce cobol le
PIC s9(i)v9(d) con i=cifre intere e d= cifre decimali.
Proprio per questi miei dubbi sull' effettiva praticità del linguaggio
in certe situazioni mi chiedevo se Java può essere una piattaforma
"agile" per scrivere codice in ambito gestionale e se qualcuno ha avuto
esperienza in merito.
Saluti
Samuele

Ha !!!
un "cobolero" !!!
(giu' il cappello davanti al COBOL, io sono un vecchio "javaboy", ma il
98% del mio stipendio arriva dal COBOL che gira sotto il portale
java-XML superfico !!!)
Anche dove lavoro piu' d'uno ha sbattuto sugli arrotondamenti con i
float (e c'e' un decimale ridicolo tipo 0.7 che proprio non ne vuole
sapere di entrare in un float ...), al riguardo ti passo 2 info :
- i bigdecimal di Java 5
- 
http://www2.hursley.ibm.com/decimal/decimal.html
  (una vera miniera)
Il "tipo di Hursley" ha scritto anche un paio di papiri interessanti e
disponibili in PDF sul sito del "colorado software summit" (cfr Google)
.
Io pero' quando ho bisogno di operazioni decimali precise e "di corsa"
... controllo le definizioni delle colonne DB2, uso gli integer,
gestisco a manina i decimali e faccio un bel po' di test ...
Ciao,
    Davide Grandi
--
Ing. Davide Grandi
davide...@mclink.it

 esperienza in merito.
Se devo essere sincero finora non mi è mai capitato di dover usare 
BigDecimal per calcoli "monetari". Ciò che ho sempre fatto è trattare 
tutto come double (o float nel caso) senza *mai* arrotondare/troncare 
nulla (e ovviamente facendo attenzione alle trappole delle divisioni e 
moltiplicazioni) salvo nel momento in cui devo tirar fuori la cifra a 
video, in cui mi avvalgo di un DecimalFormat col numero di decimali 
desiderato. Carta e penna alla mano finora funziona tutto :)
Per esempio:
     double d = 1.9999999;
     DecimalFormat ds = new DecimalFormat("###,###.00");
     System.out.println(ds.format(d));
Risultato:
     2.00
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.htm


Beh, non credo che si possa contare sull'arrotondamento fatto da
DecimalFormat.
Nulla vieta che in una nuova versione della VM le cose possano
cambiare.
Per me double e float vanno usati solo dove gli arrotondamenti non sono
importanti (e non ci sono test del tipo x == 0 che falliscono se x vale
1.9999999)
Ad ogni modo, e qui entro nel merito, ho lavorato anche io per 6 anni
su Cobol+Sql e quindi so di che parli. Ti posso dire che la classe
BigDecimal assolve appieno al suo compito (compreso il fatto che gli
puoi dare un fattore di scala e il tipo di arrotondamento).
Unico neo, scrivere le 4 operazioni fondamentali è più "palloso" che
usare i simboli
Ad es, w = (x+y)/z si traduce in
BigDecimal w = (x.add(y)).divide(z)
Semmai, dove si deve fare attenzione è nel parsing dell'input utente.
Il parse di DecimalFormat non è il massimo, nel senso che prende
eccezione solo se nella stringa ci sono caratteri diversi dai
DecimalFormatSymbols associati al tuo NumberFormat. Già per esempio se
gli dai in pasto un "100,88,77" lui traduce il numero "come gli pare"

pio...@inwind.it
 wrote:
[...]
Concordo con le tue osservazioni su BigDecimal, pensando soprattutto 
alle implicazioni del suo utilizzo sugli arrotondamenti intermedi in 
campo contabile.
Non ho invece informazioni in merito all'eventuale inattendibilità 
dell'arrotondamento effettuato da DecimalFormat.
Sui javadoc dice che utilizza la politica ROUND_HALF_EVEN; mi pare tutto 
ok...
