Hacker News Reader

Comment by Etheryte | Hacker News Reader

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?

View on HN

> 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.

A shocking number of devs are simply afraid of bits and bytes.

Sounds 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

I'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?

If 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

Storing 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).

That pretty much guarantees being the victim of multiple coding bugs...

Maybe, 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.

I think what OP's talking about aren't sw bugs, but rather hw errors like a bit flip caused by an external interference.

That's the kind of thing for what error correction codes were invented.

They'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.

Not 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.

They use integers to store cents or fraction of cents, and that's it (or the equivalent of MySQL "DECIMAL" format if not using integers)

When 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!

> 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 ?

I referred to 'they' for my clients and start-up. You seemed to be making claims about those particular implementions, which seemed a bit odd.

Derivatives 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.

Profit/margin was not larger than the ulp for single-precision float values for derivatives by the time I got there, so we all were using doubles.

The rounding-for-settlement issue that you describe is, I think, separate.

Single precision ulp is one part in ten million? I'm not sure which derivatives you worked with but that's an exceptionally small profit margin. For most derivatives a margin of one part in ten thousand would be considered small.

I have never encountered such a system. Integers used for fixed-point representation do not suffer from "bit-level issues".

Is 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.

No it's not different, what you describe is exactly what fixed point is.

Oh, 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.

Interesting, were the denominators always powers of 10? Or any positive integer?

The financial systems you've used never needed to add two numbers together?

Reply on news.ycombinator.com