4 ms·

There is a little more to it than "languages don't provide decimal or fixed point". Both Java and Python provide decimal implementations as part of their standa

There is a little more to it than "languages don't provide decimal or fixed point". Both Java and Python provide decimal implementations as part of their standard libraries, and languages don't provide fixed-point as it's largely trivial: "just do integer operations and scale them appropriately". The problem is that fixed point is ambiguous: there are multiple ways to do rounding (unlike floating point which has been largely standardised since the early 90s). In fact, the COBOL rounding rules are rather complicated: https://stackoverflow.com/a/30215718/392585 https://stackoverflow.com/a/30215718/392585 This has some interesting consequences: I know of an insurance company where there were difficulties trying to replicate the exact premium calculation (which was done on a mainframe in COBOL), part of which involved taking 1.01 to the power of a positive integer (which depended on various risk factors of the policy). COBOL was not really intended for numerical work, and so doesn't have a "pow" function (or at least this version didn't): instead, it turns out that the programmer had used a simple loop which would iteratively multiply a variable by 1.01, incurring round-off at each iteration. So the only way to emulate it exactly was to use the same arithmetic _and_ the same ugly hacks used in the original software.

jarfil 8y ago
Why replicate the same calculation with the same errors? Shouldn't it be specified as a pure math formula somewhere, probably in the contacts? So they did it slightly wrong for a long time, but why would that be the reference instead of the contract.
- simonbyrne 8y ago
  They weren't trying to replace the system, just emulate it for testing and simulation purposes: e.g. test how new rates would affect existing policy holders. Insurance policies (the contracts) just have final premiums (sometimes they might split it out by risk), but they don't typically explain how the insurer arrived at that number.
- wruza 8y ago
  It hurts even when there is no explicit contract. After integrating a couple of factories we found out that not precision is king, but stability is. Too many processes depend on each other, from small to big, and if you’re lucky to mess it up without immediate notice from workers (which happens rarely, since they give a good friction on this slippery surface), costs to fix it may outprice the precision gains for years. Essentially, no matter what the hw/sw platform is, business “ABI” is locked into algorithms used, and rounding/floating/fixed is only one of these. I’ve seen [edit:algorithm-wise] wrong cost-price distributions, penalty calculations and so on, that were a foundation for chains of table-based and gut-based decision making. Things simply don’t add up for everyone, not to mention how hard is turning a switch for the entire org that runs e.g. 24/7 and/or has unfinished production shifts. That was a knowledge I wish I already had back then, since these sorts of projects provided a lot of frustration, insecurities and expenses that you never could imagine working as software half-pm/half-coder. At some point you start to doubt whether you’re skilled for this job or just a loser with a keyboard. Minor/simple processes lack that cohesion and can be fixed or left as-is without much trouble though.
  - LeifCarrotson 8y ago
    The requirements doc or contract generated to create the software almost always has a lot less thought and a lot less debugging and adjusting in it than the actual software and processes subsequently built around it that have been running that way for the last decade oe three. Can you imagine if, suddenly, an insurer had a 1% shift in premiums overnight because someone fixed the rounding algorithm to comply with the 1983 spec that had been mis-implemented in COBOL?
