Jakiego typu danych powinienem użyć dla waluty w grze?

Czy w prostej grze symulacyjnej dla biznesu (wbudowanej w Javę + Slick2D) aktualna kwota pieniędzy gracza powinna być przechowywana w postaci innej floatkarty int?

W moim przypadku większość transakcji będzie korzystała z centów (0,50 USD, 1,20 USD itp.) I będą obejmowały proste obliczenia stopy procentowej.

Widziałem ludzi mówiących, że nigdy nie powinieneś używać floatwaluty, a także ludzi, którzy twierdzą, że nigdy nie powinieneś używać intwaluty. Czuję, że powinienem zastosować inti zaokrąglić wszelkie niezbędne obliczenia procentowe. Czego powinienem użyć?

Możesz użyć inti rozważyć wszystko w centach. 1,20 USD to zaledwie 120 centów. Na wyświetlaczu wstawiasz przecinek tam, gdzie należy.

Obliczenia odsetek byłyby po prostu obcięte lub zaokrąglone w górę. Więc

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

W ten sposób nie będziesz mieć bałaganu po przecinku. Możesz wzbogacić się, dodając do swojego konta bankowego niezliczone pieniądze (z powodu zaokrągleń)

Okej, wskoczę.

Moja rada: to gra. Uspokój się i użyj double.

Oto moje uzasadnienie:

• floatma problem z precyzją, który pojawia się przy dodawaniu jednostek do milionów, więc chociaż może być łagodny, unikałbym tego typu. doublezaczyna się problemy z kwintillonami (miliard miliardów).
• Ponieważ będziesz mieć stopy procentowe, i tak będziesz potrzebować teoretycznej nieskończonej precyzji: przy stopach procentowych 4%, 100 USD zmieni się na 104, następnie 108,16 USD, a następnie 112,4864 itd. To czyni inti jest longbezużyteczne, ponieważ nie wiesz, gdzie się zatrzymać miejsca dziesiętne.
• BigDecimalda ci dowolną precyzję, ale stanie się boleśnie powolny, chyba że kiedyś dokonasz precyzji. Jakie są zasady zaokrąglania? Jak wybrać, gdzie się zatrzymać? Czy warto mieć więcej precyzyjnych bitów niż double? Nie wierzę.

Powodem stosowania arytmetyki punktu stałego w aplikacjach finansowych jest to, że są deterministyczne. Reguły zaokrąglania są doskonale zdefiniowane, czasem przez prawo, i muszą być ściśle stosowane, ale w pewnym momencie nadal występuje zaokrąglanie . Każdy argument przemawiający za danym typem opartym na precyzji jest prawdopodobnie fałszywy. Wszystkie typy mają problemy z precyzją w rodzaju obliczeń, które zamierzasz wykonać.

Praktyczne przykłady

Widzę sporo komentarzy twierdzących, że nie zgadzam się z zaokrągleniem lub precyzją. Oto kilka dodatkowych przykładów ilustrujących to, co mam na myśli.

Przechowywanie : jeśli jednostką podstawową jest cent, prawdopodobnie będziesz chciał zaokrąglić do najbliższego centa podczas przechowywania wartości:

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

Przy zastosowaniu tej metody nie będziesz mieć absolutnie żadnych problemów z zaokrąglaniem, których nie miałbyś również w przypadku liczb całkowitych.

Pobieranie : wszystkie obliczenia można wykonać bezpośrednio na podwójnych wartościach, bez konwersji:

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

Zauważ, że powyższy kod nie działa, jeśli zastąpi doublesię int64_t: nie będzie niejawna konwersja double, a następnie obcięcie do int64_t, z możliwością utraty information.data.GetValue ()

Porównywanie : porównania są jedną rzeczą, którą należy uzyskać w przypadku typów zmiennoprzecinkowych. Sugeruję użycie metody porównania, takiej jak ta:

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

Zaokrąglanie uczciwości

Załóżmy, że masz na koncie 9,99 USD z 4% odsetkami. Ile powinien zarobić gracz? Zaokrąglając liczbę całkowitą, otrzymujesz 0,03 $; zaokrąglanie zmiennoprzecinkowe daje 0,04 USD. Uważam, że to drugie jest bardziej sprawiedliwe.

