4 ms·

The typical library folks use is called MPFR: https://mpfr.org https://mpfr.org It's fast, high quality, and very complete.

vlovich123 2y ago
It might be also important to note that mpfr is really for scientific purposes that need to deal with such large precision - there are significant memory and performance costs. For financial accounting applications, a fixed precision floating point library (aka fixed point arithmetic) is probably a better choice. Also mpfr is c/c++ but the author didn’t really specify their language and there may be other better options although bindings likely exist.
- denton-scratch 2y ago
  I once wrote some accounting software for a tiny team in an investment bank. The bosses decided that we should use our brand-new platform, which was cheap to develop for, because most (normal) things could be done without code. All went well for a couple of months; then the customer reported that the system failed for currency conversions to and from Yen. There wasn't enough precision. We had to write an arbitrary-precision maths library, resulting in the project overrunning budget by a factor of three.
  - vlovich123 2y ago
    There’s a world of difference between an arbitrary precision library like mpfr suited for financial applications, a fixed precision “Decimal” type that’s better suited for financial applications, and trying to roll your own thing. I don’t believe anywhere that I wrote that you should roll your own. All I said is that for financial stuff “Decimal”-like APIs are going to be easier to configure, manage and be better suited for financial applications.
    - denton-scratch 2y ago
      Sure. This was the early eighties; we didn't really have "libraries", and even if we had, there was no way to plug them into this proprietary development system. > library like mpfr suited for financial applications, a fixed precision “Decimal” type that’s better suited for financial applications I don't know mpfr, but my guess is you meant to say that mpfr is better-suited for scientific applications?
      - vlovich123 2y ago
        Yeah, arbitrary precision is different from fixed point precision that financial institutions typically need. MPFR is arbitrary precision so if you’re doing stuff involving our solar system and beyond, you probably want to use mpfr and be very careful in setting up the equations you’re using. Financial transactions have different requirements though and the arbitrary precision is unnecessarily slow, uses unnecessary amounts of RAM, and I believe will probably difficult to configure correctly. That being said, I’ve never really used mpfr. More just relaying what I understand to be the lay of the land.
        nullc 2y ago
        MPFR itself is pretty easy to use. Unfortunately, if your formula are ill conditioned you can get inaccurate results even using thousands of bits of precision... so there is no replacement for doing analysis and testing. Perhaps if there were some interval-math equivalent of MPFR you could at least tell when your code might be producing wrong results without extensive mathematical analysis.
myth2018 2y ago
Thanks for the suggestion. And do you know where I could read about the underlying theory? I'd like to implement the most I could from scratch, for learning purposes.
- Galanwe 2y ago
  The underlying theory is primary school math if you stay in a decimal fixed point format. All you have to do is choose the number of decimals you want. Say, half the number of digits of the biggest number that fits your desired size. Half these digits will be for the integral part, the other half for the decimal part. For instance, if you want to store signed fixed point on 32 bits, the highest number in base 10 is 2 billion. That's 9 zeros for you. Say you pick 4 for the decimal part, just multiply your numbers by 10000. So 1 is 10000. You can use all the regular operators you want on these numbers, just remember to x10000 when storing them, and /10000 when extracting from them. You're really just "computing on tenths of thousands" instead of "computing on ones". This is obviously wasteful to do that in a decimal base, but it's also trivial, so unless you cannot afford to lose that many digits, stick with it. When confortable, consider moving to a binary base so that you don't waste as much digits. Note that it is not _stricly_ mandatory to use fixed point numbers when doing financial computations. Floating point can work just fine, it all depends on what kind of number and computation you have to deal with. Typically, the need for fixed point arises when 1) You work with really small and large numbers together, these are the most susceptible to be misrepresented as floating points. The best example is if you need to deal with exchange rates to convert between currencies that have widely different bases. 2) You need to chain a lot of operations, which could compound imprécision. 3) You need to store exact numbers of arbitrary precision (e.g. market data)
  - teo_zero 2y ago
    > You can use all the regular operators you want on these numbers, just remember to x10000 when storing them, and /10000 when extracting from them. ??? You can only use addition and subtraction in this way. As soon as you touch multiplication and division the rules don't hold anymore!

