Wydajesz się być na miejscu z korzyściami płynącymi z używania typu zmiennoprzecinkowego. Zazwyczaj projektuję dla dziesiętnych we wszystkich przypadkach i polegam na profilerze, który da mi znać, czy operacje na dziesiętnych powodują wąskie gardła lub spowolnienia. W takich przypadkach, będę "down cast" podwoić lub float, ale tylko zrobić to wewnętrznie, i ostrożnie spróbować zarządzać straty precyzji poprzez ograniczenie liczby znaczących cyfr w operacji matematycznej jest wykonywana.

Ogólnie, jeśli wartość jest przejściowa (nie reused), można bezpiecznie używać typu zmiennoprzecinkowego. Prawdziwym problemem typów zmiennoprzecinkowych są następujące trzy scenariusze.

1. agregujesz wartości zmiennoprzecinkowe (w tym przypadku związek błędów precyzji)
2. budujesz wartości na podstawie wartości zmiennoprzecinkowej (na przykład w algorytmie rekurencyjnym)
3. wykonujesz matematykę z bardzo dużą liczbą cyfr znaczących (na przykład, 123456789.1 * .000000000000000987654321)

EDIT

Zgodnie z reference documentation on C# :

Decimal słowo kluczowe oznacza 128-bitowy typ danych. W porównaniu do typy zmiennoprzecinkowe, Typ dziesiętny ma większą precyzję i mniejszą zakres, co sprawia, że nadaje się do obliczenia finansowe i monetarne.

Aby wyjaśnić moje powyższe stwierdzenie:

Mam tendencję do projektowania dla dziesiętnych we wszystkich przypadków i polegają na profilerze, który pozwoli ja wiem czy operacje na decimal są powodujące wąskie gardła lub spowolnienia.

Decimal nie jest nieskończenie precyzyjne (niemożliwe jest przedstawienie nieskończonej precyzji dla nieintegralnych w prymitywnym typie danych), ale jest znacznie dokładniejsze niż double:

• dziesiętne = 28-29 znaczące cyfry
• double = 15-16 cyfr znaczących
• float = 7 cyfr

EDIT 2

W odpowiedzi nakomentarz Konrada Rudolfa punkt # 1 (powyżej) jest zdecydowanie poprawny. Agregacja nieprecyzyjności rzeczywiście się łączy. Zobacz poniższy kod dla przykładu:

private const float THREE_FIFTHS = 3f / 5f;
private const int ONE_MILLION = 1000000;

public static void Main(string[] args)
{
    Console.WriteLine("Three Fifths: {0}", THREE_FIFTHS.ToString("F10"));
    float asSingle = 0f;
    double asDouble = 0d;
    decimal asDecimal = 0M;

    for (int i = 0; i < ONE_MILLION; i++)
    {
        asSingle += THREE_FIFTHS;
        asDouble += THREE_FIFTHS;
        asDecimal += (decimal) THREE_FIFTHS;
    }
    Console.WriteLine("Six Hundred Thousand: {0:F10}", THREE_FIFTHS * ONE_MILLION);
    Console.WriteLine("Single: {0}", asSingle.ToString("F10"));
    Console.WriteLine("Double: {0}", asDouble.ToString("F10"));
    Console.WriteLine("Decimal: {0}", asDecimal.ToString("F10"));
    Console.ReadLine();
}

Daje to następujące rezultaty:

Three Fifths: 0.6000000000
Six Hundred Thousand: 600000.0000000000
Single: 599093.4000000000
Double: 599999.9999886850
Decimal: 600000.0000000000

Jak widzisz, mimo że dodajemy z tego samego źródła stałą, wyniki dublowania są mniej precyzyjne (chociaż prawdopodobnie będzie zaokrąglać poprawnie), a float jest znacznie mniej precyzyjny, do tego stopnia, że został zredukowany do tylko dwóch znaczących cyfr.

Użyj dziesiętnych dla wartości bazy 10, np. obliczeń finansowych, jak sugerowali inni.

Ale double jest na ogół dokładniejsze dla dowolnych obliczonych wartości.

Na przykład, jeśli chcesz obliczyć wagę każdej linii w portfelu, użyj double, ponieważ wynik będzie prawie sumować się do 100%.

