10 ms·

Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you shoul

Specialising in financial software, over the past 2 decades I have been fighting over this with countless people, teams and companies. For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules. If your programming environment/language does not have one, it is unsuitable to be used for accounting, billing, invoicing, payments, etc. Having the underlying library is, of course, not enough. You also need to be able to properly store (data structures, databases), transfer (wire formats, data structures), process (order of operations, rounding rules), present (UI toolkit) and so on. I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correctly (and I worked for companies ranging from small startups just needing invoices and very simple billing to risk management departments for largest financial institutions on Earth processing trillions of dollars on a daily basis).

forinti 3y ago
I have a personal anecdote on this subject. A long time ago I worked at a bank and I had to calculate a large number of accounts regarding agricultural loans. These were state sponsored loans. When I finished my task (this was a Java job), I found that sometimes the results were off by $0.01. So I asked my boss how I should do the rounding, to which he replied that an error of up to $1 was acceptable. If I recall correctly, the amounts where in the hundreds and thousands.
- rvnx 3y ago
  I had such case too, the solution is simple: round in favor of the bank / financial institution you are working for
  - onetimeuse92304 3y ago
    No, it does not work this way. Any good accountant will see a different in values, even smallest one, as a sign of an incorrect calculation. Does not matter which way it goes, they will feel compelled to figure out who is wrong. At least a good accountant will.
    - rvnx 3y ago
      There is no accounting error; let's say customer has purchased / used a service for 1.433 USD. You issue an invoice for 1.44 USD (aka, amount due), then the 1.44 USD is used as a basis for accounting and is all consistent. Then, if you are a nice company and the situation applies in your case, you may issue a credit in favor of the customer for 1.44 USD - 1.433 USD that will be used as a discount on a future invoice The best part is that the moment where you decide to issue the credit invoice or not, is the perfect moment to track the rounding errors and even keep a very detailed journal of the entries (e.g. for auditors).
      - marcosdumay 3y ago
        You added 10 of those items as inventory with a total value of 14.33, then you sold each individually as a total value of 14.40. After that transaction, your inventory account has -0.07 on it, but there aren't any items at all there.
        hef19898 3y ago
        From experience, those differences surface during stock taking. Amd most companies are really bad at that. And if they surfacey they are corrected by inventors adjustments (in unit of measure, not value, which is a differwnt can of worms). As long as those adjustments aren't to extreme, nobody really cares. A good accountant so will sooner or later investigate those rounding errors, as they will show up somewhere ultimately. And a general policy of rounding in one direction is the last thing you want an auditor to find.
        eternityforest 3y ago
        So accountants are like number detectives doing what's essentially debugging work just like a coder would?
        marcosdumay 3y ago
        They design the system, detect the failures, explain and correct them. So, their work even is more like programing than your comment implies.
  - tonfreed 3y ago
    I've worked in banking. I assure you, I would have had a million bugs filed on that before it even hit production.
  - seanhunter 3y ago
    That is absolutely not how it works. Rounding is exactly specified in the underlying contract always and you need to implement the correct rounding. For example, here is the rounding table for compounding calculations in the ISDA definitions (these are very standard for a wide range of contracts, but this particular table is for various overnight swap rates used in interest rate derivatives)[1]. [1] https://globalmarkets.cib.bnpparibas/app/uploads/sites/4/2021/11/isda-2021-definitions-compounding-averaging-matrix.pdf https://globalmarkets.cib.bnpparibas/app/uploads/sites/4/202...
    - cornstalks 3y ago
      And how do they round ties? Does 0.00005% round to 0.0001%? Is tie breaking usually included in such contracts?
      - RandomLensman 3y ago
        For these benchmarks, yes, that is defined. Where issues could come in is when these things are multiplied with a bunch of other numbers (each number with defined rounding but not after each operation) and then have some defined rounding at the end. There different computer numerics could in give slightly different results, but those can easily be resolved on settlement (for small stuff that stays well within the back offices - at least that is how I remember it). Also, not totally unusual for one or both participants to forget about some rounding they might have agreed bilaterally if it was some one off etc.
    - prometheus76 3y ago
      Interesting side note:ASME also has a standard for rounding on engineering drawings. A few years back I had to build a custom function in Excel to match the standard, because our calcs weren't matching the customer's calcs.
  - yyyk 3y ago
    Heh. But usually it's the other way around unless they remembered to specify it the right way. Forgiving $0.01*N customers is cheaper than dealing with an irate customer.
- valdiorn 3y ago
  I'm assuming you did the correct thing and engaged an an Office Space-esque penny-stealing operation after learning this? :)