vlovich123 2y ago

It might be also important to note that mpfr is really for scientific purposes that need to deal with such large precision - there are significant memory and performance costs. For financial accounting applications, a fixed precision floating point library (aka fixed point arithmetic) is probably a better choice. Also mpfr is c/c++ but the author didn’t really specify their language and there may be other better options although bindings likely exist.

denton-scratch 2y ago
I once wrote some accounting software for a tiny team in an investment bank. The bosses decided that we should use our brand-new platform, which was cheap to develop for, because most (normal) things could be done without code. All went well for a couple of months; then the customer reported that the system failed for currency conversions to and from Yen. There wasn't enough precision. We had to write an arbitrary-precision maths library, resulting in the project overrunning budget by a factor of three.
- vlovich123 2y ago
  There’s a world of difference between an arbitrary precision library like mpfr suited for financial applications, a fixed precision “Decimal” type that’s better suited for financial applications, and trying to roll your own thing. I don’t believe anywhere that I wrote that you should roll your own. All I said is that for financial stuff “Decimal”-like APIs are going to be easier to configure, manage and be better suited for financial applications.
  - denton-scratch 2y ago
    Sure. This was the early eighties; we didn't really have "libraries", and even if we had, there was no way to plug them into this proprietary development system. > library like mpfr suited for financial applications, a fixed precision “Decimal” type that’s better suited for financial applications I don't know mpfr, but my guess is you meant to say that mpfr is better-suited for scientific applications?
    - vlovich123 2y ago
      Yeah, arbitrary precision is different from fixed point precision that financial institutions typically need. MPFR is arbitrary precision so if you’re doing stuff involving our solar system and beyond, you probably want to use mpfr and be very careful in setting up the equations you’re using. Financial transactions have different requirements though and the arbitrary precision is unnecessarily slow, uses unnecessary amounts of RAM, and I believe will probably difficult to configure correctly. That being said, I’ve never really used mpfr. More just relaying what I understand to be the lay of the land.
      - nullc 2y ago
        MPFR itself is pretty easy to use. Unfortunately, if your formula are ill conditioned you can get inaccurate results even using thousands of bits of precision... so there is no replacement for doing analysis and testing. Perhaps if there were some interval-math equivalent of MPFR you could at least tell when your code might be producing wrong results without extensive mathematical analysis.

myth2018 2y ago

Thanks for the suggestion. And do you know where I could read about the underlying theory? I'd like to implement the most I could from scratch, for learning purposes.

Galanwe 2y ago
The underlying theory is primary school math if you stay in a decimal fixed point format. All you have to do is choose the number of decimals you want. Say, half the number of digits of the biggest number that fits your desired size. Half these digits will be for the integral part, the other half for the decimal part. For instance, if you want to store signed fixed point on 32 bits, the highest number in base 10 is 2 billion. That's 9 zeros for you. Say you pick 4 for the decimal part, just multiply your numbers by 10000. So 1 is 10000. You can use all the regular operators you want on these numbers, just remember to x10000 when storing them, and /10000 when extracting from them. You're really just "computing on tenths of thousands" instead of "computing on ones". This is obviously wasteful to do that in a decimal base, but it's also trivial, so unless you cannot afford to lose that many digits, stick with it. When confortable, consider moving to a binary base so that you don't waste as much digits. Note that it is not _stricly_ mandatory to use fixed point numbers when doing financial computations. Floating point can work just fine, it all depends on what kind of number and computation you have to deal with. Typically, the need for fixed point arises when 1) You work with really small and large numbers together, these are the most susceptible to be misrepresented as floating points. The best example is if you need to deal with exchange rates to convert between currencies that have widely different bases. 2) You need to chain a lot of operations, which could compound imprécision. 3) You need to store exact numbers of arbitrary precision (e.g. market data)
- teo_zero 2y ago
  > You can use all the regular operators you want on these numbers, just remember to x10000 when storing them, and /10000 when extracting from them. ??? You can only use addition and subtraction in this way. As soon as you touch multiplication and division the rules don't hold anymore!