3 ms·

What do they use? Not float I hope. Plus given that some currencies have different precisions... Don't tell me it's rounding errors over trillion monies?! :o)

by aatd86 2y ago

fluoridation 2y ago
The industry standard in finance is decimal floating point. C# for example has 'decimal', with 128 bits of precision. On occasion I've seen people who didn't know any better use floats. One time I had to fix errors of single satoshis in a customer's database because their developer used 1.0 to represent 1 BTC.
Maxatar 2y ago
As I indicate in another post, I work in finance and I use binary floats. So do a lot of others who work in the industry. I sympathize with people who think that IEEE floating points are some weird or error prone representation and that fixed point arithmetic solves every problem, but in my professional experience that isn't true and systems that start by using fixed point arithmetic eventually end up making a half-assed error prone and slow version of floating point arithmetic as soon as they need to handle more sophisticated use cases like handling multiple currencies, doing calculations involving percentages such as interest rates, etc etc... The IEEE 754 floating point standard is a very well thought out standard that is suitable for representing money as-is. If you have requirements such as compliance/legal/regulatory needs that mandate a minimum precision, then you can either opt to use decimal floating point or use binary floating point where you adjust the decimal place up to whatever legally required precision you are required to handle. For example the common complaint about binary floating point is that $1.10 can't be represented exactly so you should instead use a fixed integer representation in terms of cents and represent it as 110. But if your requirement is to be able to represent values exactly to the penny, then you can simply do the same thing but using a floating point to represent cents and represent $1.10 as the floating point 110.0. The fixed integer representation conveys almost no benefit over the floating point representation, and once you need to work with and mix currencies that are significantly out of proportion to one another, you begin to really appreciate the nuances and work that went into IEEE 754 for taking into account a great deal of corner cases that a fixed integer representation will absolutely and spectacularly fail to handle.
- vidarh 2y ago
  It really depends on your need. In some countries e.g. VAT calculations used to specify rounding requirements that were a pain to guarantee with floats. I at one point had our CFO at the time breathing down my neck while I implemented the VAT calculations while clutching a printout of the relevant regulations on rounding because in theory he could end up a defendant in a court case if I got it wrong (in practice not so much, but it spooked him enough that it was the one time he paid attention to what I was up to). Many tax authorities are now more relaxed, as long as your results average out in their favour, but there's a reason for this advice.
- kbolino 2y ago
  There are more problems with using floating-point for exact monetary quantities than just the inexact representations of certain quantities which are exact in base 10. For example, integers have all of the following advantages over floats: Integer arithmetic will never return NaN or infinity. Integer (a*b)*c will always equal a*(b*c). Integer (a+b)%n will always equal (a%n+b%n)%n, i.e. low-order bits are always preserved. IEEE 754 is not bad and shouldn't be feared, but it is not a universal solution to every problem. It's also not hard to multiply by fractions in fixed-point. You do a widening multiplication by the numerator followed by a narrowing division by the denominator. For percentages and interest rates etc., you can represent them using percentage points, basis points, or even parts-per-million depending on the precision you need.
  - bee_rider 2y ago
    Are there cases where float could return a NaN or infinity, where you instead prefer the integer result? That seems a little odd to me.
    - kbolino 2y ago
      Integer division by zero will raise an exception in most modern languages. Integer overflow is more problematic. While some languages in some situations will raise exceptions, most don't. While it's easier to detect overflow that has already occurred with floats (though you'll usually have lost low-order bits long before you get infinity), it's easier to avoid overflow in the first place with integers.

What do they use? Not float I hope. Plus given that some currencies have different precisions... Don't tell me it's rounding errors over trillion monies?! :o)

by aatd86 2y ago

What do they use? Not float I hope. Plus given that some currencies have different precisions... Don't tell me it's rounding errors over trillion monies?! :o)

fluoridation 2y ago

The industry standard in finance is decimal floating point. C# for example has 'decimal', with 128 bits of precision. On occasion I've seen people who didn't know any better use floats. One time I had to fix errors of single satoshis in a customer's database because their developer used 1.0 to represent 1 BTC.

Maxatar 2y ago

As I indicate in another post, I work in finance and I use binary floats. So do a lot of others who work in the industry. I sympathize with people who think that IEEE floating points are some weird or error prone representation and that fixed point arithmetic solves every problem, but in my professional experience that isn't true and systems that start by using fixed point arithmetic eventually end up making a half-assed error prone and slow version of floating point arithmetic as soon as they need to handle more sophisticated use cases like handling multiple currencies, doing calculations involving percentages such as interest rates, etc etc... The IEEE 754 floating point standard is a very well thought out standard that is suitable for representing money as-is. If you have requirements such as compliance/legal/regulatory needs that mandate a minimum precision, then you can either opt to use decimal floating point or use binary floating point where you adjust the decimal place up to whatever legally required precision you are required to handle. For example the common complaint about binary floating point is that $1.10 can't be represented exactly so you should instead use a fixed integer representation in terms of cents and represent it as 110. But if your requirement is to be able to represent values exactly to the penny, then you can simply do the same thing but using a floating point to represent cents and represent $1.10 as the floating point 110.0. The fixed integer representation conveys almost no benefit over the floating point representation, and once you need to work with and mix currencies that are significantly out of proportion to one another, you begin to really appreciate the nuances and work that went into IEEE 754 for taking into account a great deal of corner cases that a fixed integer representation will absolutely and spectacularly fail to handle.

vidarh 2y ago
It really depends on your need. In some countries e.g. VAT calculations used to specify rounding requirements that were a pain to guarantee with floats. I at one point had our CFO at the time breathing down my neck while I implemented the VAT calculations while clutching a printout of the relevant regulations on rounding because in theory he could end up a defendant in a court case if I got it wrong (in practice not so much, but it spooked him enough that it was the one time he paid attention to what I was up to). Many tax authorities are now more relaxed, as long as your results average out in their favour, but there's a reason for this advice.
kbolino 2y ago
There are more problems with using floating-point for exact monetary quantities than just the inexact representations of certain quantities which are exact in base 10. For example, integers have all of the following advantages over floats: Integer arithmetic will never return NaN or infinity. Integer (a*b)*c will always equal a*(b*c). Integer (a+b)%n will always equal (a%n+b%n)%n, i.e. low-order bits are always preserved. IEEE 754 is not bad and shouldn't be feared, but it is not a universal solution to every problem. It's also not hard to multiply by fractions in fixed-point. You do a widening multiplication by the numerator followed by a narrowing division by the denominator. For percentages and interest rates etc., you can represent them using percentage points, basis points, or even parts-per-million depending on the precision you need.
- bee_rider 2y ago
  Are there cases where float could return a NaN or infinity, where you instead prefer the integer result? That seems a little odd to me.
  - kbolino 2y ago
    Integer division by zero will raise an exception in most modern languages. Integer overflow is more problematic. While some languages in some situations will raise exceptions, most don't. While it's easier to detect overflow that has already occurred with floats (though you'll usually have lost low-order bits long before you get infinity), it's easier to avoid overflow in the first place with integers.