5 ms·

I develop accounting software for banks, brokerage houses and likes. Currency, taxes, rebates, etc. handling is NEVER done with floating point. Whatever you d

I develop accounting software for banks, brokerage houses and likes. Currency, taxes, rebates, etc. handling is NEVER done with floating point. Whatever you do with money you need predictable, reproducible results. It is norm that calculations are checked by software at two companies on both sides of transaction. Any discrepancies are alarms, bug reports, unhappy customers. Every significant operation is exactly specified with rounding rules, etc. For card payments and especially on terminals usually BCD is used. For everything else usually some kind of arbitrary length decimal library (BigInteger, BigDecimal).

chrisseaton 7y ago
> Currency, taxes, rebates, etc. handling is NEVER done with floating point. Nonsense. I’ve seen real banking code at reputable banks that uses floats. > Whatever you do with money you need predictable, reproducible results. Floats aren’t random. They’re perfectly deterministic, predictable and reproducible. If you do the same operation in two places you get the same result.
- mynegation 7y ago
  I write real banking code. There is definitely a banking code that uses floats, e.g. valuation of financial instruments. The parent comment talks about software that does transactions and “simpler” calculations, like taxes and fees etc. When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z).
  - throwawaymath 7y ago
    > When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z). Good example of this, in Python 3: >>> (0.1 + 0.2) + 0.3 0.6000000000000001 >>> 0.1 + (0.2 + 0.3) 0.6
    - chrisseaton 7y ago
      Every single time you run those two statements, you’ll get the same result. Yes they're non-associative. But that's specified and documented. That's not the same thing as non-deterministic in any way.
      - lmilcin 7y ago
        Yet, in accounting, you are expected to be able to sum a set of numbers in different ways and still get the same result
      - throwawaymath 7y ago
        Yes, sorry, I was just intending to highlight non-associativity :) I agree it's not "non-deterministic".
      - FabHK 7y ago
        The same code might be optimised in different ways by different compilers, though (or the same compiler with different flags). This might lead to different results for the same code. In that sense, it's non-deterministic.
        chrisseaton 7y ago
        > The same code might be optimised in different ways by different compilers, though It's not an optimisation if it changes the result! And if you use non-standard flags that's your problem.
        lmilcin 7y ago
        What is and what is not optimization and what changes are allowed or not depends on the application. MP3 is an optimization of WAV, yet it changes the result. Some applications are ok with reducing precision of calculations because they are not sensitive enough to small inaccuracies or they take effort to control inaccuarcies. For example, graphics applications are typically heavy in FP calculations and yet they tend to not care much about precision and much more about performance. For those applications reducing accuracy for slight performance increase is likely win.
  - deleted 7y ago
    [deleted]
- tsimionescu 7y ago
  > Floats aren’t random. They’re perfectly deterministic, predictable and reproducible. If you do the same operation in two places you get the same result. That's not exactly true in real hardware, or at least it wasn't until ~10 years ago. With the x87 FPU, internal precision was 80 bits, while the x86 registers were at most 64 bits. So, depending on the way the program would transfer data between the CPU and FPU your could get different results. It is very likely that different compilers and different optimization decisions could change the way these operations were implemented, so you would get slight differences between different versions of the software. There are/were also several global FP flags that could get changed by other programs running on the same CPU/FPU that could impact the result of calculations. So, if you want 100% reproducible FP, you would have to either audit all software running on the same machine to ensure it doesn't touch those flags, or set the flags yourself for every FP calculation in your your program.
  - chrisseaton 7y ago
    In a language like Java, all these factors are specified and fully deterministic.
    - tsimionescu 7y ago
      True, that's a good point. I was thinking of C & C++, but you're right, newer languages do a much better job of specifying and controlling this behavior. Wonder if JS does something similar or not.
      - gdxhyrd 7y ago
        All major C/C++ compilers implement IEEE754. If you are telling the compiler to disregard it, that is on you.
        tsimionescu 7y ago
        It's not about IEEE754, it's about the precision that the FP co-processor offers. The results you get are correct per IEEE754, it's just that they may have even less error than required by IEEE754 in some cases. But, this is enough to make the results non-deterministic between different compilation options. Also, changes applied to the FP co-processor by other processes on the machine could impact your process, regardless of your own compilation settings.
- lmilcin 7y ago
  I did not say floats are random. But when you do accounting you need to be able to sum large sets of numbers and compare results with another sum of different numbers and the sum must match. This just does not work with FP. Poor souls that use FP for accounting are scourge of the industry and source of jokes.
  - chrisseaton 7y ago
    That's what I used to think, then I met these banking types, and they told me 'no we understand their semantics and we use them correctly and we know it is safe for our programs.' These teams have compiler experts on them - they aren't ignorant.
    - lmilcin 7y ago
      I started working on accounting software in 2002 and right now work for Citi. Compiler experts in accounting? If you are doing HFT you are not doing accounting. Accounting is what happens later when all those transactions need to actually be accounted for and balance calculated
    - loopz 7y ago
      If you rely on compiler implementations for accounting, you're already lost. For anything imprecise and scientific, doubles will normally work well. Accounting rules regarding truncation and rounding as specified, seems unaccounted for by most until they meet such stringent reqs.

