Knight lost a sum that was a large fraction of their market value... So what's your problem exactly?
The fact that any trades were reversed at all.
Well, make up your mind man! Are you mad about HFT not losing money (false), or are you mad about the uniform volatility guards which NYSE, NASDAQ, and all of the other stock exchanges have agreed upon?
A possible first step would be to make the companies fully responsible when there's a software glitch.
Agreed. Do you mean only trading clients, or the exchanges as well? NASDAQ set aside some cash to compensate traders who received untimely execution in the Facebook IPO, but the amount is not expected to cover all losses so from a financial perspective they still are not taking "full" responsibility. Or there's UBS, who (stupidly!) submitted more orders for FB when their earlier orders were not acknowledged (stuck in-flight) and ended up getting filled on all orders. They started litigation to recover those trading losses.
They canceled some of the orders -- if they do that for everyone, then OK, but HFTers shouldn't get any preferential treatment.
There was no preferential treatment. Trade cancellations were done based on price deviance beyond a deterministic cutoff (on 6 names, IIRC). The $440 million lost was trading within the cutoff across ~150 names.
[GoDaddy's] CEO brags about security being for cadavers,
If you read the context on his own website you should understand that by "security" he is referring to personal comfort zone, as in "take more risks with your life/business" and the proverbial risk/reward trade-off, in contrast to network/system security which is a risk/convenience trade-off. There are enough examples with which to highlight his sleaziness that you don't need this "security" lie to pin him to the wall.
Apologies in advance if English is not your primary language.
Man, I wish I had the capital at the time to short sell the fuck out of FB.
If it makes you feel better, there are such heavy restrictions on short-selling new issues (within 30 days of IPO) that you probably wouldn't have had the opportunity even if you had the capital.
Please explain how a doubly linked list now makes add & remove O(1).
Suppose you have a collection of unit objects, and your main game loop involves iterating through each of them and performing some time-step (move, regenerate energy or health, cooldown weapons, etc.) Now at any point in the "simulation" that is an RTS game, a single unit decides/discovers that it must be deleted. If you are already iterating over units in a doubly-linked list, it is exactly 2 pointer operations for the unit to remove itself from the master list. If you had used a singly-linked list you would need to spend O(N) time searching for the previous unit.
Oh, and given that you're already iterating over every single unit in the game, you don't need the random lookup that a hashtable provides. Actually, you probably can't afford the lookup table unless it is already solving another problem for you. CPU cycles and cache footprints matter when you want to push the limits of the hardware.
Heard of it? I remember living it in high school! I think at the time it was a 2.1GB drive and then the next size up. And "kibibytes" was still dog food, not an overindulgent unit of measurement. Ah, the days...
Net Neutrality is NOT treating all packets the same. VoIP and Video are among those applications that are time sensitive. You need to apply QoS to prioritize that type of traffic.
Thank you! Many people conflate protocol-favoritism with endpoint-favoritism and (wrongly) conclude that routers should be dumb and never prioritize in order to enforce NN. The difficulty that I run into on this topic is that there seems to be a slippery slope due to the privacy implications of effective QoS. For examle:
Streaming video over HTTP is more important than a large file download over HTTP, but you may need to peek at HTTP headers or even the file content in order to distinguish between the two.
Video games frequently run over nonstandard ports but have characteristic signatures for UDP traffic. Should deep packet inspection be used to keep most/all video games at high priority? What if the DPI has even a minor impact on overall throughput/latency?
QoS works best by throttling outbound traffic, rather than discarding inbound traffic. For wired traffic this can be done at a cable modem, DSL mode, or some switch local to the customer. For metro-wide wireless traffic (i.e. a MAN 3G, 4G, what-have-you) is it acceptable for the ISP to require its traffic shaper to be running on connected devices?
I'm uncertain about the answers to these questions, and I have familiarity with the domain. I fear legislation which is enacted by lawyers and written by a legion of Grima Wormtongues.
Grandma users don't need enormous bandwidth, like video and games require...
I am not trying to disagree with your main point here, but many networked games are low-bandwidth. Why? High bandwidth requirements inevitably leads to increased likelihood of packet loss, which leads to latency spikes, which leads to perceived lag and inconsistent performance in the game. This is death for a FPS or similar "twitch" game.
I've heard they don't use anaesthetic for some strange baby-physiology-based reason, and that horrifies me.
My memory may be failing me, but I think there was a weak local anesthetic applied. Mostly I remember that there was a little oral dose of sugar-water, which is standard for infant pain-relief in hospitals. Really, I have seen much worse expressions of pain in my child from mundane GI stuff like gas and reflux.
I am not associated with the makers of f.lux in any way except being a hopeless devotee and mentioning them to anyone within earshot that mentions difficult keeping a normal sleep cycle.
We make compromises for accuracy all the time in computation. The use of floating point numbers is one such case.
I agree. The AC's comment which is blatantly wrong is more specific:
part of optimization is refactoring math equations in the code for shortest execution period.
High-performance numerical algorithms are written with the expectation of a well-behaved compiler which will not attempt to refactor mathematical expressions on the basis that it may change the numerical error. The mathematicians who write these algorithms understand how the error accumulates, so their order-of-operations will be tailored accordingly.
Any acceptable compiler by todays standards must be capable of optimization, and part of optimization is refactoring math equations in the code for shortest execution period.
No acceptable compiler refactors math equations in a way that breaks numerical accuracy, unless the user explicitly requests it (gcc's -funsafe-math-optimizations comes to mind). Optimizing compilers are useless if they give the wrong answers for the most compute-intensive problems.
such regulations are there solely for the reason of "providing equal service to everyone"
This is similar to protocol-based QoS which ensures that VoIP or other latency-sensitive streams take priority over latency-insensitive streams. Yet such a mechanism may be blocked in some people's visions of net neutrality.
The power and water companies do just fine providing equal service to everyone.
Electricity and water are both fungible; bits of data are not. The bandwidth may be fungible, but bandwidth will always be traffic-shaped for QoS (e.g. VoiP > HTTP > FTP), so while it's similar it's not exactly the same.
Neither the government nor the water suppliers tell people what they can and cannot do with their water.
This is a bad example; plenty of municipalities have water regulations during summers or droughts.
they just fucking hate other people being on the phone. I'm sure there's some kind of reason for this
The reason is that the cell-phone conversationalist is showing disregard toward other drivers, cyclists, and pedestrians. Other distractions can be equally hated (e.g. applying makeup or eating) but cell phone usage is an easy target for ire. In any case, a distracted driver represents a hazard and an inconvenience for other drivers.
The statistics presented in TFA don't lie, but they also don't tell the whole story. They only measure collisions, which are relatively infrequent and more or less represent a 'total failure' (neither driver avoided the other). The rationale of the haters is relevant for you, because you share a society and a government with them.
I've felt for over a decade the police should have license plate scanners. Then when they tie it into a database of stolen cars, or cars used in recent untried crimes, it would come up as a positive, and the cop could pull the car over.
I don't see a problem with that, either. Real-time scanning and correlation automates the lookups they are already doing. The problem is when the cops build up a database of all license plates instead of just "hot" vehicles. Persistent storage enables chilling new "research" which tempts abuse while offering very little marginal benefit.
Please link the original XKCD comic instead of some random blog. In addition to being more respectful to the original author, it preserves the mouseover text which is relevant to the conversation at hand.
If the trading is going along at such a fast pace, is the software weighted to hold my particular sell so that an investor who has more influence gets sold first? And therefore in a selling frenzy, is harmed less? Just a few milliseconds makes the difference.
If milliseconds matter but your executions are going through a broker, I think it's safe to assume that you're talking about stop-loss orders here. Normal limit orders from retail traders are not sensitive to millisecond-level delays at the broker, as they are already typically delayed by the Internet connection, human trading decisions, and possibly even quote delays (i.e. reacting to the 20-minute delayed quotes publicly available, or reacting to "breaking news" from the media). Given that basis, I think it is a valid complaint if brokerages are not sending stop-loss orders to the exchange in time-price priority. However, you can mitigate that risk by sending stop-limit orders, where you can set your worst possible execution price.
Thank you for the links. I'm interested in looking into some of those single-stock events, but that takes some time so I can't really comment about any of them at the moment. Regarding the Nanex E-mini graphs, the 15:56 reduction in liquidity looks characteristic of a large market maker shutting down. Their astonished "one year ago the same thing happened!" observation suggests that there is something special about the end of July, perhaps either by convention or perhaps due to some relationship with options expiries. Supposing that were the case, it wouldn't surprise me to see large market makers pulling out early, just to avoid the risk. All in all, a 3-point move from someone dumping into the close really isn't a crash. Old-school pit traders could have done the same thing (dumped into the close), and whether it took 3 seconds or 30 seconds it would have been too fast for non-professionals to react. Remember, Yahoo! and Google give the public free quotes only after a 20 minute delay!
I'm familiar with Zero Hedge, Nanex, and Themis Trading. Nanex does find some interesting tidbits, but the other two seem to focus on fear-mongering and excessive use of weasel words in a way that reminds me of the "whip and buggy industry" story.
Well, make up your mind man! Are you mad about HFT not losing money (false), or are you mad about the uniform volatility guards which NYSE, NASDAQ, and all of the other stock exchanges have agreed upon?
Agreed. Do you mean only trading clients, or the exchanges as well? NASDAQ set aside some cash to compensate traders who received untimely execution in the Facebook IPO, but the amount is not expected to cover all losses so from a financial perspective they still are not taking "full" responsibility. Or there's UBS, who (stupidly!) submitted more orders for FB when their earlier orders were not acknowledged (stuck in-flight) and ended up getting filled on all orders. They started litigation to recover those trading losses.
There was no preferential treatment. Trade cancellations were done based on price deviance beyond a deterministic cutoff (on 6 names, IIRC). The $440 million lost was trading within the cutoff across ~150 names.
If you read the context on his own website you should understand that by "security" he is referring to personal comfort zone, as in "take more risks with your life/business" and the proverbial risk/reward trade-off, in contrast to network/system security which is a risk/convenience trade-off. There are enough examples with which to highlight his sleaziness that you don't need this "security" lie to pin him to the wall.
Apologies in advance if English is not your primary language.
If it makes you feel better, there are such heavy restrictions on short-selling new issues (within 30 days of IPO) that you probably wouldn't have had the opportunity even if you had the capital.
Yes, but how do you hedge your counterparty risk?
Suppose you have a collection of unit objects, and your main game loop involves iterating through each of them and performing some time-step (move, regenerate energy or health, cooldown weapons, etc.) Now at any point in the "simulation" that is an RTS game, a single unit decides/discovers that it must be deleted. If you are already iterating over units in a doubly-linked list, it is exactly 2 pointer operations for the unit to remove itself from the master list. If you had used a singly-linked list you would need to spend O(N) time searching for the previous unit.
Oh, and given that you're already iterating over every single unit in the game, you don't need the random lookup that a hashtable provides. Actually, you probably can't afford the lookup table unless it is already solving another problem for you. CPU cycles and cache footprints matter when you want to push the limits of the hardware.
Heard of it? I remember living it in high school! I think at the time it was a 2.1GB drive and then the next size up. And "kibibytes" was still dog food, not an overindulgent unit of measurement. Ah, the days...
-fno-access-control
Muahaha...
Thank you! Many people conflate protocol-favoritism with endpoint-favoritism and (wrongly) conclude that routers should be dumb and never prioritize in order to enforce NN. The difficulty that I run into on this topic is that there seems to be a slippery slope due to the privacy implications of effective QoS. For examle:
I'm uncertain about the answers to these questions, and I have familiarity with the domain. I fear legislation which is enacted by lawyers and written by a legion of Grima Wormtongues.
I am not trying to disagree with your main point here, but many networked games are low-bandwidth. Why? High bandwidth requirements inevitably leads to increased likelihood of packet loss, which leads to latency spikes, which leads to perceived lag and inconsistent performance in the game. This is death for a FPS or similar "twitch" game.
My memory may be failing me, but I think there was a weak local anesthetic applied. Mostly I remember that there was a little oral dose of sugar-water, which is standard for infant pain-relief in hospitals. Really, I have seen much worse expressions of pain in my child from mundane GI stuff like gas and reflux.
Thanks, I am trying this out now.
Either I'm taking you too literally, or you're doing it wrong.
I agree. The AC's comment which is blatantly wrong is more specific:
High-performance numerical algorithms are written with the expectation of a well-behaved compiler which will not attempt to refactor mathematical expressions on the basis that it may change the numerical error. The mathematicians who write these algorithms understand how the error accumulates, so their order-of-operations will be tailored accordingly.
No acceptable compiler refactors math equations in a way that breaks numerical accuracy, unless the user explicitly requests it (gcc's -funsafe-math-optimizations comes to mind). Optimizing compilers are useless if they give the wrong answers for the most compute-intensive problems.
The parent's post is clearly a refutation of half of this statement you made earlier:
These Naperville, IL year-round watering restrictions are pretty mundane.
This is similar to protocol-based QoS which ensures that VoIP or other latency-sensitive streams take priority over latency-insensitive streams. Yet such a mechanism may be blocked in some people's visions of net neutrality.
Electricity and water are both fungible; bits of data are not. The bandwidth may be fungible, but bandwidth will always be traffic-shaped for QoS (e.g. VoiP > HTTP > FTP), so while it's similar it's not exactly the same.
This is a bad example; plenty of municipalities have water regulations during summers or droughts.
The reason is that the cell-phone conversationalist is showing disregard toward other drivers, cyclists, and pedestrians. Other distractions can be equally hated (e.g. applying makeup or eating) but cell phone usage is an easy target for ire. In any case, a distracted driver represents a hazard and an inconvenience for other drivers.
The statistics presented in TFA don't lie, but they also don't tell the whole story. They only measure collisions, which are relatively infrequent and more or less represent a 'total failure' (neither driver avoided the other). The rationale of the haters is relevant for you, because you share a society and a government with them.
I don't see a problem with that, either. Real-time scanning and correlation automates the lookups they are already doing. The problem is when the cops build up a database of all license plates instead of just "hot" vehicles. Persistent storage enables chilling new "research" which tempts abuse while offering very little marginal benefit.
Please link the original XKCD comic instead of some random blog. In addition to being more respectful to the original author, it preserves the mouseover text which is relevant to the conversation at hand.
If milliseconds matter but your executions are going through a broker, I think it's safe to assume that you're talking about stop-loss orders here. Normal limit orders from retail traders are not sensitive to millisecond-level delays at the broker, as they are already typically delayed by the Internet connection, human trading decisions, and possibly even quote delays (i.e. reacting to the 20-minute delayed quotes publicly available, or reacting to "breaking news" from the media). Given that basis, I think it is a valid complaint if brokerages are not sending stop-loss orders to the exchange in time-price priority. However, you can mitigate that risk by sending stop-limit orders, where you can set your worst possible execution price.
Thank you for the links. I'm interested in looking into some of those single-stock events, but that takes some time so I can't really comment about any of them at the moment. Regarding the Nanex E-mini graphs, the 15:56 reduction in liquidity looks characteristic of a large market maker shutting down. Their astonished "one year ago the same thing happened!" observation suggests that there is something special about the end of July, perhaps either by convention or perhaps due to some relationship with options expiries. Supposing that were the case, it wouldn't surprise me to see large market makers pulling out early, just to avoid the risk. All in all, a 3-point move from someone dumping into the close really isn't a crash. Old-school pit traders could have done the same thing (dumped into the close), and whether it took 3 seconds or 30 seconds it would have been too fast for non-professionals to react. Remember, Yahoo! and Google give the public free quotes only after a 20 minute delay!
I'm familiar with Zero Hedge, Nanex, and Themis Trading. Nanex does find some interesting tidbits, but the other two seem to focus on fear-mongering and excessive use of weasel words in a way that reminds me of the "whip and buggy industry" story.
Can you back this up with facts? A list of timestamps (or hell, even dates) would be a start. More than just May 6, please.
They bought at the offer and sold at the bid, over and over again. They definitely handed that money over to other market makers.