- onetimeuse92304 3y ago
  On my first day in a new company, not even senior dev yet, I met with the head accountant. I asked about her top problems, she said her top problem was that the application would produce different invoice on screen, different invoice when printed as PDF and a different invoice in the accounting software. About 1% of all invoices were affected but due to amount of billing they were doing (telecommunications and advertising) they needed to have 3 FTEs just to correct the invoices. And correcting the invoices meant playing with numbers so that at least the PDF and accounting software agreed on the total value and tax. She also said they had at least 2 different employees and an external company look at it and not able to fix it. She also told me not to bother because she does not believe the problem can be fixed (that's what she was told). I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still. I ran couple of experiments to reverse engineer how the accounting software did the calculations -- the exact order of them and the exact rounding rules. Then I built a small module that captured those calculations. Then I changed all doubles to arbitrary precision. It took two days and the problem was fixed but it took couple more days before accounting department actually believed it.
  - formerly_proven 3y ago
    > I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still. Your setup made it sound like something crazy and inane, like "the PDF printer used on those machines changed floating point rounding modes" or what have you.
    - onetimeuse92304 3y ago
      In olden times we would "print to PDF" as in have a little piece of code to format the document that would be sent to a printer which could be a PDF document. In this particular case we had two separate pieces of code, one running on the client (for on screen presentation) and one on the backend (to create the PDF on a shared location and produce a download URL).
- twodave 3y ago
  https://wiki.c2.com/?BankersRounding https://wiki.c2.com/?BankersRounding
- Vvector 3y ago
  Sounds like the start of a movie script
  - GoToRO 3y ago
    Office Space https://youtu.be/yZjCQ3T5yXo?si=xGGrxafG2zzA0IIR https://youtu.be/yZjCQ3T5yXo?si=xGGrxafG2zzA0IIR
- deleted 3y ago
  [deleted]
- david422 3y ago
  Whenever I input my tax data on forms, it always rounded to the nearest dollar. It was strange that accuracy didn't seem to be a big priority.
  - brewdad 3y ago
    I imagine over millions of returns it probably evens out. Also, for the majority of taxpayers in the US, the tax table does things like: AGI is 40,001 to 40,025 then your tax is X dollars. Being accurate to the penny isn't worth the trouble.
    - david422 3y ago
      Yes, practically I can see why. But when my W2 contains cents, and my tax forms make me sign for accuracy under penalty of whatever blah blah, seems pretty odd that they don't accept my cents and then do their own internal rounding. Maybe it was just the tax software I was using.
- Cshelton 3y ago
  Exactly. I think many people start overthinking things in banking. Most accounting/finance departments are ok with rounding pennies every month. I run a Commercial Real Estate Servicing platform, where we are accruing interest on large balances daily. Our method is to not do the rounding daily, but add up all the numbers for a given period, say a month, and then round to the penny and create a single adjustment rounding transaction along with it. Accounting departments love us for it. If we rounded daily before storing the amount, the adjustment for accounting is usually a few pennies at least every month they have to make. Our method, it's roughly $0.01 per year with monthly periods, adjusted usually at the very end. Which on a $20MM loan, is very well within the bounds of acceptable.
  - hef19898 3y ago
    The real reason is because Cathrine Zeta Jones and James Bond actually did implement a program in Malaysia that collects all those rounding errors on a seperate bank account. And since it wenr global, affecting everypne, everyone thinks it ia simply normal. Or it is because rounding errors happen and accounting is a bitch. The first option makes for a better movie plot so.
    - dahart 3y ago
      I guess I’m old because I credit that plot to Superman III. TIL it’s called Salami Slicing https://en.wikipedia.org/wiki/Salami_slicing_tactics# https://en.wikipedia.org/wiki/Salami_slicing_tactics#
    - CleaveIt2Beaver 3y ago
      Man, you and I remember Office Space differently! /s
  - _glass 3y ago
    I love how small details, like rounding always up for 2.50 would be significantly skewing the numbers to the higher values, so there are functions like ROUND_HALF_EVEN that would round up on even numbers, and down on uneven ones.
  - 3y ago
- ignite 3y ago
  People care less about the dollar value than about reconciling. If there is some external system they should match, they really want it to match exactly.
Aardwolf 3y ago
Would IEEE decimal128 be sufficient (instead of arbitrary precision)? "Formally introduced in IEEE 754-2008, it is intended for applications where it is necessary to emulate decimal rounding exactly, such as financial and tax computations." https://en.wikipedia.org/wiki/Decimal128_floating-point_format https://en.wikipedia.org/wiki/Decimal128_floating-point_form...
- deleted 3y ago
  [deleted]
- onetimeuse92304 3y ago
  Hypothetical solutions that do not exist are none of my concern. Did you know different countries and different currencies have different rounding rules, for example for tax-related calculations? Does "IEEE decimal128" support this? Unless you can get all countries on our planet to agree on a single standard, any solution that does not allow specifying rounding rules is pretty much useless (unless you want to implement rounding yourself which tends to be very tricky -- I know because I attempted this couple of times).
  - eesmith 3y ago
    This is not hypothetical. Yes, of course IEEE decimal supports setting the rounding mode. The authors of the spec aren't ignorant of what's needed for financial and tax computations. Use fe_dec_setround from ISO/IEC TR 24732, "Extension for the programming language C to support decimal floating-point arithmetic". The modes listed at https://www.ibm.com/docs/en/zos/2.5.0?topic=functions-fe-dec-setround-set-current-rounding-mode https://www.ibm.com/docs/en/zos/2.5.0?topic=functions-fe-dec... are: FE_DEC_DOWNWARD rounds towards minus infinity FE_DEC_TONEAREST rounds to nearest FE_DEC_TOWARDZERO rounds toward zero FE_DEC_UPWARD rounds toward plus infinity FE_DEC_TONEARESTFROMZERO rounds to nearest, ties away from zero _FE_DEC_AWAYFROMZERO rounds away from zero _FE_DEC_TONEARESTTOWARDZERO rounds to nearest, ties toward zero _FE_DEC_PREPAREFORSHORTER rounds to prepare for shorter precision
    - 3y ago
throwaway894345 3y ago
What are the specific challenges to writing financial software? What are common mistakes you see? What are common data structures for representing money (both the common incorrect implementations but also the correct implementations)? Also, provided you have a data structure that can represent money, you should presumably be able to serialize that data structure and store or send it just like any other data, right? Why do you need special database or wire format support? The trivial example is to marshal it to JSON put it on disk or write it to the network using the protocol suite of your choice, right?
- onetimeuse92304 3y ago
  I never said you need special database or wire format. Maybe if you are using JSON, transfer monetary values as strings rather than decimal or float data types. Some databases can actually handle money, some don't. Those that do not, usually require you to store money as strings to not lose information. When you get warned by your DBA that the database can't do arithmetic on strings, tell them that "thank you, it could not do correct arithmetic anyway".
  - HerculePoirot 3y ago
    Just use integers, and fields ending with "_cents". There is no ambiguity, rounding problems are not even an issue, serialization and deserialization will pose no problem when dealing with external actors, and you can still sum money easily in your db requests. Problems will arise when you'll do multiplicative operations on money, for instance when working out taxes. There are precise rounding rules to apply, and the solution is to tackle these issue one abstraction layer above, on the operations rather than the values, because some time you'll want to carry out rounding between each tax operation, sometimes at the end, on one line or on a whole batch of transactions. Other problems you'll bump into is the asynchronous nature of money flows. You won't realize it with credit cards (well you'll figure it out soon enough when you'll stumble upon "race conditions"), but this becomes explicit when dealing with mandates, direct bank transfers or checks. You need to move the money out of sight of the user in a ledger specific to that person that holds transactions being processed (can takes days or weeks in some case) and move it back to the original ledger if the transaction fail. Otherwise you'll bump into issues of double spending. This is something that is out of your control sometimes (had the unfortunate experience to issue withdrawals multiple times on a big bank's payment processor API and theses dunces sent the money multiples times). Use idempotency keys profusely as well as (distributed) locks. The hardest part is not getting your part right, it's handling external actors bad implementations. Also fuck HTTP w/ hooks. Some actors do not even make sure you received the webhook. The non binary aspect of HTTP is a bullshit argument and I'd gladly trade it for a binary protocol that has strong quality of service mike MQTT, since anyway I'll have to implement some kind of smart broker when issuing orders to a shitty HTTP api anyway.
