7 ms·

Maybe it’s just that I’ve done a few gigs at financial institutions, but it’s pretty shocking to see the number of people in this thread arguing that it’s a-ok

Maybe it’s just that I’ve done a few gigs at financial institutions, but it’s pretty shocking to see the number of people in this thread arguing that it’s a-ok to use floating point for money. I don’t want to get dragged down into specifics, but if you’re doing this, please, please don’t. Money is one of those things like dates and times - everyone who hasn’t done much of it can’t figure out what all the fuss is about. Just... please, at a minimum, if you don’t want to be bothered, find a reputable third-party library with Money and Currency or some such, and use that. It really won’t add much work for you.

smallnamespace 8y ago
I'm curious to hear about your specifics, since I was at a shop where front office used all floats (doubles). Not sure what the back office did, but I doubt it was all done in arbitrary position arithmetic. Note that if an accountant says things need to be accurate down to the penny, that's probably an exaggeration [1]. Financial statements are typically rounded to the thousands, e.g. Intel's are rounded to million [2]. The IRS also lets you round off dollars [3]. I agree though that if you're building a large complex system with many coders, and either 1) nobody has a full view of the calculation and can do the numerical analysis or 2) there's a high chance that at some point in the future you need penny-accurate bookkeeping, then it's safer to use a very wide int or float type. Of course, there's also the case where the accountant or auditor doesn't actually need penny precision, but it's easier to just tell the coder 'just in case'. [1] https://www.accountingtools.com/articles/2017/5/14/the-materiality-principle https://www.accountingtools.com/articles/2017/5/14/the-mater... [2] https://s21.q4cdn.com/600692695/files/doc_financials/2017/annual/Intel_Annual_Report_Final_corrected.pdf https://s21.q4cdn.com/600692695/files/doc_financials/2017/an... [3] https://taxmap.irs.gov/taxmap/pub17/p17-006.htm#TXMP5d034bfb https://taxmap.irs.gov/taxmap/pub17/p17-006.htm#TXMP5d034bfb
- stephengillie 8y ago
  Collecting the rounding leftovers into another bank account was the plot of Office Space.
  - tigershark 8y ago
    Also superman 3 15 years before...
- kbenson 8y ago
  If you bill customers for anything, and there are multiple items being totaled on an invoice, you do not want that total to be anything except an accurate sum of the individual parts. At a minimum, you look like a rinky dink operation that doesn't know how to add dollars and cents. On the other end of the spectrum, some people will likely accuse you of theft, and not nicely. Do not fall under the assumption that the amount you mis-bill will inform how upset the people are that contact you. You will likely be the easy and obvious scapegoat for all their recent annoyances. For example, imagine all the people upset at their AT&T, Comcast or Verizon bill, who now have an easy and obvious thing to point at as an example of over billing. Have fun with those transferred emotions...
  - smallnamespace 8y ago
    I think that's the disconnect here — 'high' finance is not an exact science, and clients don't actually have an easy way of checking the numbers directly themselves — not only the models, but the inputs are also proprietary. Even auditors and regulators are dependent on bank models. Note that the article's advice is to use their own library, but the library just uses JS floats as ints and a separate precision arg: https://github.com/sarahdayan/dinero.js/blob/master/src/dinero.js#L47 https://github.com/sarahdayan/dinero.js/blob/master/src/dine... This doesn't give you any more precision than using floats directly, just a wider 'mantissa' range.
    - kbenson 8y ago
      I thought it was fairly obvious I wasn't talking about banking. I was providing an example of a much more common scenario, which many businesses have to deal with, that also provides a good reason for taking care with currency. > This doesn't give you any more precision than using floats directly, just a wider 'mantissa' range. Floating point errors sometimes result in slightly smaller values than expected, and this can result in problems when they are passed around if even one spot if missed that needs to round. For example, some databases might truncate 1.9999999999 to 1.99 instead of round to 2.00. As a simple illustration, consider the following Javascript (because it's easily available): price1 = 0.10; price2 = 0.20; package1 = price1 + price2; // Hmm, 0.30000000000000004 on my system ten_packages = 10*package1 money_received = 5.00; change_due = money_received - ten_packages; // change_due is 1.9999999999999996,should be 2.00 So, either you choose floating point, and make sure to always round prior to display or passing to any other system and if you miss a spot it will probably just work fine until you hit specific values, or you convert to cents, and you only have to worry about overflow, and any place you don't convert is obvious because it's not formatted with cents and is an order of magnitude too large. And if you're worried that an int is too small and might overflow, just use a long, and that problem goes away for all conceivable real values in your lifetime. If you're coding defensively (and we're talking about money here, so why wouldn't you be?), one of them is obviously a better choice
- LoSboccacc 8y ago
  I've worked with a bank at a fund management application and money is annoying in surprising ways. Some background: funds can handle fractional quotes and each fund can have its own rounding rules, funds mixes can handle fractional percentages, when money enters or leaves the system it gets rounded to cents because you can't move fraction of cents (unless digital) So, you get issues even using arbitrary precision math. Operation order matters. Rounding impacts everywhere so you need to be consistent across the business logic, reversing an operation need to have rounding applied in a specific order to result in the final date to match the initial. Order is also important when splitting money, because the last share gets all the leftover cents that come from rounding the previous shares split so that the total gets allocated fully. I.e. moving the last 1$ from one fund mix to another mix that has 3 equally divided fund is going to round as .33 movement toward each, but you can't just leave that cent on the previous fund mix and you can't just drop it going nobody notices, so one of them gets .34
donbright 8y ago
finance is a different culture than hackernews, and the people speak different languages with different philosophy and assumptions about the world. maybe this is not a technical issue, maybe its a subculture interaction issue that involves a lot of technical details. i dont think its easy to 'understand' unless one group spends time with another, and i dont mean half an hour meeting, i mean like, shadowing someone for a week.
maceurt 8y ago
I don't know why people wouldn't just make and array for monetary values or make two int values for decimal and number place.

smallnamespace 8y ago

I'm curious to hear about your specifics, since I was at a shop where front office used all floats (doubles). Not sure what the back office did, but I doubt it was all done in arbitrary position arithmetic. Note that if an accountant says things need to be accurate down to the penny, that's probably an exaggeration [1]. Financial statements are typically rounded to the thousands, e.g. Intel's are rounded to million [2]. The IRS also lets you round off dollars [3]. I agree though that if you're building a large complex system with many coders, and either 1) nobody has a full view of the calculation and can do the numerical analysis or 2) there's a high chance that at some point in the future you need penny-accurate bookkeeping, then it's safer to use a very wide int or float type. Of course, there's also the case where the accountant or auditor doesn't actually need penny precision, but it's easier to just tell the coder 'just in case'. [1] https://www.accountingtools.com/articles/2017/5/14/the-materiality-principle https://www.accountingtools.com/articles/2017/5/14/the-mater... [2] https://s21.q4cdn.com/600692695/files/doc_financials/2017/annual/Intel_Annual_Report_Final_corrected.pdf https://s21.q4cdn.com/600692695/files/doc_financials/2017/an... [3] https://taxmap.irs.gov/taxmap/pub17/p17-006.htm#TXMP5d034bfb https://taxmap.irs.gov/taxmap/pub17/p17-006.htm#TXMP5d034bfb

