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

81–90 of 128 posts

Re: Using floating-point numbers for money

#81

Post by e12e »

antonyme wrote: post #5

Sorry, but I remain skeptical. The same people who use `float` for financial calculations are probably the same people who don't understand how/why to do the rounding described to avoid these problems. Way too many programmers think that they are working in base 10 when using float. Why not just make them use it, and keep them out of trouble. Also, I wonder what the overhead of rounding every operation is? Comparable…

It's hard to consider float anything, but a hack - and certainly something to keep away from discrete domains (countables).

I'm a little more curious on the suitability of using integers for money though (integer number of pennies). I suppose there are cases (and rules) concerning fractional pennies? Like in the case of percents of interests, often given by the year, accumulated[1] by the month?

[1] that's probably not the correct term in English.

Re: Using floating-point numbers for money

#82

Post by e12e »

dahart wrote: post #69
geofft wrote: post #51

Earlier quoted context omitted.

How are you going to do linear interpolation, let alone exponential growth, without floating-point? On August 1 you made $1000, on August 7 you made $1100, assuming that growth is linear, how much are you going to make on August 20? If you have some routines for dividing fixed-point numbers, one, why do you believe they have more accuracy than floating point (especially if you're doing divisions by numbers that aren'…

> How are you going to do linear interpolation, let alone exponential growth, without floating-point? Fixed point is one answer, but I see you know that already. I don’t know what the banks use for interest, but I can guarantee that it’s not float32. > If you have some routines for dividing fixed-point numbers, one, why do you believe they have more accuracy than floating point Fixed point routines do not have more b…

> I think asking about correctness is a straw man. The issue is really about safety, predictability, and controllability.

Uh, and compliance? (if you didn't mean to imply that under "controllability")

Re: Using floating-point numbers for money

#84

Post by andrewaylett »

From the article: "I am not a theoretician and have not proven that this is actually correct."

So, yes, you might get away with floating point values for financials -- and I have even seen banking code that did -- but that doesn't mean it's a good idea. Especially when libraries providing fixed point and arbitrary precision decimal representations are widely available and easy to use.

The biggest problem with using IEE 754 for currencies is that IEE 754 defines a domain and a set of operations that don't match the domain and set of operations required for currency calculations. The discrepancies between the "right" answers and the answers given by IEE 754 aren't because IEE 754 is in some way "wrong", it's because it's not calculating what you think it's calculating.

Re: Using floating-point numbers for money

#85

Post by sixstringtheory »

dragonwriter wrote: post #58
sixstringtheory wrote: post #41

Earlier quoted context omitted.

The problem here isn’t integers at all, as 8.95 is not an integer but an integer (8) plus a fraction (0.95 or 95/100==19/20). That’s in decimal, but since computers use binary, your decimal fraction must be converted to a binary fraction. This is what floating point is used for, although it’s important to know that floating point is an approximation of the real number line, and also that fractions that are rational i…

> That’s in decimal, but since computers use binary Well, if you tell them to, e.g., by using a binary floating point type instead of a decimal type.

No, we aren’t using computers with logic gates that have 10 discrete states. Even if you’re programming to decimal, the underlying representation is still binary. But there are numerical differences between using decimals represented by rationals with binary integer numerators and denominators, vs floating point with binary mantissa and exponent.

Re: Using floating-point numbers for money

#86

Post by pcwalton »

dahart wrote: post #63
antonyme wrote: post #5

Sorry, but I remain skeptical. The same people who use `float` for financial calculations are probably the same people who don't understand how/why to do the rounding described to avoid these problems. Way too many programmers think that they are working in base 10 when using float. Why not just make them use it, and keep them out of trouble. Also, I wonder what the overhead of rounding every operation is? Comparable…

> I wonder what the overhead of rounding every operation is? Comparable to the cost of using a proper Decimal class? For what it’s worth, for the major ICs (Intel, NVIDIA, etc.) there is zero extra overhead. A choice of rounding modes is part of the floating point operation’s instruction. And keep in mind that a floating point op is always rounding no matter what you do, the question is whether it’s always using the…

> You run out of integer precision at 2^24, which is only 16 million

To be fair, the author seems to be suggesting using double-precision floating point. If you use integer numbers of pennies, signed 32-bit integers cap out at a similar value of $21M. 32 bits is just too small for financial calculations.

Re: Using floating-point numbers for money

#88

Post by semicolon_storm »

guggle wrote: post #24
antonyme wrote: post #5

Sorry, but I remain skeptical. The same people who use `float` for financial calculations are probably the same people who don't understand how/why to do the rounding described to avoid these problems. Way too many programmers think that they are working in base 10 when using float. Why not just make them use it, and keep them out of trouble. Also, I wonder what the overhead of rounding every operation is? Comparable…

> I would argue that financial math by definition needs to be accurate to the penny. Yes, indeed. There is no such thing as "financial math that does not need to be accurate to the penny". I wonder if OP has ever worked with a bookkeeper...

That's not strictly true. Some of the work I do involves software to do premium calculations for insurance. While pennies do matter for intermediate values during calculation, virtually everyone rounds the final premium to a dollar amount or the closest 10 cent increment. Nobody cares about pennies when each transaction is hundreds or thousands of dollars.

Re: Using floating-point numbers for money

#90

Post by nabla9 »

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)?

Post reply on HN