That 32-bit price format is in the message protocol used by many NASDAQ customers.[1] The spec, though, says "Prices are integer fields,supplied with an associated precision. When converted to a decimal format, prices are in fixed point format, where the precision defines the number of decimal places. For example,a field flagged as Price(4) has an implied 4 decimal places. The maximum value of price(4) in Total View-•-ITCH is 200,000.0000 (decimal, 77359400 hex)."
This is a feed used in high-frequency trading. It's fixed format and intended to be read by FPGAs. Sent over UDP.
I wonder what they've been doing for BRK.A for that feed.
They probably just use BRK.B for most HFT involving BRK. The one-way transfer from Class A to B shares (and the different voting rights) reduces the supply of Class A shares due to a myriad of reasons. This makes the daily volume for Class A shares lower than Class B (when normalized by the trade ceiling imposed by Berkshire).
Google Finance has the worst corporate actions processing of any public source of market data. Their splits and mergers are wrong in a lot of cases, not just this exceptional one.
Make Berskshire Hathaway stock priced in 1/100th unit instead of 1/10,000th unit and the stock price can go 100 times higher and you don't have to change the existing data feeds - which would be quite expensive. All you have to do is send everyone the message that this stock symbol is priced in 1/100 units instead of 1/10000. Seems to me this would be the least-intrusive solution.
YTs counter had was even signed. So the first dirty fix was very easy, because there was an unused bit. This is different, because all bits are used in the stock price, so no easy dirty fix.
> The U.S. stock with the second-highest share price, home builder NVR Inc., is trading just above $5,100 a share.
Exchanges have a minimum stock price requirement for a stock to be listed. Seems reasonable that they should have a maximum too instead of redesigning the system for a single outlier.
Engineering is the art of tradeoffs. When there's a two orders of magnitude difference between the needs of one user of the system and all other users of the system, it's not laziness to decide the tradeoffs needed for that one user aren't worth it.
Storage of data that is usually but not ALWAYS in a shorter range is a complicated problem if you don't just throw more RAM at it.
Perhaps a CPU built around a base numeric type more like UTF-8 would be useful? Short values would take only a smaller amount of RAM but longer values would still work?
I suspect in the era of 64 bit CPUs that isn't much of an advantage anymore.
You don’t really need dedicated instructions for them. Programmers can do that today, and many decades in the past too, with software. For example, Java has BigInteger in the standard library for decades now.
The reason they did not is less about memory (it would save memory on average, many numbers in that system need less than 4 bytes) more about CPU time. That system is likely very old, older than wide adoption of 64-bit processors.
The reason we don’t often use variable-length integers now, memory and storage are cheap. For new software people simply use 64 or 128 bit integers.
Still, variable-length integers are widely used when storage or bandwidth matters. They are all over binary network protocols, multimedia containers, and media codecs.
Exchanges compete on speed. If exchange A delivers data in half the packet size and requires smaller word sizes to operate on and exchange B decides it's okay to double the packet size and requires twice the word size... exchange A gets the trade and exchange B is left holding the bag.
Back in the day the major exchanges, NASDAQ and NYSE in the U.S. and the TSX in Canada used to operate as a mafia with a monopoly on the stock market. Entire exchanges came into being strictly on the basis that they had lower bandwidth requirements and operated faster, such as BATS and DirectEdge (which ended up merging), CHI-X, Omega, and a host of competition emerged to actually focus on technology. They ended up taking a large chunk of market share away from the major exchanges.
Now NASDAQ and NYSE have since caught up, and in some ways they did so by buying out these competitors. Modulo some embarrassing glitches over the past few years, the major exchanges need to continue supporting their legacy systems for major institutions who are very slow and hesitant to upgrade any aspect of their technology.
NASDAQ has a more advanced and modern data feed and that feed doesn't have this issue, BRK.A is being reported properly at its price as we speak, but that feed isn't widely adopted except by firms that generally build their own technology and have a team that can keep their tech up to date. The feed that has this issue is like 20 years old now and rarely gets updates, and many firms like to keep it that way.
When I worked on a semi-similar problem (a realtime-ish feed with lots of numbers), we found that it was better to just eat the extra RAM costs.
Once you have variable width values, it gets much more expensive to answer questions like "Here's a file with every stock price, we know that Berkshire is the 1,000th one in the list, what is their current price?" Instead of being able to jump straight to the relevant bytes, you end up needing to parse (potentially) the entire file. Even with better CPU support for variable integer sizes, you're still essentially turning an O(1) operation into one that is O(N)
I wonder if a CPU could do something like have 9-bit bytes internally that would allow you to quickly jump over a list like that (use the 9th bit to indicate the first of a multi-byte sequence or something). You'd need dedicated hardware to make it as fast as 1000xRecordsize, though.
That's the typical approach to varints except optimized for hardware with 9-bit bytes. It's not the kind of thing that dedicated instructions can make faster, or we'd be using them all the time.
Processors have had BCD (binary coded decimal) instructions since the earliest 8-bit micros. They usually deal with 0-99 and then you have to add digit by digit but it can handle carry propagation.
Much earlier than that. The IBM/360 architecture had instructions for doing arithmetic with BCD numbers (packed and zoned decimal formats) in the mid-1960s. I think earlier IBM architectures had them too. COBOL natively supports that datatype, so did PL/I.
After all, the biggest customers for mainframes were banks, insurance companies, the IRS, etc. that dealt with large sums of money and needed their accounts to be accurate to the nearest cent. Dealing with very large integer values is a problem that was solved a long, long time ago.
>Perhaps a CPU built around a base numeric type more like UTF-8 would be useful? Short values would take only a smaller amount of RAM but longer values would still work?
BRK.A are "voting" shares. My understanding is that they want to keep the "voting pool" to be richer / upper class people.
Rumor is that the shareholders meeting is a giant party, a who's-who of the elite world. You can only have that culture if you have a very high barrier to entry. In any case, the high share price ensures a certain class of people in the voting pool: an old-school sense of community and elitism but... hey, you can't argue that it doesn't work.
BRK.B also votes, but with much-less voting power.
It isn't to discriminate on class (which is a definite side-effect), but rather to discriminate on time-horizon. Berkshire plays the long game and has taken great pains to attract/retain long-term shareholders. (As has, to an extent, Amazon)
Almost nobody can afford to day-trade BRK.A. Furthermore, most holders of A probably don't want to sell on any given day.
If you want to trade Berkshire on short timescales, B is available/liquid, but your votes don't count for much.
Buffet has said before that it's intentionally high to keep out short-term traders and inexperienced traders. He wants investors who will hold for long terms. If the price is so high, there's only a particular clientele that can afford to buy it.
They do have a different code of class b stock that is more affordable.
I read it's because he only wants the most absolutely committed investors owning shares, not superficial speculators. You would overthink if you had to spend that much on a single share.
Although modern platforms with their fractional shares might negate the advantage a bit.
One reason is that they now have the highest stock price and that's a cool selling point for BK. Not their only one, clearly, but a neat point to make.
One is reminded of the Isner–Mahut match at the 2010 Wimbledon Championships, where the scoreboard was limited to 47 games, and it went far over, and an IBM engineer had to work all night to fix it.
47 was over double the previous record, so everyone thought it was extremely low risk, and not worth worrying about. But it did happen.
Over ten years on and no other match has come close.
So, did they not realize this was a limitation of their system, they did realize it but they did not know BRK was going to hit the limits, or they knew both and just let it happen?
My guess is they didn't consider the possibility when they designed the system, and had forgotten the limitation existed by the time it became obvious that it would happen.
No they knew it but this particular feed having the issue is an older NASDAQ feed.
NASDAQ's newer feed doesn't have this issue but a lot of major institutions don't like updating their infrastructure so they stick to the older feed.
To be honest, it's not nearly as big of a deal as it's being made out to be. It's not a situation where NASDAQ was ignorant of this issue or neglectful, it's a situation where NASDAQ has to balance support for legacy systems by not doing a binary incompatible update to a protocol that has worked well for many users for 20 years... versus pushing older institutions to update to their newer technology which doesn't have these issues.
The fact that it only affects the old protocol might not comfort its users. Users have this crazy habit of not migrating. I remember when Reuters bought Bridge and they tried to announce they were deprecating the bridge feed protocol, twenty years ago, but it looks like you can still get Bridge feeds and Bridge Station to this very day.
I think they absolutely could, and the SEC would be OK with it, but BRK.A is listed on the NYSE, not the Nasdaq, so it doesn't have a contract with them. Like other US stocks, you can still trade it on other exchanges than the listing one.
If money wasn't so darn sacrosanct that you absolutely cannot destroy or create even a fraction of a cent... the solution would be to just use floats.
I know it's a big no-no, but I find it odd that we can live with limited precision in scientific computations (even have to), but can't when it comes to money.
Floats are used in finance for many applications. Most of the front office applications I've worked on use floats for money, because it's like science: the model is already off by more than floating point error.
The whole "NEVER use floats for money" thing is cargo culting. In this situation though I don't see why floats would be any better a solution than just using 64-bit integers.
It's more accurate to say "never use floats for accounting." You should be able to state with 100% certainty how much money you owe no matter how much money you owe.
I'll cede this point. If you're accounting for the quantity of pennies down to the precision of individual penny atoms then your accounting must be accurate to within the quantity of penny atoms that are rubbed off the penny during normal handling during the transaction.
In scientific computations, it is often sufficient that the final answer is correct to a few significant figures. There are several reasons for this. One is that the model uncertainty is typically quite large (unless you are dealing with particle physics). Another is measurement uncertainty. Except for some unique scenarios measurements aren't going to have more than a few significant figures as well. So there isn't a big difference between 3.14 and 3.14159 and pi to 100 decimals.
I'm sure one can think of plenty of counter examples, but I'll give an example where floating point numbers are used heavily and you don't typically don't care about minor rounding issues.
Computational chemistry can be used to predict the geometry of molecules. The model used to make this prediction has to describe the interactions between the atoms, which is computationally expensive (solving Schrodinger's equation). So often times the molecule is only modeled in a vacuum and not as a liquid (where there would be many other molecules included). All of these add up that even if there was no IEEE-754 floating point error, the answer would still maybe only be right to +/- 10%.
So science is quite different from finance, where the main goal is to converse a certain quantity. Money shouldn't be created or lost though rounding errors.
Sure, it's humorous and a little bit silly, but the issue is a real one, and this is a funny way to familiarize yourself with the tricks that can be played.
You cannot live with it in any system where agency can be taken because of how exploitable it is. If you set up a genetic algorithm in a life simulation and foolishly set it to use floating points "nature" will select for utilizing free energy as a matter of course.
HFT + floating point = economy crashed by duping inflation without real item duping
HFT programs absolutely use floating point, you don't have time to waste using rationals/fixed point/whatever. I've no idea where this misapprehension has come from, in my experience the more complicated the work you do in finance, the more you balk at the idea of not using floating point.
As some sibling comments suggest, not all finance is created the same. Trading systems often use floating point, but banking/accounting systems used fixed point.
The key is whether your system needs to tally up your monies into a known quantity and ensure it is all accounted for. If you summed up the transactions across a number of customer accounts at a bank for instance, it's critical that they all net out.
Yes, but consider how much volume there is in the stock market - doubling to a 64-bit integer would increase RAM and network volume, and there are plenty of downstream consumers who’d need to test this. None of that is intractable but there’s literally one company affected - the next highest share price is two orders of magnitude lower - so there must be a strong temptation to see what Buffett would want to do a split.
It's slightly mystifying they haven't done one already (and yes I know he wants people to buy and hold). This share is very... special in causing these problems and I'm actually surprised NYSE didn't make them do it some time ago.
Yes - I said 64-bit because that’s a natural size now and for high volume like this it seems likely that they’d prefer a fixed size to savings which make decode and recovery logic harder and less cache line efficient.
In this domain it is quite a bit of headroom. Normal companies just avoid the problem by splitting before they get even within two orders of magnitude.
So if this next-closest share price got closer to the limit, it would almost certainly split long before it became within one order of magnitude of the limit.
Normally issuers would just split the stock. When investors' systems break because your quote is 100x anyone else's you're just making everyone's job harder.