stephengillie 8y ago
Collecting the rounding leftovers into another bank account was the plot of Office Space.
- tigershark 8y ago
  Also superman 3 15 years before...
kbenson 8y ago
If you bill customers for anything, and there are multiple items being totaled on an invoice, you do not want that total to be anything except an accurate sum of the individual parts. At a minimum, you look like a rinky dink operation that doesn't know how to add dollars and cents. On the other end of the spectrum, some people will likely accuse you of theft, and not nicely. Do not fall under the assumption that the amount you mis-bill will inform how upset the people are that contact you. You will likely be the easy and obvious scapegoat for all their recent annoyances. For example, imagine all the people upset at their AT&T, Comcast or Verizon bill, who now have an easy and obvious thing to point at as an example of over billing. Have fun with those transferred emotions...
- smallnamespace 8y ago
  I think that's the disconnect here — 'high' finance is not an exact science, and clients don't actually have an easy way of checking the numbers directly themselves — not only the models, but the inputs are also proprietary. Even auditors and regulators are dependent on bank models. Note that the article's advice is to use their own library, but the library just uses JS floats as ints and a separate precision arg: https://github.com/sarahdayan/dinero.js/blob/master/src/dinero.js#L47 https://github.com/sarahdayan/dinero.js/blob/master/src/dine... This doesn't give you any more precision than using floats directly, just a wider 'mantissa' range.
  - kbenson 8y ago
    I thought it was fairly obvious I wasn't talking about banking. I was providing an example of a much more common scenario, which many businesses have to deal with, that also provides a good reason for taking care with currency. > This doesn't give you any more precision than using floats directly, just a wider 'mantissa' range. Floating point errors sometimes result in slightly smaller values than expected, and this can result in problems when they are passed around if even one spot if missed that needs to round. For example, some databases might truncate 1.9999999999 to 1.99 instead of round to 2.00. As a simple illustration, consider the following Javascript (because it's easily available): price1 = 0.10; price2 = 0.20; package1 = price1 + price2; // Hmm, 0.30000000000000004 on my system ten_packages = 10*package1 money_received = 5.00; change_due = money_received - ten_packages; // change_due is 1.9999999999999996,should be 2.00 So, either you choose floating point, and make sure to always round prior to display or passing to any other system and if you miss a spot it will probably just work fine until you hit specific values, or you convert to cents, and you only have to worry about overflow, and any place you don't convert is obvious because it's not formatted with cents and is an order of magnitude too large. And if you're worried that an int is too small and might overflow, just use a long, and that problem goes away for all conceivable real values in your lifetime. If you're coding defensively (and we're talking about money here, so why wouldn't you be?), one of them is obviously a better choice
LoSboccacc 8y ago
I've worked with a bank at a fund management application and money is annoying in surprising ways. Some background: funds can handle fractional quotes and each fund can have its own rounding rules, funds mixes can handle fractional percentages, when money enters or leaves the system it gets rounded to cents because you can't move fraction of cents (unless digital) So, you get issues even using arbitrary precision math. Operation order matters. Rounding impacts everywhere so you need to be consistent across the business logic, reversing an operation need to have rounding applied in a specific order to result in the final date to match the initial. Order is also important when splitting money, because the last share gets all the leftover cents that come from rounding the previous shares split so that the total gets allocated fully. I.e. moving the last 1$ from one fund mix to another mix that has 3 equally divided fund is going to round as .33 movement toward each, but you can't just leave that cent on the previous fund mix and you can't just drop it going nobody notices, so one of them gets .34

donbright 8y ago

finance is a different culture than hackernews, and the people speak different languages with different philosophy and assumptions about the world. maybe this is not a technical issue, maybe its a subculture interaction issue that involves a lot of technical details. i dont think its easy to 'understand' unless one group spends time with another, and i dont mean half an hour meeting, i mean like, shadowing someone for a week.

maceurt 8y ago

I don't know why people wouldn't just make and array for monetary values or make two int values for decimal and number place.