GTP 3y ago
What would be the problem with TigerBeetle's approach to use a smaller and configurable unit of measure so that you only have to deal with integers?
- lxgr 3y ago
  The article and the comment you're responding to aren't even talking about the same thing, so it's futile to discuss the pros and cons. The article is talking about serialized representations, i.e. how you store amounts in a database. The comment is talking about how to arrive at amounts as part of arithmetic calculations, e.g. determining interest, percentage fees etc.
tgv 3y ago
For very simple billing, arbitary precision sounds like overkill, as do rounding, and order of operations.
- onetimeuse92304 3y ago
  Oh, sure, because when you are a small company you don't care that people get correct invoices. I can certainly sympathise with this stance. There is about a billion things you can do better but you have limited time to do anything so you have to prioritise. And if one invoice in ten thousand is incorrect by one cent, and only one client in ten thousand who received the wrong invoice will actually find it out, then it is hard to argue you should be spending time on fixing this one problem. Just don't say you can do accounting correctly on floats and we will remain friends.
  - tylergetsay 3y ago
    For simple accounting I've always used integers and done all operations in cents, only converting on the frontend. what's my downside here? I guess it wouldn't support unit prices less than a penny
    - TheCoelacanth 3y ago
      Also many types of operations could give you the wrong result from incorrect rounding. E.g. let's say you're calculating 10% of $1.01 ten times and adding the result together. The correct result is $1.01, but with your method you will get $1.00.
      - projektfu 3y ago
        The correct answer will depend on the specifics of your environment. In some places, tax is calculated per line item. If you go to a dollar store and buy 10 items with 7.3% sales tax, it adds up without those 0.3¢ bits. In other places, the tax is supposed to be calculated on the total for the tax category in the sale. If you wanted to keep it by line item you'd need the extra digits of precision.
rbatiati 3y ago
Rounding monetary values is a complex, opinionated and business-defined operation. Sometimes it's even orthogonal to the datatype used. Things get out of hand when you need to round multiple different things that have to sum up at the end. For example: - Items in an invoice are rounded and summed. (eg. $1.1234 * 5.678kg) - Payments of an invoice can be paid in multiple installments, with interests that are also rounded (eg. 1.77% per month). - The value paid of interest *per item* must match the total value paid of interest in all installments of all invoices in the same period.
tantalor 3y ago
Serialization as a byte string ought be good enough if the storage layer doesn't support arbitrary precision natively.
im3w1l 3y ago
> I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correct This observation should tell you that's it actually quite viable to be off as long as the errors are small enough.
- kawhah 3y ago
  Quite right. Either this OP spends every day writing letters to banks, shops and credit card companies complaining about the fractional cents that they have been cheated out of, probably in green ink. OR they should be able to recognize that plenty of people have good-enough solutions for this.
- SoftTalker 3y ago
  Yeah even in university in my intro-level accounting classes they said in the real world nobody cares about discrepancies less than a dollar (and that amount scales with the size of the business). I don't know if that's actually true and I wasn't an accounting major so I don't know what they said in the more advanced classes. But if I imagine myself as a business owner I would be annoyed with my accounting firm if they spent billable hours chasing down a discrepancy of a few pennies.
  - koliber 3y ago
    Years of practice have led me to this practical wisdom: As long as things are consistent, no one cares if you are correct. If you lose a penny in the backend calculation, and the frontend shows the amount without the penny, and the email contains the amount without the penny, and the PDF download contains the amount without the penny, no one will care that there should be a penny there. It becomes problematic if some places are wrong and some are right, and they are not consistent. You won't get credit for being right in only some places. As long as the error is small enough to be inconsequential, being consistent is more important than being correct.
- devmor 3y ago
  As someone who works in fintech, my observation is not that the caveat is "as long as the errors are small enough" but rather "as long as whoever governs the business logic is aware of the impact". The size of the errors almost always is a large factor in their decision, but ultimately the software we write exists to serve the needs of the business, and if the business decides that larger errors are okay for some reason, then so be it.
RamblingCTO 3y ago
Not sure about that. In Germany, especially SMEs, no one cares about cents. Your tax reports are done in rounded Euros anyway. People, companies, and the taxation and financial state dept. are well aware of rounding issues, different ways to round that no one really cares about cents. Besides that, using BigDecimal with two decimal places is sufficient in the java world imho. Depends on your use case. I'm entirely sceptical of people claiming general things. Depends on the requirements I'd say.
- t0mas88 3y ago
  Same in the Netherlands. There is an official rule that you don't have to do mathematical rounding to get to whole euro's, you can do it in whichever direction is more favourable to you. That rule is probably there just to save the tax services some extra work and IT costs.
- lxgr 3y ago
  Only final values are rounded to full Euros (down, if I remember correctly). If a large taxpayer starts rounding down as part of intermediate calculations of their tax liability, I think they'd get some questions. But yes, rounding does happen a lot – what's important is that everybody uses the same, transparent rules for that, or it becomes impossible to double-check somebody's books, tax declaration, invoice etc.
  - RamblingCTO 3y ago
    Well, how much money can you save by efficient rounding? Surely not that much that anyone would bother. There's a thing called "Kaufmännisches Runden", which is kind of cheating as well. > But yes, rounding does happen a lot – what's important is that everybody uses the same, transparent rules for that, or it becomes impossible to double-check somebody's books, tax declaration, invoice etc. They don't, that's why it doesn't matter that much ;)
    - lxgr 3y ago
      > Well, how much money can you save by efficient rounding? You and me? Probably a few cents. A bank or a large corporation selling things billed in sub-cent amounts? Single-digit percentages of their gross revenue, i.e. many millions. Just as a very simple example: I'm your bank/phone provider/..., and I'm charging you a flat fee of 1.9 cents per transaction/call/... You're my customer and make a billion of such transactions per year. Option 1: 1000000000 * 0.019 = 19000, you owe me $19000000. Option 2: There are no fractional cents, so let's just round up each individual billing event. 1000000000 * 0.02 = 20000000, you owe me $20000000. Cool, a free extra million for the company! This is why these things are precisely regulated when it comes to sales tax/VAT, for example. > There's a thing called "Kaufmännisches Runden", which is kind of cheating as well. Always depends on which side you're on. If you're getting a refund, it can work in your favor! Importantly, it's a precisely defined rule so that it's not possible to cheat in the implementation.
