Quale tipo di dati dovrei usare per la valuta di gioco?

In un semplice gioco di simulazione aziendale (integrato in Java + Slick2D), la quantità attuale di denaro di un giocatore deve essere archiviata come floato into, o qualcos'altro?

Nel mio caso d'uso, la maggior parte delle transazioni utilizzerà centesimi ($ 0,50, $ 1,20, ecc.) E saranno coinvolti semplici calcoli dei tassi di interesse.

Ho visto persone che dicevano che non dovresti mai usare floatper la valuta, così come persone che dicevano che non dovresti mai usare intper la valuta. Sento che dovrei usare inte arrotondare tutti i calcoli percentuali necessari. Cosa dovrei usare?

Puoi usare inte considerare tutto in centesimi. $ 1,20 sono solo 120 centesimi. A display, inserisci il decimale in cui appartiene.

I calcoli degli interessi verrebbero semplicemente troncati o arrotondati per eccesso. Così

newAmt = round( 120 cents * 1.04 ) = round( 124.8 ) = 125 cents

In questo modo non hai decimali disordinati che restano sempre in giro. Potresti diventare ricco aggiungendo i soldi non contabilizzati (a causa di arrotondamenti) nel tuo conto bancario

Ok, salterò dentro.

Il mio consiglio: è un gioco. Vacci piano e usa double.

Ecco la mia logica:

• floatha un problema di precisione che appare quando si aggiungono unità a milioni, quindi anche se potrebbe essere benigno, eviterei quel tipo. doubleinizia solo ad avere problemi intorno ai quintilioni (un miliardo di miliardi).
• Dato che avrai tassi di interesse, avrai comunque bisogno della precisione teorica infinita: con i tassi di interesse del 4%, $ 100 diventeranno $ 104, quindi $ 108,16, quindi $ 112,4864, ecc. Questo rende inte longinutile perché non sai dove fermarti. i decimali.
• BigDecimalti darà una precisione arbitraria, ma diventerà dolorosamente lento, a meno che tu non ne blocchi la precisione in qualche momento. Quali sono le regole di arrotondamento? Come scegli dove fermarti? Vale la pena avere più bit di precisione di double? Io credo di no.

Il motivo dell'aritmetica a virgola fissa viene utilizzato nelle applicazioni finanziarie perché sono deterministiche. Le regole di arrotondamento sono perfettamente definite, a volte dalla legge, e devono essere rigorosamente applicate, ma l'arrotondamento avviene ancora ad un certo punto. Qualsiasi argomento a favore di un determinato tipo basato sulla precisione è probabilmente falso. Tutti i tipi hanno problemi di precisione con il tipo di calcoli che farai.

Esempi pratici

Vedo alcuni commenti che sostengono cose sull'arrotondamento o sulla precisione con cui non sono d'accordo. Ecco alcuni esempi aggiuntivi per illustrare cosa intendo.

Memorizzazione : se l'unità base è il centesimo, probabilmente si vorrà arrotondare al centesimo più vicino quando si memorizzano i valori:

void SetValue(double v) { m_value = round(v * 100.0) / 100.0; }

Non avrai assolutamente problemi di arrotondamento quando adotti questo metodo che non avresti anche con un tipo intero.

Recupero : tutti i calcoli possono essere eseguiti direttamente sui valori doppi, senza conversioni:

double value = data.GetValue();
value = value / 3.0 * 12.0;
[...]
data.SetValue(value);

Si noti che il codice sopra riportato non funziona se si sostituisce doublecon int64_t: ci sarà una conversione implicita in double, quindi troncamento in int64_t, con una possibile perdita di information.data.GetValue ()

Confronto : i confronti sono l'unica cosa da fare con i tipi a virgola mobile. Suggerisco di utilizzare un metodo di confronto come questo:

/* Are values equal to a tenth of a cent? */
bool AreCurrencyValuesEqual(double a, double b) { return abs(a - b) < 0.001; }

