Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using floating-point numbers for money

evanjones.ca

Post reply on HN
Print view View original

121–128 of 128 posts

Re: Using floating-point numbers for money

#121

Post by arcticbull »

jdashg wrote: post #117
arcticbull wrote: post #53

> Solution: Round after every operation No, the solution is not to use floating point numbers to store money. I worked on an iOS app in fintech for years, and let me assure you, using floating point numbers to calculate currency is an exercise in frustration and lack of correctness. When balances are wrong you're losing your customers money, which in turn loses trust in your product. You know it's inexact, an approxi…

How do the balances get incorrect with 2^53 cents of precisely-roundable range?

In part it's defense against mistakes. You've got a big org, lots of people contributing and your cultural enforcement of the fact everything has to be rounded after every single step falls down. If you're going to create wrappers to automate that part why not just use fixed-precision? There's not really a good reason to use floating point and a few good reasons not to.

Re: Using floating-point numbers for money

#123

Post by _wzsf »

nabla9 wrote: post #90

Large financial calculations where errors accumulate are more often than not done in database queries, not in the application software. What is faster in Postgresql? Double floats and TRUNC after each operation or using NUMERIC(precision, scale)?

hey bro, where's your scholarly record of impactful publications?

Re: Using floating-point numbers for money

#124

Post by sixstringtheory »

dllthomas wrote: post #118
sixstringtheory wrote: post #113

Earlier quoted context omitted.

Could you help me understand where I’ve gone wrong here? I think there’s some miscommunication going on.

Are you familiar with binary coded decimal? Decimal format floats are in somewhat the same vein. See, for instance, https://en.m.wikipedia.org/wiki/Decimal32_floating-point_for...

This is basically what I meant when I said "computers use binary"

Re: Using floating-point numbers for money

#125

Post by dllthomas »

sixstringtheory wrote: post #124
dllthomas wrote: post #118

Earlier quoted context omitted.

Are you familiar with binary coded decimal? Decimal format floats are in somewhat the same vein. See, for instance, https://en.m.wikipedia.org/wiki/Decimal32_floating-point_for...

This is basically what I meant when I said "computers use binary"

That sense is trivially true, but it doesn't follow that you have binary fractions.

Re: Using floating-point numbers for money

#126

Post by sixstringtheory »

dllthomas wrote: post #125
sixstringtheory wrote: post #124

Earlier quoted context omitted.

This is basically what I meant when I said "computers use binary"

That sense is trivially true, but it doesn't follow that you have binary fractions.

Sorry, but I'm not parsing this sentence:

> it doesn't follow that you have binary fractions

Is that in reference to something I said earlier, or are we just falling deeper down a rabbit hole of hair splitting?

The point I was driving at is that a given number we think about in decimal like 12.3456 can be represented in binary in more than one way, one of which are rationals backed by integers for num/den, another is floating point with mantissa and exponent. Which way is chosen ultimately affects the outcomes of computations. I was trying to explain why OP was seeing unexpected results. I don't think I've been mistaken in the explanations...

Re: Using floating-point numbers for money

#127

Post by dllthomas »

sixstringtheory wrote: post #126
dllthomas wrote: post #125

Earlier quoted context omitted.

That sense is trivially true, but it doesn't follow that you have binary fractions.

Sorry, but I'm not parsing this sentence: > it doesn't follow that you have binary fractions Is that in reference to something I said earlier, or are we just falling deeper down a rabbit hole of hair splitting? The point I was driving at is that a given number we think about in decimal like 12.3456 can be represented in binary in more than one way, one of which are rationals backed by integers for num/den, another is…

The issue is that you are missing the possibility of decimal floating point, which is also defined in IEEE 754 but which is typically not exposed as a primitive in programming languages. Imagine a BCD mantissa. That can encode 12.3456 exactly.

So it's not "since computers use binary", but "since we use binary floating point". There are fair arguments that we made that choice because of efficiency concerns driven by the fact that "computers use binary", but I don't think that really helps the explanation.

Note that the original objection was picking at a nit that I am not sure I would have picked at, I am just seeking to clarify.

Re: Using floating-point numbers for money

#128

Post by sixstringtheory »

ComputerGuru wrote: post #104
kstenerud wrote: post #28

No, do not do financial calculations in binary floating point. Converting between base 2 and base 10 fractions can do funny things (including during the rounding step, which is also 99% guaranteed to be inaccurate because base 10 fractions can't be exactly represented as base 2 fractions). Most professional financial packages use fixed point decimal, which can easily be implemented by specifying a fractional unit (su…

A notable exception to the general lack of floating decimal support is C#, which has had floating decimal (System.Decimal) support in the CLR from the start (128 bits with a scale of 0 to 28). https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Apple SDKs have NSDecimal [0] and NSDecimalNumber [1].

[0]: https://developer.apple.com/documentation/foundation/nsdecim...

[1]: https://developer.apple.com/documentation/foundation/nsdecim...

Post reply on HN