((2^32)-1)/10000 assuming they don't care about negative equity price.

That's the exact same thing that repiret said, I think.

I think power (^) has higher precedence than subtract (-).

So (2^32-1)/10000 == ((2^32)-1)/10000

WolframAlpha agrees: https://www.wolframalpha.com/input/?i=%282%5E32-1%29%2F10000...

Honestly, I always found precedence rules horribly ambiguous. I just use brackets for clarity and forget about it. Or is this considered 'bad practice'?

I've never found it to be an issue with math. Unary minus > powers > multiplication/division > addition/subtraction.

I have seen differences in the precedence of logical operators between languages (and > or but what happens when you have both math and logic in the same statement isn't entirely consistent) and always use parenthesis in those cases--although these days if Resharper says it's redundant I let it remove them.

I don't consider it bad practice to insert parentheses, especially with exponentiation because many people are less familiar with its precedence rules.

I don't understand why this was down voted. It is an interesting comment!

I always assume the floor for equity is the first tick above zero, e.g., 1 US cent or 1 Euro cent or 1 Japanese yen. Honestly, I don't know if any traditional stock exchanges allow zero price or less for shares. If anyone knows an example, please post about it!

Another reason why this comment matters: Does anyone remember when oil futures went negative? (April 2020) I am sure more than a few computer systems were unprepared for that scenario. I remember when short-end Japanese rates were zero and negative after the 2008 Global Financial Crisis. It was a real monkey wrench in the machine!

There's a reason futures can go negative, that is when the contracts get close to expiry, the holder becomes legally liable to receive the oil. Since the speculators have no way to actually do this (and that storage was at capacity anyway), it makes sense to sell to shift the liability to someone else. There is not such analog for shares that I can see.

You wrote: <<the holder becomes legally liable to receive the oil>> Very good point! We should be clear for other readers: For many commodities futures, there are two types: physical and cash settle. (From my experience, liquidity can vary wildly!) Example: Physical oil futures require you to deliver (short)/receive (long) oil at expiry. Cash (settle) futures only require an exchange of cash at expiry.

Probably downvoted because 2^32-1 is the same as (2^32)-1, it's 2^(32-1) you're confused with. Although downvoting just for that feels a bit pedantic to me.

The the intention of both comments was clear... To discuss signed vs unsigned integer.

If they were storing it in a signed 32-but integer, it would have already overflowed.

They could also be applying an arbitrary offset to support some range of negative value. This whole tangent seems a bit pedantic though. :-) They probably should have used uint64!

Or perhaps just move to arbitrary-length integers. (Eg what Python gives you by default.) Or even rational numbers.

Both are a bit slower than using ints built into the machine, but exchanges don't have to be particularly fast. (In contrast to HFT participants. But they just need to be faster than their competitors.)

My suspicion is that the field is a fixed size for serialization inside a database table or something. Truly variable length fields are trickier to store and then subsequently iterate over non-sequentially.

When you say rational numbers, do you literally mean a fraction, or are you talking about a floating point representation? I'm not sure what a fraction would do over fixed point in this usage, and floating point is best avoided for anything finance related due to the fact that they're approximate.

They probably regret not just using 64-bit from the start, but on the other hand somebody likely saved a measurable amount of money on storage over the years. Potentially not worth the cost to figure out a workaround now, though.

Perhaps they could implement a rule where if the field equals MAX_UINT32, then the value must be looked up in an auxiliary database table. Depending on how much crufty code there is assuming 32-bit though, it may be their equivalent of y2k.

I meant a genuine fraction. So you have arbitrary precision.

Yes, variable length fields are a bit annoying. But my argument is that the exchange itself doesn't need to be that fast. And the market makers just need to be faster than each other.

(For anyone else, exchanges just need to be fast enough.)

Yes, just using a 64 bit integers is probably the easiest here.

Floats would be worse than my suggestion to use variable length rational numbers, for exactly the reasons you know.