Equità arrotondante

Supponiamo di avere $ 9,99 nel conto con il 4% di interesse. Quanto dovrebbe guadagnare il giocatore? Con l'arrotondamento intero ottieni $ 0,03; con arrotondamenti in virgola mobile ottieni $ 0,04. Credo che quest'ultimo sia più giusto.

I tipi a virgola mobile in Java ( float, double) non sono una buona rappresentazione per le valute a causa di uno dei motivi principali: c'è un errore macchina nell'arrotondamento. Anche se un semplice calcolo restituisce un numero intero come 12.0/2(6.0), il punto mobile potrebbe erroneamente arrotondarlo (a causa della rappresentazione specifica di questi tipi in memoria) come 6.0000000000001o 5.999999999999998o simile. Questo è il risultato dell'arrotondamento specifico della macchina che si verifica nel processore ed è univoco per il computer che lo ha calcolato. Di solito, raramente è un problema operare con questi valori, poiché l'errore è piuttosto negligente, ma è un problema mostrarlo all'utente.

Una possibile soluzione a questo sarebbe quella di utilizzare implementazioni personalizzate di tipo di dati in virgola mobile, come BigDecimal. Supporta migliori meccanismi di calcolo che almeno isolano gli errori di arrotondamento per non essere specifici della macchina, ma sono più lenti in termini di prestazioni.

