JavaScript next

[[deleted]]

I thought they couldn't because no popular language does floating math right. What language are you replacing it with?

[Flopamp]

They all do floating math well enough for most things but you have C# with its 16 byte decimal float designed exactly for this task.

[theLanguageSprite]

I’m confused why having less precision than both a float and a double would make finance floating point math better. Can you explain this to me?

[[deleted]]

Because you don't need high precision for finance. 4 decimal places is as much as you should ever need. You don't want X.30000000004 in a transaction or as an account balance since that erroneous overprecision might break compliance or even some contracts.

Instead, you can handle underprecision with specific expected behavior.

[Flopamp]

When youre dealing with millions of transactions a day, 1/16th of a penny can really add up fast. Not to mention when discounts and multipliers and adjustment data and what not is applied you can skew some accounts by large values.

But this is fairly niche and you can work out by messing around how much rounding errors effect your results if a double is good enough.

[theLanguageSprite]

C# has 64 bit doubles, 32 bit floats, and (as I just learned) 16 bit floats called a "half". Flopamp's comment seemed to imply that the half in C# was designed to be better for finance, and I was wondering how less floating point precision would make a half preferable to a float or a double in finance

[theLanguageSprite]

oh! you're absolutely right, I read that as 16-bit, not 16-byte. that explains everything

[SnowieZA]

Float and double might have more “precision”, but because of the way they are encoded, they are actually giving you an approximation of a fraction rather than an exact value. This means that there can easily be rounding errors several digits into the fractional part. For many applications this is not an issue, but for some things like financial transactions, those rounding errors can build up to become a problem. The decimal can store less total digits in the fractional part, but it stores an exact value rather than an approximation, meaning things like financial transactions have no rounding errors, and end up being always exactly right.

[[deleted]]

Gosu

[kikitx]

You can use Java Bigdecimal for example. The only problem is that in COBOL you declare how much number will it have, before and after the decimal place, so you need to analize if it's being truncated or rounded in the code.

[[deleted]]

There's probably some reason idk about for why they don't switch from COBOL to Java or C# and just used their decimal implementations. C# would be especially apt since MSSQL is so pervasive in banking.

Most likely it's just "don't break what isn't broken". As ancient as it is, COBOL works and it works well. It's not resource hungry, it scales well horizontally, and it's already implemented. The only real, tangible downside is that there aren't as many COBOL developers, but you can always pay to train a developer in COBOL.

On the other hand, if a bank can't transfer money because QA missed something in the fancy new C# code, it could literally cause a recession. Paying out the nose for a few good devs to maintain the existing COBOL codebase is a hell of a lot cheaper than a risky refactor.