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

111–120 of 128 posts

Re: Using floating-point numbers for money

#111

Post by protomyth »

Supermancho wrote: post #100
protomyth wrote: post #79

Earlier quoted context omitted.

Because it is a massive pain in the butt for your report writers / business intelligence people whose tools expect decimal fields. Never mind all the existing code that expects an actual decimal and not an integer. Plus tax folks like like their mills.

> Because it is a massive pain in the butt for your report writers / business intelligence people whose tools expect decimal fields That's a matter for the ETL that dumps the data on their screens.

Yeah, no. First, sometimes you actually don't get to use a ETL before doing the report, and massaging an integer or float to decimal in an ETL is just going to cause you trouble.

Re: Using floating-point numbers for money

#112

Post by tzs »

jspash wrote: post #37

I ran into a weird problem this week trying to convert a string "8.95" to an integer (8.95) that made me question if even Int is good enough and as suggested in the comments here, use BigInt or equivalent for anything to do with numbers. This also happens with Javascript and Elixir, not just Ruby. So perhaps it has something to do with how the cpu stores the numbers? I know this isn't StackOverflow, but could someone…

After converting the string to float and then multiplying by 100, round to the nearest integer.

Assuming that the underlying implementation of Ruby uses sscanf for the conversion (I'm assuming Ruby is in C or C++?), that should work.

I had some concerns about this general issue, and did some brute force testing. The following program constructs strings "0.1", "0.2", ..., "0.9", "0.01", "0.02", ..., "0.99", ..., "0.99999999", uses sscanf to turn them into doubles, multiplies by the appropriate power of 10, rounds to the nearest integer, and checks if that is right.

  #include 
  #include 
  
  int main(void)
  {
      int len = 1;
      unsigned long div = 10;
      char num[30];
      
      while (len

Re: Using floating-point numbers for money

#113

Post by sixstringtheory »

dragonwriter wrote: post #97
sixstringtheory wrote: post #85

Earlier quoted context omitted.

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.

> 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. That is not the sense of "computers use binary" that justifies the conclusions in the sentence in which the phrase was used in the post being responded to, so while true on its own, in context it is an example of the fallacy of equivocation.

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

Re: Using floating-point numbers for money

#114

Post by [deleted] »

protomyth wrote: post #111
Supermancho wrote: post #100

Earlier quoted context omitted.

> Because it is a massive pain in the butt for your report writers / business intelligence people whose tools expect decimal fields That's a matter for the ETL that dumps the data on their screens.

Yeah, no. First, sometimes you actually don't get to use a ETL before doing the report, and massaging an integer or float to decimal in an ETL is just going to cause you trouble.

[deleted]

Re: Using floating-point numbers for money

#115

Post by [deleted] »

protomyth wrote: post #111
Supermancho wrote: post #100

Earlier quoted context omitted.

> Because it is a massive pain in the butt for your report writers / business intelligence people whose tools expect decimal fields That's a matter for the ETL that dumps the data on their screens.

Yeah, no. First, sometimes you actually don't get to use a ETL before doing the report, and massaging an integer or float to decimal in an ETL is just going to cause you trouble.

[deleted]

Re: Using floating-point numbers for money

#116

Post by jdashg »

dahart wrote: post #96
pcwalton wrote: post #86

Earlier quoted context omitted.

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

You’re absolutely right; he did say 64 bit. I just wouldn’t do that blindly either, and the author admitted to not being fluent in error analysis. The issue with even doubles is that the magnitude of your error in a running total calculation is a sum of all the errors of your largest intermediate results (the results of multiplies you don’t see or store explicitly). That means with a bank account, the error of your c…

Isn't the proposal in the article is "round after every operation"? Since rounding to nearest cent values corrects each subtotal's error to zero, this should work up to 2^53 cents. ($90T)

Re: Using floating-point numbers for money

#117

Post by jdashg »

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?

Re: Using floating-point numbers for money

#118

Post by dllthomas »

sixstringtheory wrote: post #113
dragonwriter wrote: post #97

Earlier quoted context omitted.

> 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. That is not the sense of "computers use binary" that justifies the conclusions in the sentence in which the phrase was used in the post being responded to, so while true on its own, in context it is an example of the fallacy of equivocation.

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

Re: Using floating-point numbers for money

#119

Post by jglathe »

tbabb wrote: post #93
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…

This thread seems to be unaware of DEC64, so this seems as good a place as any to point to this: http://www.dec64.com/ The gist: It's efficient (adds and mults in a few instructions), and preserves the decimal representation. It's quite simple, really: Store a whole-number integer with a smaller one representing the number of shifts to the decimal point. This is probably a good choice for sensitive financial calculat…

Thank you for this link. Sounds interesting and looks like a lesson learned from history.

Re: Using floating-point numbers for money

#120

Post by dahart »

jdashg wrote: post #116
dahart wrote: post #96

Earlier quoted context omitted.

You’re absolutely right; he did say 64 bit. I just wouldn’t do that blindly either, and the author admitted to not being fluent in error analysis. The issue with even doubles is that the magnitude of your error in a running total calculation is a sum of all the errors of your largest intermediate results (the results of multiplies you don’t see or store explicitly). That means with a bank account, the error of your c…

Isn't the proposal in the article is "round after every operation"? Since rounding to nearest cent values corrects each subtotal's error to zero, this should work up to 2^53 cents. ($90T)

Yes, that is the proposal. Rounding doesn’t correct errors though, it can make the error grow faster. Rounding just keeps you from dealing with sub-pennies.
Post reply on HN