W poniższym przykładzie, dubleresult jest bliżej 1 niż decimalResult:

// Add one third + one third + one third with decimal
decimal decimalValue = 1M / 3M;
decimal decimalResult = decimalValue + decimalValue + decimalValue;
// Add one third + one third + one third with double
double doubleValue = 1D / 3D;
double doubleResult = doubleValue + doubleValue + doubleValue;

Więc jeszcze raz na przykładzie portfolio:

• Na wartość rynkowa każdej linii w portfelu jest wartością pieniężną i prawdopodobnie najlepiej byłoby przedstawić ją jako wartość dziesiętną.

• Waga każdej linii w portfelu (=wartość rynkowa / suma (wartość rynkowa)) jest zwykle lepiej reprezentowana jako Podwójna.

Użyj podwójnego lub pływaka, gdy nie potrzebujesz precyzji, na przykład w grze platformowej, którą napisałem, użyłem pływaka do przechowywania prędkości gracza. Oczywiście nie potrzebuję tutaj super precyzji, ponieważ w końcu zaokrąglam do Int do rysowania na ekranie.

W niektórych rachunkach rozważ możliwość użycia typów całkowych zamiast lub w połączeniu. Załóżmy na przykład, że zasady, na których działasz, wymagają przeniesienia każdego wyniku obliczeń z co najmniej 6 miejscami po przecinku, a wynik końcowy zostanie zaokrąglony do najbliższego grosza.

Obliczenie 1/6 z 100 $ daje 16.66666666666666666666666666666667.., więc wartość przeprowadzona w arkuszu będzie $16.666667. Zarówno podwójne, jak i dziesiętne powinny dawać ten wynik dokładnie do 6 miejsca po przecinku. Możemy jednak uniknąć kumulacyjnego błędu, przenosząc wynik do przodu jako liczbę całkowitą 16666667. Każde kolejne obliczenie może być wykonane z taką samą precyzją i przeniesione do przodu w podobny sposób. Kontynuując przykład, obliczam podatek od sprzedaży w Teksasie od tej kwoty (16666667 * .0825 = 1375000). Dodanie dwóch (jest to krótki arkusz roboczy) 1666667 + 1375000 = 18041667. Przesunięcie punktu dziesiętnego z powrotem daje nam 18.041667, czyli $18.04.