js8 8y ago
Not only that, but in fact, on IBM Mainframe (main COBOL platform), the new hardware decimal floating-point is actually better in all respects than original packed decimal fixed-point representation that COBOL programs often use. (So it's not true that floating-point has been standardized many years ago, recent latest IEEE 754 includes decimal floating-point as it was implemented on IBM mainframe.)
mamcx 8y ago
I'm building a language tailored for business app and for long time I was thinking in make decimals the first-class treatment. ie, when doing "total = 1.3 + 2 * 10%" all this is in decimal. To make float "total = 1.3f + 2f * 10%". The reason is that most, if not all, the calculations in my life are around money. I only use floats because that is what every language make me do. However, I wish to know how do this robustly. How not rely on hacks? How do this ok? I'm working in rust for this.
- simonbyrne 8y ago
  Your best bet might be wrapping the Intel decimal floating point library: https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library https://software.intel.com/en-us/articles/intel-decimal-floa... This is a software implementation of the standardized IEEE decimal format.
  - mamcx 8y ago
    Is that better than http://speleotrove.com/decimal/decnumber.html http://speleotrove.com/decimal/decnumber.html? But, apart to just have a decimal datatype + overload the operators and provide some functions, exist something else I need to be aware?
    - simonbyrne 8y ago
      I'm not really sure, but from a quick skim it seems that the Intel library provides standard math functions (log, exp, sin, etc.), whereas the speleotrove library does not. Also the speleotrove one doesn't appear to have been updated since 2010.

jarfil 8y ago

Why replicate the same calculation with the same errors? Shouldn't it be specified as a pure math formula somewhere, probably in the contacts? So they did it slightly wrong for a long time, but why would that be the reference instead of the contract.

simonbyrne 8y ago
They weren't trying to replace the system, just emulate it for testing and simulation purposes: e.g. test how new rates would affect existing policy holders. Insurance policies (the contracts) just have final premiums (sometimes they might split it out by risk), but they don't typically explain how the insurer arrived at that number.
wruza 8y ago
It hurts even when there is no explicit contract. After integrating a couple of factories we found out that not precision is king, but stability is. Too many processes depend on each other, from small to big, and if you’re lucky to mess it up without immediate notice from workers (which happens rarely, since they give a good friction on this slippery surface), costs to fix it may outprice the precision gains for years. Essentially, no matter what the hw/sw platform is, business “ABI” is locked into algorithms used, and rounding/floating/fixed is only one of these. I’ve seen [edit:algorithm-wise] wrong cost-price distributions, penalty calculations and so on, that were a foundation for chains of table-based and gut-based decision making. Things simply don’t add up for everyone, not to mention how hard is turning a switch for the entire org that runs e.g. 24/7 and/or has unfinished production shifts. That was a knowledge I wish I already had back then, since these sorts of projects provided a lot of frustration, insecurities and expenses that you never could imagine working as software half-pm/half-coder. At some point you start to doubt whether you’re skilled for this job or just a loser with a keyboard. Minor/simple processes lack that cohesion and can be fixed or left as-is without much trouble though.
- LeifCarrotson 8y ago
  The requirements doc or contract generated to create the software almost always has a lot less thought and a lot less debugging and adjusting in it than the actual software and processes subsequently built around it that have been running that way for the last decade oe three. Can you imagine if, suddenly, an insurer had a 1% shift in premiums overnight because someone fixed the rounding algorithm to comply with the 1983 spec that had been mis-implemented in COBOL?

js8 8y ago

Not only that, but in fact, on IBM Mainframe (main COBOL platform), the new hardware decimal floating-point is actually better in all respects than original packed decimal fixed-point representation that COBOL programs often use. (So it's not true that floating-point has been standardized many years ago, recent latest IEEE 754 includes decimal floating-point as it was implemented on IBM mainframe.)

mamcx 8y ago

I'm building a language tailored for business app and for long time I was thinking in make decimals the first-class treatment. ie, when doing "total = 1.3 + 2 * 10%" all this is in decimal. To make float "total = 1.3f + 2f * 10%". The reason is that most, if not all, the calculations in my life are around money. I only use floats because that is what every language make me do. However, I wish to know how do this robustly. How not rely on hacks? How do this ok? I'm working in rust for this.

simonbyrne 8y ago
Your best bet might be wrapping the Intel decimal floating point library: https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library https://software.intel.com/en-us/articles/intel-decimal-floa... This is a software implementation of the standardized IEEE decimal format.
- mamcx 8y ago
  Is that better than http://speleotrove.com/decimal/decnumber.html http://speleotrove.com/decimal/decnumber.html? But, apart to just have a decimal datatype + overload the operators and provide some functions, exist something else I need to be aware?
  - simonbyrne 8y ago
    I'm not really sure, but from a quick skim it seems that the Intel library provides standard math functions (log, exp, sin, etc.), whereas the speleotrove library does not. Also the speleotrove one doesn't appear to have been updated since 2010.