Typy zmiennoprzecinkowe w Javie ( float, double) nie są dobrą reprezentacją walut z jednego głównego powodu - występuje błąd maszynowy w zaokrąglaniu. Nawet jeśli to prosta kalkulacja zwraca liczbę całkowitą - jak 12.0/2(6,0), przy czym zmiennoprzecinkowe może błędnie runda to (z powodu tho konkretnej reprezentacji tych typów pamięci) jako 6.0000000000001lub 5.999999999999998lub podobny. Jest to wynik specyficznego zaokrąglenia maszyny występującego w procesorze i jest unikalny dla komputera, który go obliczył. Zwykle rzadko jest problem z obsługą tych wartości, ponieważ błąd jest dość zaniedbany, ale wyświetlenie go użytkownikowi nie jest łatwe.

Możliwym rozwiązaniem tego byłoby użycie niestandardowych implementacji typu danych zmiennoprzecinkowych, takich jak BigDecimal. Obsługuje lepsze mechanizmy obliczeniowe, które przynajmniej izolują błędy zaokrąglania, które nie są specyficzne dla maszyny, ale są wolniejsze pod względem wydajności.

Jeśli potrzebujesz wysokiej wydajności, lepiej trzymaj się prostych typów. Jeśli operujesz ważnymi danymi finansowymi , a każdy cent jest ważny (np. Aplikacja Forex lub gra kasynowa), polecam użyć Longlub long. Longpozwoli ci obsługiwać duże ilości i dobrą precyzję. Załóżmy, że potrzebujesz, powiedzmy, 4 cyfr po przecinku, wystarczy pomnożyć tę kwotę przez 10000. Mając doświadczenie w opracowywaniu gier kasynowych online, widziałem, Longże często jestem używany do przedstawiania pieniędzy w centach . W aplikacjach Forex dokładność jest ważniejsza, więc potrzebujesz większego mnożnika - wciąż liczby całkowite są wolne od problemów z zaokrąglaniem maszyny (oczywiście zaokrąglania ręcznego, jak w 3/2, powinieneś sobie poradzić).

Dopuszczalną opcją byłoby użycie standardowych typów zmiennoprzecinkowych - Floata Doublejeśli wydajność jest ważniejsza niż dokładność do setnych centa. Następnie, zgodnie z logiką wyświetlania, wystarczy użyć predefiniowanego formatowania , aby brzydota potencjalnego zaokrąglenia maszyny nie dotarła do użytkownika.

W przypadku gier na małą skalę i tam, gdzie szybkość procesu ważna jest pamięć (ze względu na precyzję lub praca z koprocesorem matematycznym może boleśnie spowolnić), wystarczy podwójna .

Ale w przypadku gier na dużą skalę (na przykład gier społecznościowych) i tam, gdzie szybkość procesu, pamięć nie jest ograniczona, BigDecimal jest lepszy. Ponieważ tutaj

• int lub długo dla obliczeń pieniężnych.
• liczba zmiennoprzecinkowa i liczba podwójna nie mogą dokładnie reprezentować większości 10 liczb rzeczywistych.

Zasoby:

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

Ponieważ liczby zmiennoprzecinkowe i liczby podwójne nie mogą dokładnie reprezentować większości 10 liczb rzeczywistych podstawowych.

Tak działa liczba zmiennoprzecinkowa IEEE-754: poświęca ona trochę znakowi, kilka bitów do przechowywania wykładnika, a resztę dla rzeczywistej części. Prowadzi to do reprezentacji liczb w formie podobnej do 1,45 * 10 ^ 4; z wyjątkiem tego, że zamiast podstawy 10, to dwa.

Wszystkie rzeczywiste liczby dziesiętne mogą być postrzegane jako dokładne ułamki potęgi dziesięciu. Na przykład 10,45 to naprawdę 1045/10 2. I tak jak niektóre ułamki nie mogą być reprezentowane dokładnie jako ułamek potęgi dziesięciu (przychodzi na myśl 1/3), niektóre z nich nie mogą być przedstawiane dokładnie jako ułamek potęgi dwóch. Jako prosty przykład po prostu nie możesz przechowywać 0.1 w zmiennej zmiennoprzecinkowej. Otrzymasz najbliższą możliwą do przedstawienia wartość, która jest jak 0,099999999999999999996, a oprogramowanie zaokrągli ją do 0,1 podczas wyświetlania.

