Raddoppia i miei soldi: il mio framework usa i doppi per gli importi monetari

Question

Ho ereditato un progetto in cui gli importi monetari usano il doppio tipo.

Peggio ancora, il framework che utilizza e le classi proprie del framework utilizzano il doppio del denaro.

L'ORM del framework gestisce anche il recupero dei valori da (e archiviazione a) il database. Nel database i valori monetari sono di tipo numero (19, 7), ma l'ORM del framework li mappa in doppio.

A corto di bypassare completamente le classi framework e ORM, c'è qualcosa che posso fare per calcolare con precisione i valori monetari?

Modifica: sì, so che BigDecimal deve essere utilizzato. Il problema è che sono strettamente legato a un framework in cui, ad esempio, la classe framework.commerce.pricing.ItemPriceInfo ha membri double mRawTotalPrice; e doppio mListPrice. Il codice dell'applicazione della mia azienda si estende, ad esempio, a ItemPriceInfoClass.

Realisticamente, non posso dire alla mia azienda, "scarto di due anni di lavoro, e centinaia di migliaia di dollari spesi, basando il codice in questo quadro, a causa di errori di arrotondamento"

Answer 1

Se tollerabile, considera il tipo monetario come integrale. In altre parole, se lavori negli Stati Uniti, traccia i centesimi anziché i dollari, se i centesimi forniscono la granularità di cui hai bisogno. Le doppie possono rappresentare in modo accurato interi fino a a very large value (2^53) (nessun errore di arrotondamento fino a tale valore).

Ma in realtà, la cosa giusta da fare è bypassare completamente la struttura e utilizzare qualcosa di più ragionevole. Questo è un errore amatoriale da fare nel framework - chissà che altro c'è in agguato?

Answer 2

non ho visto Lei parla di refactoring. Penso che sia la tua migliore opzione qui. Invece di mettere insieme alcuni hack per far funzionare meglio le cose per ora, perché non risolverlo nel modo giusto?

Ecco alcune informazioni su double vs BigDecimal. Questo post suggerisce di utilizzare BigDecimal anche se è più lento.

Answer 3

Beh, non c'è bisogno che molte opzioni in realtà:

È possibile refactoring del progetto per utilizzare ad esempio BigDecimal (o qualcosa che meglio si adatta alle sue esigenze) per rappresentare il denaro.

Prestare estrema attenzione al trabocco/underflow e alla perdita di precisione, il che significa aggiungere tonnellate di controlli e rielaborare in modo non necessario una parte ancora maggiore del sistema. Per non parlare di quanta ricerca sarebbe necessaria se si vuole farlo.

Tenere le cose come sono e spero che nessuno se ne accorga (è uno scherzo).

IMHO, la soluzione migliore sarebbe semplicemente refactoring questo fuori. Potrebbe essere un pesante refactoring, ma il male è già stato fatto e credo che dovrebbe essere la scelta migliore.

migliore, Vassil

P.S. Oh, puoi trattare i soldi come numeri interi (contando i centesimi), ma non sembra una buona idea se hai conversioni valutarie, calcolando interessi, ecc.

Answer 4

Un sacco di persone suggeriranno di usare BigDecimal e se non sai come usare l'arrotondamento nel tuo progetto, questo è quello che dovresti fare.

Se si sa come utilizzare correttamente l'arrotondamento decimale, utilizzare doppio. I suoi numerosi ordini di grandezza più veloci, molto più chiari e più semplici e quindi meno IMHO incline agli errori. Se usi dollari e centesimi (o hai bisogno di due cifre decimali), puoi ottenere un risultato accurato per valori fino a 70 trilioni di dollari.

Fondamentalmente, non si ottengono errori di arrotondamento se si corregge utilizzando l'arrotondamento appropriato.

BTW: Il pensiero di errori di arrotondamento colpisce il terrore nel cuore di molti sviluppatori, ma non sono errori casuali ed è possibile gestirli abbastanza facilmente.

MODIFICA: considerare questo semplice esempio di errore di arrotondamento.

double a = 100000000.01; 
    double b = 100000000.09; 
    System.out.println(a+b); // prints 2.0000000010000002E8 

Esistono diverse possibili strategie di arrotondamento. È possibile arrotondare il risultato durante la stampa/la visualizzazione. per esempio.

System.out.printf("%.2f%n", a+b); // prints 200000000.10 

o rotondo il risultato matematicamente

double c = a + b; 
    double r= (double)((long)(c * 100 + 0.5))/100; 
    System.out.println(r); // prints 2.000000001E8 

Nel mio caso, ho arrotondare il risultato quando si invia dal server (scrivendo a una presa di corrente e un file), ma usare la mia routine per evitare qualsiasi creazione di oggetti.

Una funzione di round più generale è la seguente, ma se è possibile utilizzare printf o DecimalFormat, può essere più semplice.

private static long TENS[] = new long[19]; static { 
    TENS[0] = 1; 
    for (int i = 1; i < TENS.length; i++) TENS[i] = 10 * TENS[i - 1]; 
} 

public static double round(double v, int precision) { 
    assert precision >= 0 && precision < TENS.length; 
    double unscaled = v * TENS[precision]; 
    assert unscaled > Long.MIN_VALUE && unscaled < Long.MAX_VALUE; 
    long unscaledLong = (long) (unscaled + (v < 0 ? -0.5 : 0.5)); 
    return (double) unscaledLong/TENS[precision]; 
} 

nota: è possibile utilizzare BigDecimal per eseguire l'arrotondamento finale. esp se avete bisogno di un metodo rotondo specifico.

Answer 5

Penso che questa situazione sia almeno minimamente recuperabile per il tuo codice. Ottieni il valore come doppio tramite il framework ORM. È quindi possibile convertirlo in BigDecimal utilizzando il metodo valueOf statico (vedere here per il motivo) prima di eseguire calcoli matematici su di esso e quindi riconvertirlo in double solo per memorizzarlo.

Poiché si stanno estendendo queste classi in ogni caso, è possibile aggiungere i getter per il valore doppio che li ottiene come BigDecimal quando è necessario.

Questo non può coprire il 100% dei casi (sarei particolarmente preoccupato di ciò che il driver ORM o JDBC sta facendo per convertire il doppio in un tipo numerico), ma è molto meglio che semplicemente fare i conti sui doppi grezzi.

Tuttavia, sono tutt'altro che convinto che questo approccio sia effettivamente più economico per l'azienda a lungo termine.