Se hai bisogno di alta produttività, è meglio attenersi ai tipi semplici. Nel caso in cui tu operi con dati finanziari importanti e ogni centesimo è importante (come un'applicazione Forex o un gioco da casinò), ti consiglierei di usare Longo long. Longti permetterebbe di gestire grandi quantità e buona precisione. Supponiamo solo che tu abbia bisogno, diciamo, di 4 cifre dopo il punto decimale, tutto ciò che serve è moltiplicare l'importo per 10000. Avendo esperienza nello sviluppo di giochi da casinò online, ho visto Longessere spesso usato per rappresentare il denaro in centesimi . Nelle applicazioni Forex, la precisione è più importante, quindi avrai bisogno di un moltiplicatore maggiore - tuttavia, i numeri interi sono privi di problemi di arrotondamento della macchina (ovviamente l'arrotondamento manuale come in 3/2 dovresti gestire te stesso).

Un'opzione accettabile sarebbe quella di utilizzare i tipi standard a virgola mobile Floate Double, se le prestazioni sono più importanti della precisione al centesimo del centesimo. Quindi, nella logica di visualizzazione, tutto ciò che serve è utilizzare una formattazione predefinita , in modo che la bruttezza del potenziale arrotondamento della macchina non arrivi all'utente.

Per i giochi su piccola scala e in cui la velocità del processo, la memoria è un problema importante (a causa della precisione o del lavoro con il coprocessore matematico può rallentare dolorosamente), il doppio è sufficiente.

Ma per i giochi su larga scala (ad esempio, i giochi social) e dove la velocità del processo, la memoria non è limitata, BigDecimal è migliore. Perché qui,

• int o long per calcoli monetari.
• float e double non possono rappresentare accuratamente la maggior parte dei 10 numeri reali di base.

risorse:

Da https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency

Perché float e double non possono rappresentare accuratamente la maggior parte dei 10 numeri reali di base.

Ecco come funziona un numero in virgola mobile IEEE-754: dedica un po 'per il segno, alcuni bit per memorizzare un esponente e il resto per la frazione effettiva. Questo porta a numeri rappresentati in una forma simile a 1,45 * 10 ^ 4; tranne che invece che la base è 10, sono due.

Tutti i numeri decimali reali possono essere visti, infatti, come frazioni esatte di una potenza di dieci. Ad esempio, 10.45 è davvero 1045/10 ^ 2. E proprio come alcune frazioni non possono essere rappresentate esattamente come una frazione di una potenza di dieci (viene in mente 1/3), alcune di esse non possono nemmeno essere rappresentate esattamente come una frazione di una potenza di due. Come semplice esempio, semplicemente non è possibile memorizzare 0,1 all'interno di una variabile in virgola mobile. Otterrai il valore rappresentabile più vicino, che è qualcosa come 0,0999999999999999996 e il software lo arrotonderà a 0,1 quando lo visualizza.

Tuttavia, man mano che esegui più aggiunte, sottrazioni, moltiplicazioni e divisioni su numeri inesatti, perderai sempre più precisione man mano che i piccoli errori si sommano. Ciò rende i galleggianti e i doppi inadeguati per gestire il denaro, dove è richiesta la massima precisione.

Da Bloch, J., Effective Java, 2nd ed, Item 48:

The float and double types are particularly ill-suited for 

calcoli monetari perché è impossibile rappresentare 0,1 (o qualsiasi altro potere negativo di dieci) come float o double esattamente.

For example, suppose you have $1.03 and you spend 42c. How much money do you have left?

System.out.println(1.03 - .42);

prints out 0.6100000000000001.

The right way to solve this problem is to use BigDecimal, 

int o long per calcoli monetari.

Dai anche un'occhiata a

• https://stackoverflow.com/questions/4806944/what-the-difference-between-the-float-and-integer-data-type-when-the-size-is-sam

Vuoi conservare la tua valuta longe calcolare la tua valuta double, almeno come backup. Volete che tutte le transazioni avvengano come long.

Il motivo per cui vuoi conservare la tua valuta longè che non vuoi perdere alcuna valuta.

Supponiamo che tu usi un double, e non hai soldi. Qualcuno ti dà tre dimes, e poi li riprende.

You:       0.1+0.1+0.1-0.1-0.1-0.1 = 2.7755575615628914E-17

Beh, non è così bello. Forse qualcuno con $ 10 vuole regalare la propria fortuna dandoti prima tre dimes e poi dando $ 9,70 a qualcun altro.

Them: 10.0-0.1-0.1-0.1-9.7 = 1.7763568394002505E-15

E poi restituisci loro le dimes:

Them: ...+0.1+0.1+0.1 = 0.3000000000000018

Questo è solo rotto.

Ora, usiamo un lungo e terremo traccia dei decimi di centesimi (quindi 1 = $ 0,001). Diamo a tutti sul pianeta un miliardo, centododici milioni, settantacinquemila, centoquarantatre dollari:

Us: 7000000000L*1112075143000L = 1 894 569 218 048

Aspetta, possiamo dare a tutti oltre un miliardo di dollari e spendere solo poco più di due? L'overflow è un disastro qui.

Quindi, ogni volta che stai calcolando una somma di denaro da trasferire, usa doublee Math.roundper ottenere un long. Quindi aggiusta i saldi (aggiungi e sottrai entrambi gli account) usando long.

La tua economia non perderà e raggiungerà i quadrilioni di dollari.

Esistono problemi più delicati, ad esempio cosa fai se effettui venti pagamenti? *, Ma questo dovrebbe iniziare.

^{* Calcola quale è un pagamento, arrotondato a long; quindi moltiplicare per 20.0e verificare che sia nell'intervallo; in tal caso, moltiplichi il pagamento 20Lper ottenere l'importo dedotto dal tuo saldo. In generale, tutte le transazioni devono essere gestite come long, quindi è davvero necessario riassumere tutte le singole transazioni; puoi moltiplicare come scorciatoia, ma devi assicurarti di non aggiungere errori di arrotondamento e di non traboccare, il che significa che devi verificare con doubleprima di fare il calcolo reale con long.}

Vorrei dire che qualsiasi valore che può essere visualizzato per l'utente dovrebbe essere quasi sempre un numero intero. Il denaro è solo l'esempio più importante di questo. Infliggere 225 danni quattro volte a un mostro con 900 HP e scoprire che ha ancora 1 HP sottrarrà l'esperienza tanto quanto scoprire che sei una frazione invisibile di un centesimo a corto di offrire qualcosa.

Dal punto di vista tecnico, penso che valga la pena notare che non è necessario tornare ai float per fare cose avanzate come l'interesse. Finché si ha abbastanza spazio per la testa nel tipo intero prescelto, una moltiplicazione e una divisione sostituirà una moltiplicazione per un numero decimale, ad esempio per aggiungere il 4%, arrotondato per difetto:

number=(number*104)/100

Per aggiungere il 4%, arrotondato da convenzioni standard:

number=(number*104+50)/100

Nessuna inesattezza in virgola mobile qui, l'arrotondamento si divide sempre esattamente sul .5segno.

Modifica, la vera domanda:

Vedendo come il dibattito è andato comincio a pensare che delineando quello che la questione è tutto può essere più utile di un semplice int/ floatrisposta. Al centro della domanda non si tratta di tipi di dati, si tratta di prendere il controllo dei dettagli di un programma.

L'uso di un numero intero per rappresentare un valore non intero impone al programmatore di gestire i dettagli dell'implementazione. "Quale precisione usare?" e "Che modo di arrotondare?" sono domande a cui è necessario rispondere esplicitamente.

Un float d'altra parte non costringe il programmatore a preoccuparsi, fa già praticamente ciò che ci si aspetterebbe. Ma poiché un galleggiante non è una precisione infinita, si verificherà un arrotondamento e tale arrotondamento è piuttosto imprevedibile.

Cosa succede in un uso float e vuoi prendere il controllo dell'arrotondamento? Risulta essere quasi impossibile. L'unico modo per rendere veramente prevedibile un float è utilizzare solo valori che possono essere rappresentati in interi 2^ns. Ma quella costruzione rende i galleggianti piuttosto difficili da usare.

Quindi la risposta alla semplice domanda è: se vuoi prendere il controllo, usa numeri interi, altrimenti usa float.

Ma la domanda in discussione è solo un'altra forma della domanda: vuoi prendere il controllo?

Anche se è "solo un gioco", userei Money Pattern di Martin Fowler, supportato da molto tempo.

Perché?

Localizzazione (L10n): Usando quel modello puoi localizzare facilmente la valuta del tuo gioco. Pensa ai vecchi giochi di magnati come "Transport Tycoon". Consentono facilmente al giocatore di cambiare la valuta di gioco (es. Dalla sterlina britannica al dollaro USA) per soddisfare la valuta del mondo reale.

E

Il tipo di dati lungo è un intero di complemento a due bit con segno a 64 bit. Ha un valore minimo di -9.223.372.036.854.775.808 e un valore massimo di 9.223.372.036.854.775.807 (incluso) ( Java Tutorials )

Ciò significa che puoi immagazzinare 9.000 volte l' attuale offerta di moneta americana USA (~ 10.000 miliardi di dollari). Dandoti abbastanza spazio per usare qualsiasi altra valuta mondiale, probabilmente, anche quelli che avevano / ha l'iperinflazione (Se curioso, vedi l'inflazione tedesca post-prima guerra mondiale , dove 1 chilo di pane era di 3.000.000.000 di marchi)

Lungo è facile da perseverare, molto veloce e dovrebbe darti abbastanza spazio per fare tutti i calcoli degli interessi usando solo l'aritmetica intera, la risposta di eBusiness fornisce una spiegazione su come farlo.

Quanto lavoro vuoi dedicare a questo? Quanto è importante l'accuratezza? Ti interessa tracciare gli errori frazionari che si verificano con l'arrotondamento e l'imprecisione della rappresentazione dei numeri decimali in un sistema binario?

Alla fine tendo a dedicare un po 'più di tempo alla codifica e all'implementazione di unit test per "casi angolari" e noti casi problematici - quindi penserei in termini di un BigInteger modificato che comprende quantità arbitrariamente grandi e mantiene i bit frazionari con un BigDecimal o una parte BigRational (due BigInteger, una per il denominatore e un'altra per il numeratore) - e include il codice per mantenere la parte frazionaria una frazione effettiva aggiungendo (forse solo periodicamente) qualsiasi parte non frazionaria al BigInteger principale. Quindi terrei internamente traccia di tutto in centesimi solo per mantenere le parti frazionarie fuori dai calcoli della GUI.

Probabilmente un modo complesso per un gioco (semplice) - ma buono per una libreria pubblicata come open source! Avrei solo bisogno di capire come mantenere buone le prestazioni quando si affrontano i bit frazionari ...

Certamente non galleggiare. Con solo 7 cifre, hai solo precisione come:

12.345,67 123.456,7x

Quindi vedi, già con 10 ^ 5 dollari, stai perdendo la cognizione. double è utilizzabile per scopi di gioco, non nella vita reale a causa di problemi di precisione.

Ma long (e con questo intendo 64 bit, o long long in C ++) non è sufficiente per tracciare le transazioni e sommarle. È sufficiente mantenere le partecipazioni nette di qualsiasi società, ma tutte le transazioni per un anno potrebbero traboccare. Dipende da quanto è grande il tuo "mondo" finanziario nel gioco.

Un'altra soluzione che aggiungerò qui è quella di fare una classe di soldi. La classe sarebbe qualcosa del genere (potrebbe anche essere semplicemente una struttura).

class Money
{
     string currencyType; //the type of currency example USD could be an enum as well
     bool isNegativeValue;
     unsigned long int wholeUnits;
     unsigned short int partialUnits;
}

Ciò consentirebbe di rappresentare i centesimi in questo caso come numeri interi e l'intero dollaro come numero intero. Dato che hai un flag separato per essere negativo, puoi usare numeri interi senza segno per i tuoi valori che raddoppiano la quantità possibile (puoi anche scrivere una classe numerica che applica questa idea ai numeri per ottenere VERAMENTE numeri grandi). Tutto quello che dovresti fare è sovraccaricare gli operatori matematici e potresti usarlo come qualsiasi vecchio tipo di dati. Occupa più memoria, ma espande davvero i limiti di valore.

Questo potrebbe essere ulteriormente ampliato per includere elementi come il numero di unità parziali per unità intere in modo da poter avere valute che si suddividono su qualcosa di diverso da 100 unità secondarie, centesimi in questo caso, per dollaro. Ad esempio, potresti avere 125 floop che formano un flooper.

Modificare:

Espanderò l'idea che potresti anche avere una sorta di tabella di consultazione, alla quale la classe monetaria può accedere in modo da fornire un tasso di cambio per la sua valuta rispetto a tutte le altre valute. È possibile incorporarlo nelle funzioni di sovraccarico dell'operatore. Pertanto, se provi automaticamente ad aggiungere 4 USD a 4 sterline inglesi, ti darebbero automaticamente 6,6 sterline (al momento della scrittura).

Come menzionato in uno dei commenti sulla tua domanda originale, questo problema è stato trattato su StackExchange: https://stackoverflow.com/questions/8148684/what-is-the-best-data-type-to-use-for- denaro-in-java-app

Fondamentalmente, i tipi in virgola mobile non dovrebbero mai essere usati per rappresentare valute, e come la maggior parte delle lingue Java ha un tipo più appropriato. La documentazione di Oracle sulle primitive suggerisce di usare BigDecimal .

Utilizzare la classe è il modo migliore. Puoi nascondere l'implementazione del tuo denaro, puoi cambiare il doppio / quello che vuoi in qualsiasi momento.

Esempio

class Money
{
    private long count;//Store here what ever you want in what type you want i suggest long or int
    //methods constructors etc.
    public String print()
    {
        return count/100.F; //convert this to string
    }
}

Nel tuo codice usare semplicemente getter è il modo migliore penso e puoi memorizzare metodi più utili.