Chociaż ten krótki przykład nie dałby błąd skumulowany przy użyciu podwójnego lub dziesiętnego, dość łatwo jest pokazać przypadki, w których po prostu obliczenie podwójnego lub dziesiętnego i przeniesienie do przodu zgromadziłoby znaczący błąd. Jeśli reguły, na których działasz, wymagają ograniczonej liczby miejsc po przecinku, przechowywanie każdej wartości jako liczby całkowitej przez pomnożenie przez 10^(wymagane # miejsc po przecinku), a następnie podzielenie przez 10^(wymagane # miejsc po przecinku), aby uzyskać rzeczywistą wartość, uniknie kumulacyjnego błędu.

W sytuacjach, gdy ułamki grosze nie występują (na przykład automat), nie ma powodu, aby w ogóle używać typów nieintegralnych. Pomyśl o tym, jak o liczeniu groszy, a nie dolarów. Widziałem kod, w którym każda kalkulacja obejmowała tylko całe grosze, jednak użycie podwójnego doprowadziło do błędów! Integer only math usunął problem. Więc moja niekonwencjonalna odpowiedź jest, jeśli to możliwe, rezygnować zarówno podwójne i dziesiętne.

Jeśli potrzebujesz binarnego interrop z innymi językami lub platformami, może być konieczne użycie float lub double, które są standaryzowane.

Uwaga: ten post jest oparty na informacjach o możliwościach typu dziesiętnego z http://csharpindepth.com/Articles/General/Decimal.aspx i moja własna interpretacja tego, co to znaczy. Zakładam, że Double to normalna Podwójna precyzja IEEE.

Note2: najmniejszy i największy w tym poście reffer do wielkości liczby.

Plusy "dziesiętnego".

• "decimal" może reprezentować dokładnie liczby, które można zapisać jako (wystarczająco krótkie) ułamki dziesiętne, podwójny nie może. Jest to ważne w księgach finansowych i podobnych, gdzie ważne jest, aby wyniki dokładnie pasowały do tego, co człowiek robi obliczenia dałoby.
• "decimal" ma znacznie większą mantissę niż"double". Oznacza to, że dla wartości w jego znormalizowanym zakresie" dziesiętny " będzie miał znacznie większą dokładność niż dwukrotnie.

Wady dziesiętne

• będzie dużo wolniej (nie mam benchmarków, ale chyba przynajmniej rząd wielkości może więcej), dziesiętny nie będzie korzystał z akceleracji sprzętowej i arytmetyka na nim będzie wymagała stosunkowo kosztownego mnożenia/dzielenia przez potęgi 10 (co jest znacznie droższe niż mnożenie i dzielenie przez potęgi 2), aby dopasować wykładnik przed dodawaniem/odejmowaniem i przywrócić wykładnik do zakresu po mnożeniu/dzieleniu.
• dziesiętny przepełni się wcześniej niż podwójny. dziesiętne mogą reprezentować tylko liczby do ±2⁹⁶-1 . Przez porównanie podwójne mogą reprezentować liczby do prawie ±2¹⁰²⁴
• decimal będzie zaniżał wcześniej. Najmniejsze liczby reprezentowalne w układzie dziesiętnym to ±10^-28 . Przez porównanie double może reprezentować wartości do 2^-149 (ok. 10^-45) jeśli obsługiwane są numery subnromalne i 2^-126 (ok. 10^-38) jeśli nie.
• decimal zajmuje dwa razy więcej pamięci niż dwukrotnie.

Moim zdaniem powinieneś domyślnie używać "dziesiętne" dla pracy pieniędzy i innych przypadków, w których dopasowanie obliczeń człowieka dokładnie jest ważne i że należy użyć użyj podwójnego jako domyślnego wyboru przez resztę czasu.

Użyj zmiennoprzecinkowych, jeśli wartość wydajności jest wyższa od poprawności.

Wybierz typ w funkcji aplikacji. Jeśli potrzebujesz precyzji jak w analizie finansowej, odpowiedziałeś na swoje pytanie. Ale jeśli aplikacja może rozliczyć się z oszacowania ok z podwójnym.

Czy Twoja aplikacja potrzebuje szybkiej kalkulacji, czy będzie miała cały czas na udzielenie odpowiedzi? To naprawdę zależy od rodzaju aplikacji.

Graficzny głodny? float lub double wystarczy. Analiza danych finansowych, meteoryt uderza w planetę precyzja ? Przydałoby się trochę precyzji :)

Decimal ma szersze bajty, double jest natywnie obsługiwane przez CPU. Decimal jest bazą-10, więc konwersja dziesiętna na podwójną odbywa się podczas obliczania dziesiętnego.

For accounting - decimal
For finance - double
For heavy computation - double

Pamiętaj, że. NET CLR obsługuje tylko matematykę.Pow (double, double). Funkcja dziesiętna nie jest obsługiwana.

. NET Framework 4

[SecuritySafeCritical]
public static extern double Pow(double x, double y);

Podwójne wartości będą serializowane do notacji naukowej domyślnie, jeśli notacja ta jest krótsza niż wyświetlacz dziesiętny. (np.00000003 będzie 3E-8) wartości dziesiętne nigdy nie będą serializowane do notacji naukowej. W przypadku serializacji do konsumpcji przez stronę zewnętrzną może to być brane pod uwagę.

Zależy, do czego go potrzebujesz.

Ponieważ float i double są binarnymi typami danych masz niektóre diifculties i errors w sposób w liczbie rund, więc na przykład double będzie okrągły 0.1 do 0.100000001490116, double będzie również okrągły 1 / 3 do 0.33333334326441. Po prostu nie wszystkie liczby rzeczywiste mają dokładną reprezentację w typach podwójnych

Na szczęście C# obsługuje również tak zwaną dziesiętną arytmetykę zmiennoprzecinkową, gdzie liczby są reprezentowane przez dziesiętny system liczbowy, a nie system binarny. Tak więc dziesiętna arytmetyka zmiennoprzecinkowa nie traci dokładności podczas przechowywania i przetwarzania liczb zmiennoprzecinkowych. Dzięki temu doskonale nadaje się do obliczeń, w których wymagany jest wysoki poziom dokładności.