Трябва ли да се използва тип данни Float или Decimal за суми в долари?
Отговорът е лесен. Никога не плува. НИКОГА !
Поплавъците бяха според IEEE 754 винаги двоични, само новият стандарт IEEE 754R дефинира десетични формати. Много от дробните двоични части никога не могат да се равняват на точното десетично представяне.
Всяко двоично число може да бъде записано като m/2^n (m , n цели положителни числа), всяко десетично число като m/(2^n*5^n) .Тъй като двоичните файлове липсват простият factor 5 , всички двоични числа могат да бъдат точно представени с десетични знаци, но не и обратното.
0.3 = 3/(2^1 * 5^1) = 0.3
0.3 = [0.25/0.5] [0.25/0.375] [0.25/3.125] [0.2825/3.125]
1/4 1/8 1/16 1/32
Така че в крайна сметка получавате число по-високо или по-ниско от даденото десетично число. Винаги.
Защо това има значение? Закръгляване.
Нормалното закръгляване означава 0..4 надолу, 5..9 нагоре. Така че прави има значение дали резултатът е или 0.049999999999 .... или 0.0500000000 ... Може да знаете, че това означава 5 цента, но компютърът не знае това и закръгля 0.4999 ... надолу (грешно) и 0.5000 ... нагоре (вдясно).
Като се има предвид, че резултатът от изчисленията с плаваща запетая винаги съдържа малки термини за грешка, решението е чист късмет. Става безнадеждно, ако искате десетична обработка на четно закръгляване с двоични числа.
Неубеден? Вие настоявате, че във вашата акаунт система всичко е напълно наред? Активи и пасиви равни? Добре, след това вземете всяко от дадените форматирани числа от всеки запис, анализирайте ги и ги сумирайте с независима десетична система!
Сравнете това с форматираната сума. Опа, нещо не е наред, нали?
За това изчисление се изискваха изключителна точност и прецизност (използвахме Oracle'sFLOAT), за да можем да запишем „милиардните от една стотинка“, които се натрупват.
Не помага срещу тази грешка. Защото всички хора автоматично приемат, че компютърът сумира правилно и на практика никой не проверява самостоятелно.
