If you do that though aren't you just reinventing floating-point?
replyNo, standard floating point implementations have higher precision for smaller numbers than larger. So for example, in a 32bit float, there are far more numbers between 0-1 than there are between 1,000,000 and 1,000,001. For 32bit floats, you start lowing whole integers with relatively small numbers.
replyIntegers have a consistent precision across the entire number line.
No, because you're doing decimal floating point, which eliminates the rounding errors of binary floating point.
reply> The only real correct solution here is to send mantissa and exponent as two separate integers.
replyThat’s essentially the same thing as a String-serialized big decimal, just less readable, no?
That’s quite a bit slower to process. At least if you’re converting to integers to do the calculations and the calculations would be quite a bit slower if you kept the big decimal type
replyTrue, but this is usually your least concern when you're dealing with monetary amounts/math.
replyI guess I’m coming at it from an optimizing market data provider perspective once you preallocate memory the next thing to optimize is the string decimal conversion if the feed isnt binary encoded
replyIt might be your least concern, and that's fine but it's not the least concern for many people who need to process large volumes of transactions.
replyMoney, even within fintech, is a concept used across a wide variety of domains, and you can't assume that what concerns you is what concerns everyone else relying on it elsewhere.
They specifically mentioned HFT so I suspect they care a lot about processing speed
reply