The only real correct solution here is to send mantissa and exponent as two separate integers. It's trivial to convert between exponents for whatever math you want, it can be as correct as you want, and is unambiguous.

In the HFT space you save some wire space if you can commit to a consistent exponent for some {slice} up front (think instrument/tick-size/asset-class/exchange/feed/server/whatever/...) such that you only need to send the mantissa and your clients can have a hard coded exponent. However, in similar spaces it's often worth the extra uint32 to send a on-the-wire exponent such that things _can_ change and you aren't hamstrung later by earlier "we only need cents now!" design choices when, e.g., you suddenly need to support bitcoin/... prices to full precision. (your users will thank you when they don't have to coordinate a breaking change when you want to adjust your fixed exponent)

▲

microgpt 6 hours ago | parent | next [-]

If you do that though aren't you just reinventing floating-point?

	▲	jjmarr 3 hours ago \| parent [-]
		No, because you're doing decimal floating point, which eliminates the rounding errors of binary floating point.

▲

lxgr 6 hours ago | parent | prev [-]

> The only real correct solution here is to send mantissa and exponent as two separate integers.

That’s essentially the same thing as a String-serialized big decimal, just less readable, no?

▲

gmm1990 4 hours ago | parent [-]

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

▲

lxgr 4 hours ago | parent [-]

True, but this is usually your least concern when you're dealing with monetary amounts/math.

	▲	mnahkies 3 hours ago \| parent [-]
		They specifically mentioned HFT so I suspect they care a lot about processing speed