frankreyes 3y ago
Many decades ago I worked in a Java team who they were using some money as a double and some as a BigDecimal. When I asked why, ... they said that at the start they didn't think they'd have any issue with doubles. Years later and still had lots of tech debt because manually rounding doubles to BigDecimal.
lxgr 3y ago
The article is about data types for storage, not for intermediary values used as part of calculations, though. Are you proposing that everybody is storing monetary values "wrong", too? And as a meta-point: > I have been fighting over this with countless people, teams and companies. [...] I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correctly [...] Are you absolutely sure that you are the only person that understands how to do accounting arithmetics on computers correctly? My guess would be that the status quo is a combination of a lot of legacy code and procedures, but more importantly of differing priorities. Maybe you value arithmetic correctness over simplicity of procedures (sometimes these need to be published in regulatory texts or even laws) or compatibility with other entities and their procedures much more than the industry average?
- vidarh 3y ago
  A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us round it wrong, to the wrong number of digits. And had we e.g. done something grossly incompetent like used floats for those calculations it most certainly would have been wrong, but so would it if I used fewer than five digits past the decimal point or failed to round in the right direction after that. It's usually not hard, but it requires being aware that you need to look up the right rules. And know better than using floats.
  - helpfulmountain 3y ago
    Why would it be wrong to use floats? That would have been my default assumption
    - lxgr 3y ago
      If there's an applicable law or regulation that says "you must do x", and you do y (and that yields different results), you'll get into trouble, even if your way yields "better" or "more accurate" results. This is not to say that using floats and rounding correctly necessarily does yield different results, by the way (although most likely it will) – but if they do differ, you're going to have a bad time using floats.
pjc50 3y ago
I did join somewhere that could do it correctly, because they had some very long-running POS software. It could even do things like "split bill three ways" correctly allocating both the spare penny from the division and the tax calculation, such that you could add the bills back together again and get the same numbers as the split bill. Using a "money" class that stores things as integer pennies gets you a long way there. "Division" and its close friend "multiply by noninteger number" are the only real problems, so you need to be careful not to provide a generic method and instead methods like divideWithLocaleTaxRounding(). You also need to check whether you're supposed to apply tax per-item or you can do it to the whole bill. I think we had a "apply tax to whole bill but then re-distribute it to line items" method, which guaranteed that the total would be correct. There are reasonable arguments for "integer decimal fraction of penny" as the correct unit. Digikey price some parts in 0.1 of a penny or cent, for example. Attempting to convert things between binary "fractions" (floating point) and decimal fractions will result in misery. I think we also had a "rational number" class for storing things like "1/3".
- amalcon 3y ago
  Integer cents is fantastic for POS software and similar things that deal with at most a few thousand dollars at a time. The place where it starts to fail is when the absolute numbers get really large, not really small. Think "United States Federal Reserve" or "UBS". Then remember that some of these institutions need to deal with accounts denominated in Zimbabwean dollars.
  - masklinn 3y ago
    Really small can be an issue when it gets really small e.g. tarsnap’s accounting is pretty infamously done in attodollars (1e-12). U64 only has room for 19 decimal digits so you’re limited to 7 figures up.
    - deleted 3y ago
      [deleted]
    - cperciva 3y ago
38 3y ago
> arbitrary precision math library with ability to specify rounding rules I got you: https://godocs.io/math/big#example-RoundingMode https://godocs.io/math/big#example-RoundingMode
_glass 3y ago
As much as SAP has problems, this is a solved problem there. In my experiences sometimes this is implemented incorrectly, but discovered very soon, as it's about money. I encountered this when people made some simple calculations on the frontend-side then submitting to the ERP system, where it was discovered because of the emerging inconsistencies.
ars 3y ago
Having an arbitrary precision library configured to use cents is not enough. Over a full year it needs to keep track of all the rounding it does when it pays you interest and when that rounding reaches a penny it's supposed to pay you that penny.
weinzierl 3y ago
"For accounting you should only ever use arbitrary precision math library" I'm a bit surprised by this advice. I thought the common wisdom was to use a decimal type like BigDecimal in Java.
- cwmma 3y ago
  BigDecimal is an arbitrary precision type so using BigDecimal is how you would follow said advice in Java.
- c2h5oh 3y ago
  BitInteger and BigDecimal are arbitrary precision types in Java
r00fus 3y ago
> For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules Do these rounding rules need to vary by jurisdiction?
- ska 3y ago
  Absolutely. IIRC most tax codes have specific rounding rules. Also e.g. some countries have done away with pennies or penny equivalents and have rules about how you are supposed to handle that, etc.
singleuse715185 3y ago
nobody cares about precision in financial calculations except for nerds. particularly areas like reporting tend to have significant errors, and not just sigma. this is now a fintech anecdotes thread, but my first ever fintech job was part of a two man special priviledges team directly under a director of X at one of the sifis. we were supposed to cut across multiple departments and through red tape with the main goal if eliminating significant overhead in certain processes (we brought some multi-day multi-step calculations down to 8 minutes in one instance, 2 minutes in another, kept us on a vendor list for a very very very long time). i didn't know how things are done, so i used bigdecimal throughout, with a lot of precision and explicit rounding rules. i did back of napkin numerical analysis for at least inner loop code. we duplicated work done by other departments (!!!), things like instrument pricing, because we couldn't wait for their batch jobs to complete. at the end we were getting from slightly to wildly different results. it took a lot of conversations with business to realize that 1) our calculations were correct 2) for them to realize what the sources of errors were and where they were coming from 3) for everyone to just kind of go eeeehh not a big deal. i wrote a translator for a subset of j/k to java bytecode using java asm, i was pretty proud of that system, because it allowed to express pricing rules in a what i thought was much more readable way, dynamic reload without restart, but man i am very very sorry for the developers who inherited that system.
nly 3y ago
In my experience most financial firms just use binary floats/doubles Fixed point decimal if you're lucky (or unlucky, since fixed point sucks) Arbitrary precision decimal floating point essentially never used