Jednak w miarę wykonywania kolejnych dodań, odejmowań, mnożenia i podziałów na niedokładnych liczbach tracisz coraz większą precyzję w miarę sumowania się drobnych błędów. To sprawia, że ​​liczba zmiennoprzecinkowa i liczba podwójna są nieodpowiednie do radzenia sobie z pieniędzmi, gdzie wymagana jest idealna dokładność.

Z Bloch, J., Effective Java, wyd. 2, pozycja 48:

The float and double types are particularly ill-suited for 

obliczenia pieniężne, ponieważ niemożliwe jest przedstawienie 0,1 (lub jakiejkolwiek innej ujemnej potęgi dziesięciu) jako liczby zmiennoprzecinkowej lub podwójnej.

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 lub długo dla obliczeń pieniężnych.

Zobacz także

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

Aby zapisać swoją walutę longi obliczyć swoją walutę double, przynajmniej jako zapasową. Chcesz, aby wszystkie transakcje odbywały się jako long.

Powodem, dla którego chcesz przechowywać swoją walutę, longjest to, że nie chcesz stracić żadnej waluty.

Załóżmy, że używasz doublei nie masz pieniędzy. Ktoś daje ci trzy dziesięciocentówki, a następnie bierze je z powrotem.

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

Cóż, to nie jest takie fajne. Może ktoś z 10 $ chce przekazać swoją fortunę, najpierw dając ci trzy dziesięciocentówki, a następnie 9,70 $ komuś innemu.

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

A potem oddajesz im dziesięciocentówki:

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

To jest po prostu zepsute.

Teraz użyjmy długiego, a my będziemy śledzić dziesiąte centy (czyli 1 = 0,001 $). Dajmy każdemu na świecie miliard sto dwanaście milionów siedemdziesiąt pięć tysięcy sto czterdzieści trzy dolary:

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

Um, czekaj, możemy dać każdemu ponad miliard dolarów i wydać tylko nieco ponad dwa? Przepełnienie jest tutaj katastrofą.

Tak więc, ilekroć obliczasz kwotę, którą chcesz przelać, użyj jej doublei Math.roundzdobądź long. Następnie napraw salda (dodaj i odejmij oba konta) za pomocą long.

Twoja gospodarka nie wycieknie i zwiększy się do miliardów dolarów.

Są trudniejsze problemy - na przykład, co robisz, jeśli dokonujesz dwudziestu płatności? * - ale to powinno zacząć.

^{* Obliczasz, co to jest jedna płatność, w zaokrągleniu do long; następnie pomnóż przez 20.0i sprawdź, czy jest w zasięgu; jeśli tak, pomnóż płatność przez, 20Laby uzyskać kwotę potrąconą z salda. Zasadniczo wszystkie transakcje muszą być obsługiwane jako long, więc naprawdę trzeba podsumować wszystkie poszczególne transakcje; możesz pomnożyć jako skrót, ale musisz upewnić się, że nie dodajesz błędów zaokrąglania i nie przepełniasz, co oznacza, że ​​musisz sprawdzić doubleprzed wykonaniem prawdziwych obliczeń long.}

Chciałbym powiedzieć, że każda wartość, która może być wyświetlana użytkownikowi, prawie zawsze powinna być liczbą całkowitą. Pieniądze są tylko najbardziej znanym tego przykładem. Zadanie potworowi 225 obrażeń czterokrotnie 225 i stwierdzenie, że pozostało mu jeszcze 1 PW, odejmie od doświadczenia tak samo, jak stwierdzenie, że jesteś niewidzialnym ułamkiem grosza, który czegoś nie daje.