chrisseaton 7y ago

> Currency, taxes, rebates, etc. handling is NEVER done with floating point. Nonsense. I’ve seen real banking code at reputable banks that uses floats. > Whatever you do with money you need predictable, reproducible results. Floats aren’t random. They’re perfectly deterministic, predictable and reproducible. If you do the same operation in two places you get the same result.

mynegation 7y ago
I write real banking code. There is definitely a banking code that uses floats, e.g. valuation of financial instruments. The parent comment talks about software that does transactions and “simpler” calculations, like taxes and fees etc. When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z).
- throwawaymath 7y ago
  > When people talk about non-determinism of floating point, what they usually mean is non-associativity, that is (x+y)+z may not be exactly equal to x+(y+z). Good example of this, in Python 3: >>> (0.1 + 0.2) + 0.3 0.6000000000000001 >>> 0.1 + (0.2 + 0.3) 0.6
  - chrisseaton 7y ago
    Every single time you run those two statements, you’ll get the same result. Yes they're non-associative. But that's specified and documented. That's not the same thing as non-deterministic in any way.
    - lmilcin 7y ago
      Yet, in accounting, you are expected to be able to sum a set of numbers in different ways and still get the same result
    - throwawaymath 7y ago
      Yes, sorry, I was just intending to highlight non-associativity :) I agree it's not "non-deterministic".
    - FabHK 7y ago
      The same code might be optimised in different ways by different compilers, though (or the same compiler with different flags). This might lead to different results for the same code. In that sense, it's non-deterministic.
      - chrisseaton 7y ago
        > The same code might be optimised in different ways by different compilers, though It's not an optimisation if it changes the result! And if you use non-standard flags that's your problem.
        lmilcin 7y ago
        What is and what is not optimization and what changes are allowed or not depends on the application. MP3 is an optimization of WAV, yet it changes the result. Some applications are ok with reducing precision of calculations because they are not sensitive enough to small inaccuracies or they take effort to control inaccuarcies. For example, graphics applications are typically heavy in FP calculations and yet they tend to not care much about precision and much more about performance. For those applications reducing accuracy for slight performance increase is likely win.
- deleted 7y ago
  [deleted]
tsimionescu 7y ago
> Floats aren’t random. They’re perfectly deterministic, predictable and reproducible. If you do the same operation in two places you get the same result. That's not exactly true in real hardware, or at least it wasn't until ~10 years ago. With the x87 FPU, internal precision was 80 bits, while the x86 registers were at most 64 bits. So, depending on the way the program would transfer data between the CPU and FPU your could get different results. It is very likely that different compilers and different optimization decisions could change the way these operations were implemented, so you would get slight differences between different versions of the software. There are/were also several global FP flags that could get changed by other programs running on the same CPU/FPU that could impact the result of calculations. So, if you want 100% reproducible FP, you would have to either audit all software running on the same machine to ensure it doesn't touch those flags, or set the flags yourself for every FP calculation in your your program.
- chrisseaton 7y ago
  In a language like Java, all these factors are specified and fully deterministic.
  - tsimionescu 7y ago
    True, that's a good point. I was thinking of C & C++, but you're right, newer languages do a much better job of specifying and controlling this behavior. Wonder if JS does something similar or not.
    - gdxhyrd 7y ago
      All major C/C++ compilers implement IEEE754. If you are telling the compiler to disregard it, that is on you.
      - tsimionescu 7y ago
        It's not about IEEE754, it's about the precision that the FP co-processor offers. The results you get are correct per IEEE754, it's just that they may have even less error than required by IEEE754 in some cases. But, this is enough to make the results non-deterministic between different compilation options. Also, changes applied to the FP co-processor by other processes on the machine could impact your process, regardless of your own compilation settings.
lmilcin 7y ago
I did not say floats are random. But when you do accounting you need to be able to sum large sets of numbers and compare results with another sum of different numbers and the sum must match. This just does not work with FP. Poor souls that use FP for accounting are scourge of the industry and source of jokes.
- chrisseaton 7y ago
  That's what I used to think, then I met these banking types, and they told me 'no we understand their semantics and we use them correctly and we know it is safe for our programs.' These teams have compiler experts on them - they aren't ignorant.
  - lmilcin 7y ago
    I started working on accounting software in 2002 and right now work for Citi. Compiler experts in accounting? If you are doing HFT you are not doing accounting. Accounting is what happens later when all those transactions need to actually be accounted for and balance calculated
  - loopz 7y ago
    If you rely on compiler implementations for accounting, you're already lost. For anything imprecise and scientific, doubles will normally work well. Accounting rules regarding truncation and rounding as specified, seems unaccounted for by most until they meet such stringent reqs.