forinti 3y ago

I have a personal anecdote on this subject. A long time ago I worked at a bank and I had to calculate a large number of accounts regarding agricultural loans. These were state sponsored loans. When I finished my task (this was a Java job), I found that sometimes the results were off by $0.01. So I asked my boss how I should do the rounding, to which he replied that an error of up to $1 was acceptable. If I recall correctly, the amounts where in the hundreds and thousands.

rvnx 3y ago
I had such case too, the solution is simple: round in favor of the bank / financial institution you are working for
- onetimeuse92304 3y ago
  No, it does not work this way. Any good accountant will see a different in values, even smallest one, as a sign of an incorrect calculation. Does not matter which way it goes, they will feel compelled to figure out who is wrong. At least a good accountant will.
  - rvnx 3y ago
    There is no accounting error; let's say customer has purchased / used a service for 1.433 USD. You issue an invoice for 1.44 USD (aka, amount due), then the 1.44 USD is used as a basis for accounting and is all consistent. Then, if you are a nice company and the situation applies in your case, you may issue a credit in favor of the customer for 1.44 USD - 1.433 USD that will be used as a discount on a future invoice The best part is that the moment where you decide to issue the credit invoice or not, is the perfect moment to track the rounding errors and even keep a very detailed journal of the entries (e.g. for auditors).
    - marcosdumay 3y ago
      You added 10 of those items as inventory with a total value of 14.33, then you sold each individually as a total value of 14.40. After that transaction, your inventory account has -0.07 on it, but there aren't any items at all there.
      - hef19898 3y ago
        From experience, those differences surface during stock taking. Amd most companies are really bad at that. And if they surfacey they are corrected by inventors adjustments (in unit of measure, not value, which is a differwnt can of worms). As long as those adjustments aren't to extreme, nobody really cares. A good accountant so will sooner or later investigate those rounding errors, as they will show up somewhere ultimately. And a general policy of rounding in one direction is the last thing you want an auditor to find.
        eternityforest 3y ago
        So accountants are like number detectives doing what's essentially debugging work just like a coder would?
        marcosdumay 3y ago
        They design the system, detect the failures, explain and correct them. So, their work even is more like programing than your comment implies.
- tonfreed 3y ago
  I've worked in banking. I assure you, I would have had a million bugs filed on that before it even hit production.
- seanhunter 3y ago
  That is absolutely not how it works. Rounding is exactly specified in the underlying contract always and you need to implement the correct rounding. For example, here is the rounding table for compounding calculations in the ISDA definitions (these are very standard for a wide range of contracts, but this particular table is for various overnight swap rates used in interest rate derivatives)[1]. [1] https://globalmarkets.cib.bnpparibas/app/uploads/sites/4/2021/11/isda-2021-definitions-compounding-averaging-matrix.pdf https://globalmarkets.cib.bnpparibas/app/uploads/sites/4/202...
  - cornstalks 3y ago
    And how do they round ties? Does 0.00005% round to 0.0001%? Is tie breaking usually included in such contracts?
    - RandomLensman 3y ago
      For these benchmarks, yes, that is defined. Where issues could come in is when these things are multiplied with a bunch of other numbers (each number with defined rounding but not after each operation) and then have some defined rounding at the end. There different computer numerics could in give slightly different results, but those can easily be resolved on settlement (for small stuff that stays well within the back offices - at least that is how I remember it). Also, not totally unusual for one or both participants to forget about some rounding they might have agreed bilaterally if it was some one off etc.
  - prometheus76 3y ago
    Interesting side note:ASME also has a standard for rounding on engineering drawings. A few years back I had to build a custom function in Excel to match the standard, because our calcs weren't matching the customer's calcs.
- yyyk 3y ago
  Heh. But usually it's the other way around unless they remembered to specify it the right way. Forgiving $0.01*N customers is cheaper than dealing with an irate customer.