Z technicznego punktu widzenia warto zauważyć, że nie trzeba wracać do pływaków, aby robić zaawansowane rzeczy, takie jak zainteresowanie. Tak długo, jak masz wystarczającą ilość miejsca w wybranym typie liczb całkowitych, mnożenie i dzielenie będą oznaczać mnożenie przez liczbę dziesiętną, na przykład, aby dodać 4%, w zaokrągleniu w dół:

number=(number*104)/100

Aby dodać 4%, w zaokrągleniu do standardowych konwencji:

number=(number*104+50)/100

Nie ma tu niedokładności punktu zmiennoprzecinkowego, zaokrąglenie zawsze dzieli się dokładnie na .5znaku.

Edytuj prawdziwe pytanie:

Widząc, jak debata upadł zacznę myśleć, że przedstawiając to, co jest pytanie o może być bardziej przydatne niż zwykły int/ floatodpowiedź. U podstaw pytania nie chodzi o typy danych, lecz o przejęcie kontroli nad szczegółami programu.

Użycie liczby całkowitej do przedstawienia wartości niecałkowitej zmusza programistę do zajęcia się szczegółami implementacji. „Jakiej precyzji użyć?” i „W jaki sposób zaokrąglić?” są pytania, na które należy udzielić wyraźnej odpowiedzi.

Z drugiej strony liczba zmiennoprzecinkowa nie zmusza programisty do zmartwień, robi już prawie wszystko, czego można by oczekiwać. Ponieważ jednak liczba zmiennoprzecinkowa nie jest nieskończoną precyzją, nastąpi pewne zaokrąglenie, a to zaokrąglenie jest dość nieprzewidywalne.

Co dzieje się przy jednym użyciu zmiennoprzecinkowych i chcesz przejąć kontrolę nad zaokrąglaniem? Okazuje się, że jest prawie niemożliwe. Jedynym sposobem, aby zmiennoprzecinkowe było naprawdę przewidywalne, jest użycie tylko wartości, które mogą być reprezentowane w całych 2^nliterach. Ale ta konstrukcja sprawia, że ​​spławiki są dość trudne w użyciu.

Tak więc odpowiedź na proste pytanie brzmi: jeśli chcesz przejąć kontrolę, użyj liczb całkowitych, jeśli nie, użyj liczb zmiennoprzecinkowych.

Ale omawiane pytanie jest tylko inną formą pytania: czy chcesz przejąć kontrolę?

Nawet jeśli to „tylko gra”, użyłbym Money Pattern od Martina Fowlera, popartego długim.

Dlaczego?

Lokalizacja (L10n): Za pomocą tego wzoru możesz łatwo zlokalizować swoją walutę gry. Pomyśl o starych grach potentata, takich jak „Transport Tycoon”. Pozwalają graczowi łatwo zmienić walutę w grze (np. Z funta brytyjskiego na dolara amerykańskiego), aby spełnić warunki rzeczywistej waluty świata.

I

Długi typ danych jest liczbą całkowitą z dopełnieniem dwójki ze znakiem 64-bitowym. Ma minimalną wartość -9 223 372,036,854,775,808 i maksymalną wartość 9 223 372,036,854,775,807 (włącznie) ( samouczki Java )

Oznacza to, że możesz przechowywać 9 000 razy bieżącą podaż pieniądza M2 w USA (~ 10 000 miliardów dolarów). Dając ci wystarczająco dużo miejsca na użycie dowolnej innej światowej waluty, prawdopodobnie nawet tych, którzy mieli / mają hiperinflację (jeśli jesteś ciekawy, zobacz niemiecką inflację po I wojnie światowej , gdzie 1 funt chleba wynosił 3 000 000 000 marek)

Długie jest łatwe do utrzymania, bardzo szybkie i powinno dać ci wystarczająco dużo miejsca na wykonanie wszystkich obliczeń odsetek przy użyciu tylko arytmetyki liczb całkowitych, odpowiedź e-biznesu wyjaśnia, jak to zrobić.

Ile pracy chcesz w to włożyć? Jak ważna jest dokładność? Czy zależy Ci na śledzeniu błędów ułamkowych, które występują podczas zaokrąglania i niedokładności przedstawiania liczb dziesiętnych w systemie dwójkowym?

