5 ms·
I'm not an expert but a finance library without a choice of rounding modes and using floating point for division and multiplication is a bit strange? Why those
by speps 8y ago
I'm not an expert but a finance library without a choice of rounding modes and using floating point for division and multiplication is a bit strange? Why those decisions?
- tyingq 8y agoIt appears to be using this: https://engineering.shopspring.com/decimal-an-arbitrary-precision-fixed-point-decimal-library-for-go-ff8b31ca7a5f https://engineering.shopspring.com/decimal-an-arbitrary-prec...
- robaho 8y agoNo, original go-trader used it, since quuckfixgo uses it, and during profiling it showed as a significant cost, so I wrote Fixed.Fixed
- chrisseaton 8y agoDespite what everyone says, I've spoken to several different people at several different highly-regarded banks who say that they do, in fact, use floating point for money amounts in some of their systems. What experience do people who work in banks have?
- christophilus 8y agoI worked in the credit union software space for a while, and using floating points for this does lead to trouble. There were several bugs in my time that were caused by using floats and were fixed by using integer math.
- segmondy 8y agoI work in Finance, I don't use float, and I suggest you never do either.
- chrisseaton 8y agoAs a concrete example, someone was running a massive online FFI for predicting the value of derivatives, and they were doing it in the real domain and using doubles on GPUs for monetary values. Where they doing it 'wrong' then? I don't know much about finance myself.
- frabert 8y agoIf you are predicting, chances are you don't care about all the decimals being correct and you'd rather get the result quickly.
- jimktrains2 8y agoPredicting a value is not the same as accounting.
- deleted 8y ago[deleted]
- OskarS 8y agoI think the problem here is that "financial computing" is too broad a term to apply a rule like that blindly. If you're making products like point-of-sale systems, ecommerce applications or account management, then it's basically malpractice to use floating point. The performance edge you get from them is so slight in the overall performance of the system and the damage bugs cause can be catastrophic. And it's very easy to get them wrong. It's pretty trivial in most languages to swap in decimal and/or rational types, so NOT doing so is just irresponsible. However, if you're doing things like high-frequency trading systems or machine learning stuff with massive amounts of data, then performance really does matter, and using floating point is entirely reasonable. If you're making systems like that, you're hopefully aware of the limitations of floating point and know how to use them safely.
- dragonwriter 8y agoPredicting is inherently approximate; accounting needs to be exact. They may use similar units, but they are different kinds of problems.
- mratsim 8y agoI used COBOL in a well known global American bank.
- atemerev 8y agoWe do use FP numbers for performance reasons occasionally, but we are well aware of their limitations, and when to normalize. Running option trading models with BigDecimal is unproductive. However, when the calculations are done, we store the results back as decimal representation.
- 75dvtwin 8y agoIn complex billing systems (that are also often responsible for computing non-trivial taxes), using fixed point math with configurable rounding rules -- is a must. There are requirement time discussions/rules that indicate if a computation has a rounding rule or not (and it is normally driven by whether a calculation involves division, or if a computation must match an amount in a different currency). Dividing amounts, as example, always comes about when there are mid-cycle cancelation/onboardings to a service. Currency translations cause that as well.