valdiorn 3y ago
I'm assuming you did the correct thing and engaged an an Office Space-esque penny-stealing operation after learning this? :)
onetimeuse92304 3y ago
On my first day in a new company, not even senior dev yet, I met with the head accountant. I asked about her top problems, she said her top problem was that the application would produce different invoice on screen, different invoice when printed as PDF and a different invoice in the accounting software. About 1% of all invoices were affected but due to amount of billing they were doing (telecommunications and advertising) they needed to have 3 FTEs just to correct the invoices. And correcting the invoices meant playing with numbers so that at least the PDF and accounting software agreed on the total value and tax. She also said they had at least 2 different employees and an external company look at it and not able to fix it. She also told me not to bother because she does not believe the problem can be fixed (that's what she was told). I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still. I ran couple of experiments to reverse engineer how the accounting software did the calculations -- the exact order of them and the exact rounding rules. Then I built a small module that captured those calculations. Then I changed all doubles to arbitrary precision. It took two days and the problem was fixed but it took couple more days before accounting department actually believed it.
- formerly_proven 3y ago
  > I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still. Your setup made it sound like something crazy and inane, like "the PDF printer used on those machines changed floating point rounding modes" or what have you.
  - onetimeuse92304 3y ago
    In olden times we would "print to PDF" as in have a little piece of code to format the document that would be sent to a printer which could be a PDF document. In this particular case we had two separate pieces of code, one running on the client (for on screen presentation) and one on the backend (to create the PDF on a shared location and produce a download URL).
twodave 3y ago
https://wiki.c2.com/?BankersRounding https://wiki.c2.com/?BankersRounding
Vvector 3y ago
Sounds like the start of a movie script
- GoToRO 3y ago
  Office Space https://youtu.be/yZjCQ3T5yXo?si=xGGrxafG2zzA0IIR https://youtu.be/yZjCQ3T5yXo?si=xGGrxafG2zzA0IIR
deleted 3y ago
[deleted]
david422 3y ago
Whenever I input my tax data on forms, it always rounded to the nearest dollar. It was strange that accuracy didn't seem to be a big priority.
- brewdad 3y ago
  I imagine over millions of returns it probably evens out. Also, for the majority of taxpayers in the US, the tax table does things like: AGI is 40,001 to 40,025 then your tax is X dollars. Being accurate to the penny isn't worth the trouble.
  - david422 3y ago
    Yes, practically I can see why. But when my W2 contains cents, and my tax forms make me sign for accuracy under penalty of whatever blah blah, seems pretty odd that they don't accept my cents and then do their own internal rounding. Maybe it was just the tax software I was using.
Cshelton 3y ago
Exactly. I think many people start overthinking things in banking. Most accounting/finance departments are ok with rounding pennies every month. I run a Commercial Real Estate Servicing platform, where we are accruing interest on large balances daily. Our method is to not do the rounding daily, but add up all the numbers for a given period, say a month, and then round to the penny and create a single adjustment rounding transaction along with it. Accounting departments love us for it. If we rounded daily before storing the amount, the adjustment for accounting is usually a few pennies at least every month they have to make. Our method, it's roughly $0.01 per year with monthly periods, adjusted usually at the very end. Which on a $20MM loan, is very well within the bounds of acceptable.
- hef19898 3y ago
  The real reason is because Cathrine Zeta Jones and James Bond actually did implement a program in Malaysia that collects all those rounding errors on a seperate bank account. And since it wenr global, affecting everypne, everyone thinks it ia simply normal. Or it is because rounding errors happen and accounting is a bitch. The first option makes for a better movie plot so.
  - dahart 3y ago
    I guess I’m old because I credit that plot to Superman III. TIL it’s called Salami Slicing https://en.wikipedia.org/wiki/Salami_slicing_tactics# https://en.wikipedia.org/wiki/Salami_slicing_tactics#
  - CleaveIt2Beaver 3y ago
    Man, you and I remember Office Space differently! /s
- _glass 3y ago
  I love how small details, like rounding always up for 2.50 would be significantly skewing the numbers to the higher values, so there are functions like ROUND_HALF_EVEN that would round up on even numbers, and down on uneven ones.
- 3y ago
ignite 3y ago
People care less about the dollar value than about reconciling. If there is some external system they should match, they really want it to match exactly.

Aardwolf 3y ago

Would IEEE decimal128 be sufficient (instead of arbitrary precision)? "Formally introduced in IEEE 754-2008, it is intended for applications where it is necessary to emulate decimal rounding exactly, such as financial and tax computations." https://en.wikipedia.org/wiki/Decimal128_floating-point_format https://en.wikipedia.org/wiki/Decimal128_floating-point_form...

deleted 3y ago
[deleted]
onetimeuse92304 3y ago
Hypothetical solutions that do not exist are none of my concern. Did you know different countries and different currencies have different rounding rules, for example for tax-related calculations? Does "IEEE decimal128" support this? Unless you can get all countries on our planet to agree on a single standard, any solution that does not allow specifying rounding rules is pretty much useless (unless you want to implement rounding yourself which tends to be very tricky -- I know because I attempted this couple of times).
- eesmith 3y ago
  This is not hypothetical. Yes, of course IEEE decimal supports setting the rounding mode. The authors of the spec aren't ignorant of what's needed for financial and tax computations. Use fe_dec_setround from ISO/IEC TR 24732, "Extension for the programming language C to support decimal floating-point arithmetic". The modes listed at https://www.ibm.com/docs/en/zos/2.5.0?topic=functions-fe-dec-setround-set-current-rounding-mode https://www.ibm.com/docs/en/zos/2.5.0?topic=functions-fe-dec... are: FE_DEC_DOWNWARD rounds towards minus infinity FE_DEC_TONEAREST rounds to nearest FE_DEC_TOWARDZERO rounds toward zero FE_DEC_UPWARD rounds toward plus infinity FE_DEC_TONEARESTFROMZERO rounds to nearest, ties away from zero _FE_DEC_AWAYFROMZERO rounds away from zero _FE_DEC_TONEARESTTOWARDZERO rounds to nearest, ties toward zero _FE_DEC_PREPAREFORSHORTER rounds to prepare for shorter precision
  - 3y ago

throwaway894345 3y ago

What are the specific challenges to writing financial software? What are common mistakes you see? What are common data structures for representing money (both the common incorrect implementations but also the correct implementations)? Also, provided you have a data structure that can represent money, you should presumably be able to serialize that data structure and store or send it just like any other data, right? Why do you need special database or wire format support? The trivial example is to marshal it to JSON put it on disk or write it to the network using the protocol suite of your choice, right?

onetimeuse92304 3y ago
I never said you need special database or wire format. Maybe if you are using JSON, transfer monetary values as strings rather than decimal or float data types. Some databases can actually handle money, some don't. Those that do not, usually require you to store money as strings to not lose information. When you get warned by your DBA that the database can't do arithmetic on strings, tell them that "thank you, it could not do correct arithmetic anyway".
- HerculePoirot 3y ago
  Just use integers, and fields ending with "_cents". There is no ambiguity, rounding problems are not even an issue, serialization and deserialization will pose no problem when dealing with external actors, and you can still sum money easily in your db requests. Problems will arise when you'll do multiplicative operations on money, for instance when working out taxes. There are precise rounding rules to apply, and the solution is to tackle these issue one abstraction layer above, on the operations rather than the values, because some time you'll want to carry out rounding between each tax operation, sometimes at the end, on one line or on a whole batch of transactions. Other problems you'll bump into is the asynchronous nature of money flows. You won't realize it with credit cards (well you'll figure it out soon enough when you'll stumble upon "race conditions"), but this becomes explicit when dealing with mandates, direct bank transfers or checks. You need to move the money out of sight of the user in a ledger specific to that person that holds transactions being processed (can takes days or weeks in some case) and move it back to the original ledger if the transaction fail. Otherwise you'll bump into issues of double spending. This is something that is out of your control sometimes (had the unfortunate experience to issue withdrawals multiple times on a big bank's payment processor API and theses dunces sent the money multiples times). Use idempotency keys profusely as well as (distributed) locks. The hardest part is not getting your part right, it's handling external actors bad implementations. Also fuck HTTP w/ hooks. Some actors do not even make sure you received the webhook. The non binary aspect of HTTP is a bullshit argument and I'd gladly trade it for a binary protocol that has strong quality of service mike MQTT, since anyway I'll have to implement some kind of smart broker when issuing orders to a shitty HTTP api anyway.

GTP 3y ago

What would be the problem with TigerBeetle's approach to use a smaller and configurable unit of measure so that you only have to deal with integers?

