5 ms·
Perhaps I'm the odd one out here, but most financial systems I've had the chance to work with don't actually use numeric types to store values, they use strings
by Etheryte 3y ago
Perhaps I'm the odd one out here, but most financial systems I've had the chance to work with don't actually use numeric types to store values, they use strings or other comparable types. Numeric values are passed to all outside interfaces, but the internal states are written in a way where no bit level issues peddle with the values. I'm wondering what the experience of the wider audience here is?
- alexvitkov 3y agoIf by "bit-level issues" you mean bit flips (which you should be worried about), a string doesn't help much - "4" is 0x34 ASCII/UTF-8, flip lowest bit and you get "5" (0x35). I'd imagine if I have to protect against bit-level fuckery something like this would be a better representation: struct Dough { u64 amount; u64 amount_again; u64 amount_just_to_be_really_sure; } that and hardware-level protection of course
- rvnx 3y agoStoring the same element the same way isn't really helping against implementation bugs, if going that route, better store in multiple formats (u64, int, or string), to protect yourself from a CPU or interpreter or library bug. In practice, just store the amounts as integer, and if you are really worried, add a checksum (if total balance is not enough).
- DamonHD 3y agoThat pretty much guarantees being the victim of multiple coding bugs...
- alexvitkov 3y agoMaybe, if you're an incredibly bad programmer. Add operator overloading and method to extract the number and you never have look at the internals again.
- GTP 3y agoI think what OP's talking about aren't sw bugs, but rather hw errors like a bit flip caused by an external interference.
- marcosdumay 3y agoThat's the kind of thing for what error correction codes were invented.
- Izkata 3y agoThey're talking about floating point precision issues, same thing as the article, and explaining another way to deal with it that doesn't require thinking as low-level as bits like the article is mainly talking about.
- dahfizz 3y agoSounds slow as hell, what kind of financial systems have you worked with? I write trading software, and pretty much everyone uses integers with implied decimal place, similar to TFA. How do you know you convert your internal string to a float/int correctly? You have to deal with the numeric types eventually
- tombert 3y agoI've never written any trading software, but out of curiosity, have you done any tests comparing something like a GMP arbitrary-precision number vs a raw integer type. Obviously the raw integer (64 bit or 128 bit) will go faster since it would have CPU-level assistance, but I'm curious to what that actually ends up being in practice, especially at the scale of trading. Is it 10% faster? 10X faster? Somewhere in between?
- DamonHD 3y agoNot true for any of the finanical systems I've worked for the credit/derivatives/FI/etc desks of some of the largest investment banks down to the systems for the virtual card e-money issuer in the UK that I founded.
- rvnx 3y agoThey use integers to store cents or fraction of cents, and that's it (or the equivalent of MySQL "DECIMAL" format if not using integers)
- DamonHD 3y agoWhen you say "they" I could tell you exactly what format we stored card balances in, including the implied point position for different currencies (not the same for GBP and (say) JPY) and none of it involved DECIMAL!
- rvnx 3y ago> They use integers to store cents or fraction of cents or DECIMAL as alternative if not using integers Seemed rather clear, what's difference with what you say ?
- DamonHD 3y agoI referred to 'they' for my clients and start-up. You seemed to be making claims about those particular implementions, which seemed a bit odd.
- fancyfredbot 3y agoDerivatives are generally subject to some fairly large uncertainty in valuation, for example bid/offer spreads are usually many orders of magnitude larger than floating point error. When the derivative expires it does have some very fixed value but the investment bank will have made enough money off the trade to "generously" round up the float to the nearest cent.
- kawhah 3y agoI have never encountered such a system. Integers used for fixed-point representation do not suffer from "bit-level issues".
- amadvance 3y agoIs fixed-point the right term ? As far as I know fixed point numbers have a fixed fractional part in bits, but this is different from using integers with a multiplicative factor, like 100, to represent correctly a fractional part as 1/100.
- kawhah 3y agoNo it's not different, what you describe is exactly what fixed point is.
- wyldfire 3y ago> internal states are written in a way where no bit level issues peddle with the values ... "bit level issues"? you eventually are going to need to use those bits to add, multiply, subtract or divide the numbers. Using character strings to represent numbers is certainly one way to do arbitrary precision/ BigInteger (like the article describes). But you might want to postpone transcoding it to characters until you decide to export your numbers across a boundary. Otherwise all of the arithmetic operations you do have to suffer this round trip each time.
- dahfizz 3y agoA shocking number of devs are simply afraid of bits and bytes.
- alentred 3y agoOh, this does sound odd indeed. I can only assume this is very slow, and voluminous on the storage side. In a similar vein, the only "tricky" solution I saw once was a financial system that stored rational numbers as fractions, and used fractions for all computations too. A decimal point was only used for the final results (end-user UI, APIs, etc.). I still think it was a an overkill.
- kawhah 3y agoInteresting, were the denominators always powers of 10? Or any positive integer?
- paxys 3y agoThe financial systems you've used never needed to add two numbers together?