Ostatecznie spędzam trochę więcej czasu na kodowaniu i wdrażaniu testów jednostkowych dla „przypadków narożnych” i znanych spraw problematycznych - więc pomyślałbym o zmodyfikowanym BigInteger, który obejmuje dowolnie duże kwoty i zachowuje bity ułamkowe za pomocą BigDecimal lub część BigRational (dwie BigInteger, jedna dla mianownika, a druga dla licznika) - i zawiera kod, aby część ułamkowa była ułamkiem rzeczywistym poprzez (być może tylko okresowe) dodawanie dowolnej części niefrakcyjnej do głównej BigInteger. Następnie wewnętrznie śledziłbym wszystko w centach, tylko po to, aby części ułamkowe nie były uwzględniane w obliczeniach GUI.

Prawdopodobnie sposób na skomplikowanie dla (prostej) gry - ale dobry dla biblioteki opublikowanej jako open source! Musiałbym tylko wymyślić sposoby utrzymania dobrej wydajności w przypadku bitów ułamkowych ...

Na pewno nie unosi się. Mając tylko 7 cyfr, masz tylko dokładność:

12 345,67 123 456,7x

Widzisz, już mając 10 ^ 5 dolarów, tracisz poczucie grosza. double jest użyteczny do celów gry, a nie w prawdziwym życiu z powodu obaw o dokładność.

Ale długi (a przez to mam na myśli 64-bitowy lub długi długi w C ++) nie wystarczy, jeśli zamierzasz śledzić transakcje i sumować je. Wystarczy utrzymać udziały netto dowolnej firmy, ale wszystkie transakcje na rok mogą się przepełnić. To zależy od tego, jak duży jest Twój finansowy świat w grze.

Kolejnym rozwiązaniem, które tu dodam, jest zarabianie pieniędzy. Klasa byłaby czymś podobnym (mogłaby nawet po prostu być strukturą).

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;
}

Pozwoliłoby to przedstawić centy w tym przypadku jako liczbę całkowitą, a całe dolary jako liczbę całkowitą. Ponieważ masz oddzielną flagę za ujemną, możesz użyć liczb całkowitych bez znaku dla swoich wartości, co podwaja możliwą ilość (możesz także napisać klasę liczb, która stosuje ten pomysł do liczb, aby uzyskać NAPRAWDĘ duże liczby). Wszystko, co musisz zrobić, to przeciążenie operatorów matematycznych i możesz użyć tego jak każdego starego typu danych. Zajmuje więcej pamięci, ale tak naprawdę rozszerza granice wartości.

Można to dodatkowo rozszerzyć o takie rzeczy, jak liczba częściowych jednostek na całe jednostki, dzięki czemu możesz mieć waluty, które dzielą się na coś innego niż 100 jednostek podrzędnych, w tym przypadku centów, za dolara. Na przykład możesz mieć 125 floopie, które tworzą jeden flooper.

Edytować:

Rozwinę pomysł, że możesz mieć również tabelę przeglądową, do której klasa pieniędzy może uzyskać dostęp, która zapewniłaby kurs dla jej waluty względem wszystkich innych walut. Możesz to wbudować w funkcje przeciążania operatora. Dlatego jeśli spróbujesz automatycznie dodać 4 USD do 4 funtów brytyjskich, automatycznie otrzymasz 6,6 funta (w momencie pisania).

Jak wspomniano w jednym z komentarzy do twojego pierwotnego pytania, problem ten został omówiony na StackExchange: https://stackoverflow.com/questions/8148684/what-is-the-best-data-type-to-use-for- Aplikacja Money-in-Java

Zasadniczo typy zmiennoprzecinkowe nigdy nie powinny być używane do reprezentowania walut i podobnie jak większość języków, Java ma bardziej odpowiedni typ. Własna dokumentacja Oracle dotycząca prymitywów sugeruje użycie BigDecimal .

Użyj klasy, to najlepszy sposób. Możesz ukryć realizację swoich pieniędzy, możesz zmieniać podwójne / długie, co tylko chcesz w dowolnym momencie.

Przykład

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
    }
}

W swoim kodzie używaj po prostu gettera, to jest lepszy sposób i myślę, że możesz przechowywać bardziej przydatne metody.