lxgr 3y ago
The article and the comment you're responding to aren't even talking about the same thing, so it's futile to discuss the pros and cons. The article is talking about serialized representations, i.e. how you store amounts in a database. The comment is talking about how to arrive at amounts as part of arithmetic calculations, e.g. determining interest, percentage fees etc.

tgv 3y ago

For very simple billing, arbitary precision sounds like overkill, as do rounding, and order of operations.

onetimeuse92304 3y ago
Oh, sure, because when you are a small company you don't care that people get correct invoices. I can certainly sympathise with this stance. There is about a billion things you can do better but you have limited time to do anything so you have to prioritise. And if one invoice in ten thousand is incorrect by one cent, and only one client in ten thousand who received the wrong invoice will actually find it out, then it is hard to argue you should be spending time on fixing this one problem. Just don't say you can do accounting correctly on floats and we will remain friends.
- tylergetsay 3y ago
  For simple accounting I've always used integers and done all operations in cents, only converting on the frontend. what's my downside here? I guess it wouldn't support unit prices less than a penny
  - TheCoelacanth 3y ago
    Also many types of operations could give you the wrong result from incorrect rounding. E.g. let's say you're calculating 10% of $1.01 ten times and adding the result together. The correct result is $1.01, but with your method you will get $1.00.
    - projektfu 3y ago
      The correct answer will depend on the specifics of your environment. In some places, tax is calculated per line item. If you go to a dollar store and buy 10 items with 7.3% sales tax, it adds up without those 0.3¢ bits. In other places, the tax is supposed to be calculated on the total for the tax category in the sale. If you wanted to keep it by line item you'd need the extra digits of precision.

rbatiati 3y ago

Rounding monetary values is a complex, opinionated and business-defined operation. Sometimes it's even orthogonal to the datatype used. Things get out of hand when you need to round multiple different things that have to sum up at the end. For example: - Items in an invoice are rounded and summed. (eg. $1.1234 * 5.678kg) - Payments of an invoice can be paid in multiple installments, with interests that are also rounded (eg. 1.77% per month). - The value paid of interest *per item* must match the total value paid of interest in all installments of all invoices in the same period.

tantalor 3y ago

Serialization as a byte string ought be good enough if the storage layer doesn't support arbitrary precision natively.

im3w1l 3y ago

> I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correct This observation should tell you that's it actually quite viable to be off as long as the errors are small enough.

kawhah 3y ago
Quite right. Either this OP spends every day writing letters to banks, shops and credit card companies complaining about the fractional cents that they have been cheated out of, probably in green ink. OR they should be able to recognize that plenty of people have good-enough solutions for this.
SoftTalker 3y ago
Yeah even in university in my intro-level accounting classes they said in the real world nobody cares about discrepancies less than a dollar (and that amount scales with the size of the business). I don't know if that's actually true and I wasn't an accounting major so I don't know what they said in the more advanced classes. But if I imagine myself as a business owner I would be annoyed with my accounting firm if they spent billable hours chasing down a discrepancy of a few pennies.
- koliber 3y ago
  Years of practice have led me to this practical wisdom: As long as things are consistent, no one cares if you are correct. If you lose a penny in the backend calculation, and the frontend shows the amount without the penny, and the email contains the amount without the penny, and the PDF download contains the amount without the penny, no one will care that there should be a penny there. It becomes problematic if some places are wrong and some are right, and they are not consistent. You won't get credit for being right in only some places. As long as the error is small enough to be inconsequential, being consistent is more important than being correct.
devmor 3y ago
As someone who works in fintech, my observation is not that the caveat is "as long as the errors are small enough" but rather "as long as whoever governs the business logic is aware of the impact". The size of the errors almost always is a large factor in their decision, but ultimately the software we write exists to serve the needs of the business, and if the business decides that larger errors are okay for some reason, then so be it.

RamblingCTO 3y ago

Not sure about that. In Germany, especially SMEs, no one cares about cents. Your tax reports are done in rounded Euros anyway. People, companies, and the taxation and financial state dept. are well aware of rounding issues, different ways to round that no one really cares about cents. Besides that, using BigDecimal with two decimal places is sufficient in the java world imho. Depends on your use case. I'm entirely sceptical of people claiming general things. Depends on the requirements I'd say.

t0mas88 3y ago
Same in the Netherlands. There is an official rule that you don't have to do mathematical rounding to get to whole euro's, you can do it in whichever direction is more favourable to you. That rule is probably there just to save the tax services some extra work and IT costs.
lxgr 3y ago
Only final values are rounded to full Euros (down, if I remember correctly). If a large taxpayer starts rounding down as part of intermediate calculations of their tax liability, I think they'd get some questions. But yes, rounding does happen a lot – what's important is that everybody uses the same, transparent rules for that, or it becomes impossible to double-check somebody's books, tax declaration, invoice etc.
- RamblingCTO 3y ago
  Well, how much money can you save by efficient rounding? Surely not that much that anyone would bother. There's a thing called "Kaufmännisches Runden", which is kind of cheating as well. > But yes, rounding does happen a lot – what's important is that everybody uses the same, transparent rules for that, or it becomes impossible to double-check somebody's books, tax declaration, invoice etc. They don't, that's why it doesn't matter that much ;)
  - lxgr 3y ago
    > Well, how much money can you save by efficient rounding? You and me? Probably a few cents. A bank or a large corporation selling things billed in sub-cent amounts? Single-digit percentages of their gross revenue, i.e. many millions. Just as a very simple example: I'm your bank/phone provider/..., and I'm charging you a flat fee of 1.9 cents per transaction/call/... You're my customer and make a billion of such transactions per year. Option 1: 1000000000 * 0.019 = 19000, you owe me $19000000. Option 2: There are no fractional cents, so let's just round up each individual billing event. 1000000000 * 0.02 = 20000000, you owe me $20000000. Cool, a free extra million for the company! This is why these things are precisely regulated when it comes to sales tax/VAT, for example. > There's a thing called "Kaufmännisches Runden", which is kind of cheating as well. Always depends on which side you're on. If you're getting a refund, it can work in your favor! Importantly, it's a precisely defined rule so that it's not possible to cheat in the implementation.

frankreyes 3y ago

Many decades ago I worked in a Java team who they were using some money as a double and some as a BigDecimal. When I asked why, ... they said that at the start they didn't think they'd have any issue with doubles. Years later and still had lots of tech debt because manually rounding doubles to BigDecimal.

lxgr 3y ago

The article is about data types for storage, not for intermediary values used as part of calculations, though. Are you proposing that everybody is storing monetary values "wrong", too? And as a meta-point: > I have been fighting over this with countless people, teams and companies. [...] I have never in my life joined a software project for any organisation that was able to do basic arithmetic on money correctly [...] Are you absolutely sure that you are the only person that understands how to do accounting arithmetics on computers correctly? My guess would be that the status quo is a combination of a lot of legacy code and procedures, but more importantly of differing priorities. Maybe you value arithmetic correctness over simplicity of procedures (sometimes these need to be published in regulatory texts or even laws) or compatibility with other entities and their procedures much more than the industry average?

vidarh 3y ago
A shocking number of people (edit: who implement billing related software) are unaware of how many decimal points of accuracy their local tax code requires to calculate vat or sales tax correctly. And those things are often specified in terms of arithmetic correctness. I had our CFO stand behind me while I talked him through every step of our VAT calculations once, because he was legally responsible if I made us round it wrong, to the wrong number of digits. And had we e.g. done something grossly incompetent like used floats for those calculations it most certainly would have been wrong, but so would it if I used fewer than five digits past the decimal point or failed to round in the right direction after that. It's usually not hard, but it requires being aware that you need to look up the right rules. And know better than using floats.
- helpfulmountain 3y ago
  Why would it be wrong to use floats? That would have been my default assumption
  - lxgr 3y ago
    If there's an applicable law or regulation that says "you must do x", and you do y (and that yields different results), you'll get into trouble, even if your way yields "better" or "more accurate" results. This is not to say that using floats and rounding correctly necessarily does yield different results, by the way (although most likely it will) – but if they do differ, you're going to have a bad time using floats.

pjc50 3y ago

I did join somewhere that could do it correctly, because they had some very long-running POS software. It could even do things like "split bill three ways" correctly allocating both the spare penny from the division and the tax calculation, such that you could add the bills back together again and get the same numbers as the split bill. Using a "money" class that stores things as integer pennies gets you a long way there. "Division" and its close friend "multiply by noninteger number" are the only real problems, so you need to be careful not to provide a generic method and instead methods like divideWithLocaleTaxRounding(). You also need to check whether you're supposed to apply tax per-item or you can do it to the whole bill. I think we had a "apply tax to whole bill but then re-distribute it to line items" method, which guaranteed that the total would be correct. There are reasonable arguments for "integer decimal fraction of penny" as the correct unit. Digikey price some parts in 0.1 of a penny or cent, for example. Attempting to convert things between binary "fractions" (floating point) and decimal fractions will result in misery. I think we also had a "rational number" class for storing things like "1/3".

amalcon 3y ago
Integer cents is fantastic for POS software and similar things that deal with at most a few thousand dollars at a time. The place where it starts to fail is when the absolute numbers get really large, not really small. Think "United States Federal Reserve" or "UBS". Then remember that some of these institutions need to deal with accounts denominated in Zimbabwean dollars.
- masklinn 3y ago
  Really small can be an issue when it gets really small e.g. tarsnap’s accounting is pretty infamously done in attodollars (1e-12). U64 only has room for 19 decimal digits so you’re limited to 7 figures up.
  - deleted 3y ago
    [deleted]
  - cperciva 3y ago

38 3y ago

> arbitrary precision math library with ability to specify rounding rules I got you: https://godocs.io/math/big#example-RoundingMode https://godocs.io/math/big#example-RoundingMode

_glass 3y ago

As much as SAP has problems, this is a solved problem there. In my experiences sometimes this is implemented incorrectly, but discovered very soon, as it's about money. I encountered this when people made some simple calculations on the frontend-side then submitting to the ERP system, where it was discovered because of the emerging inconsistencies.

ars 3y ago

Having an arbitrary precision library configured to use cents is not enough. Over a full year it needs to keep track of all the rounding it does when it pays you interest and when that rounding reaches a penny it's supposed to pay you that penny.

weinzierl 3y ago

"For accounting you should only ever use arbitrary precision math library" I'm a bit surprised by this advice. I thought the common wisdom was to use a decimal type like BigDecimal in Java.

cwmma 3y ago
BigDecimal is an arbitrary precision type so using BigDecimal is how you would follow said advice in Java.
c2h5oh 3y ago
BitInteger and BigDecimal are arbitrary precision types in Java

r00fus 3y ago

> For accounting you should only ever use arbitrary precision math library with ability to specify rounding rules Do these rounding rules need to vary by jurisdiction?

ska 3y ago
Absolutely. IIRC most tax codes have specific rounding rules. Also e.g. some countries have done away with pennies or penny equivalents and have rules about how you are supposed to handle that, etc.

singleuse715185 3y ago

nobody cares about precision in financial calculations except for nerds. particularly areas like reporting tend to have significant errors, and not just sigma. this is now a fintech anecdotes thread, but my first ever fintech job was part of a two man special priviledges team directly under a director of X at one of the sifis. we were supposed to cut across multiple departments and through red tape with the main goal if eliminating significant overhead in certain processes (we brought some multi-day multi-step calculations down to 8 minutes in one instance, 2 minutes in another, kept us on a vendor list for a very very very long time). i didn't know how things are done, so i used bigdecimal throughout, with a lot of precision and explicit rounding rules. i did back of napkin numerical analysis for at least inner loop code. we duplicated work done by other departments (!!!), things like instrument pricing, because we couldn't wait for their batch jobs to complete. at the end we were getting from slightly to wildly different results. it took a lot of conversations with business to realize that 1) our calculations were correct 2) for them to realize what the sources of errors were and where they were coming from 3) for everyone to just kind of go eeeehh not a big deal. i wrote a translator for a subset of j/k to java bytecode using java asm, i was pretty proud of that system, because it allowed to express pricing rules in a what i thought was much more readable way, dynamic reload without restart, but man i am very very sorry for the developers who inherited that system.

nly 3y ago

In my experience most financial firms just use binary floats/doubles Fixed point decimal if you're lucky (or unlucky, since fixed point sucks) Arbitrary precision decimal floating point essentially never used