By continually extracting money from the exchange without injecting value, they reduce the overall value of the stocks... the best solution would be for legitimate companies to not allow their stocks to be traded on exchanges that permit HFTs. It would keep their stock values higher...
This is a weird analysis. HFTs are market-neutral, meaning they are trying to avoid taking any big directional bets. Because they are buying and selling symmetrically, they tend to have very little impact on long-term market prices. Instead, their profit comes from buying low and selling high on average, meaning that they are profiting at the expense of their trading counterparties. At the end of the day, the value of the stock should be unchanged by HFTs. Except when their systems go bonkers, a la Knight Capital.
Per transaction fixed cost is the way to go if the goal is to discourage frequent trades.
Most transaction taxes discussed are a percentage of the notional value of the transaction (price * quantity, e.g. 100 shares of a $4 stock is $400 notionally). So Sweden's 1% tax could have easily been 1% of the value of the transaction, which is not at all stupid. In general, a transaction tax can be a function of the notional value of the transaction, quantity of the transaction (shares or contracts), or fixed per transaction; and in any case it will discourage frequent trading.
You are definitely moving the goalposts, but I will play along. Wikipedia names several products which use Infiniband, mostly for storage (not a surprise that NAS systems want high-bandwidth interconnects). On the HPC side, Los Alamos National Lab has IBM's Roadrunner cluster, which uses Infiniband.
Finally, your underlying objection sounds a lot like "640k ought to be enough for anybody." Why wouldn't we want networks to get better? IB may eventually go the way of Betamax (there are other competing low-lateny/high-bandwidth interconnects out there), but even so it is currently providing value and pushing engineering boundaries.
Getting back to the original topic, I don't think HP deserves much credit for pushing IB. The customers whose needs are met by it are probably already working directly with all of the vendors in the chain: IBM or Intel for chips, HP or Dell for the base systems and BIOS, Mellanox and Cisco for networking, etc.
please name 2 environments that actually benefited from using Infiniband
HPC clusters and cloud providers. Several financial exchanges (CME, NASDAQ) appear to be in the process of adopting Infiniband, but every reference I see sounds like a press releases from Mellanox and not yet a demonstrable application.
Nurses are likewise professionally regulated. In their particular sub-field, they are much closer to doctors than they are to laypersons. A better analogy for Uber drivers would be a CNA.
What you describe is not arbitrage. Arbitrage would be buying stock on one exchange and selling it on another without knowing jack about the order book.
What I am describing is exactly arbitrage. There is not one order book, there are fourteen order books (one per exchange). When one order book gets cleared out, the arbitrageurs make a bet that the other order books will get cleared out as well, so they take on the position with the hope of now being long at the new bid, or short at the new ask. They do not know that the other books will get cleared out, because they don't know if you wanted e.g. all 22,000 Intel shares, or just 2,000 (which just so happened to clear out 3 exchanges, but not the others).
This is definitely a problem for large executions: you move the price before you are done with your whole "trade". This has always been a problem for executing orders larger than the current top-of-book. It is made worse because there are so many exchanges, but also because some of them are so darned fast that HFT systems can beat brokers' order routers. You could argue that there should be a delay in publishing market data to ensure that routers can compete. You could also argue that it doesn't make sense for fourteen exchanges to exist, with regulation that merely attempts to paper-over fundamental natural laws (simultaneity). But you can't argue that it is not arbitrage.
Obviously what they are doing is not illegal as they are still doing it. They are very good at gaming the system.
There exist regulations to establish a "National Market", but the reality is that right now there are 14 different exchanges*, and therefore 14 independent order books to participate in. The HFT that you object to in particular is the style that performs arbitrage among the order books. If you think that arbitrage is front-running, you should start complaining to the SEC about the massive fragmentation in the US stock market which creates this situation in the first place.
* NYSE, NYSE ARCA, NYSE MKT (formerly the American Stock Exchange), NASDAQ, NASDAQ PSX (formerly the Philadelphia Stock Exchange), NASDAQ BX (formerly the Boston Stock Exchange), NSX (formerly the Cincinnati Stock Exchange), CBOE, Chicago Stock Exchange, BATS, BATS-Y, EDGX, EDGA, and now LavaFlow. Notice that's 14 exchanges with three owned by NYSE, three owned by NASDAQ, two owned by BATS, two owned by DirectEdge. Clearly market fragmentation benefits the exchanges.
Front running may be illegal but you don't see many prosecutions for it.
For firms paying for retail order flow, I expect front-running is not worth the risk of getting caught. Why bother front-running when they can just pick which retail orders to be the counterparty against? And if they route the "toxic" retail orders to the open market, they could conceivably generate their own orders and send them after the retail order to a different exchange, and potentially still trade before the retail order trades (violating the spirit—but not the letter—of the regulations). I think it would be hard to build a case against a "well-done job".
Better yet, how about a tiny tiny tax on each trade?
Such a thing exists, but under a different name: SEC Section 31 Assessments amount to a tax on sales to fund the SEC's activities. As market volume is constantly changing, the rate is periodically updated; the current rate is $17.40 per $1 million sold (notional value, so price × quantity). This assessment is applied to all sales, so it behaves as a tax on HFT (half of whose volume is sales on a given day, so they can go home without a position). Right now the rate is only adjusted for budgeting and volume predictions, but it could conceivably be used as a punative measure against excessive trading. If it was adjusted by a large amount, you can expect that market spreads would widen accordingly and total trading volume would drop. I think the rate could probably go higher than the current value without much impact, but there's definitely a tipping point where the "friction" from the assessments would cause major liquidity problems. For scale, consider that a 1% tax on the notional value of all trades would be one thousand times larger than the current Section 31 rate.
For example I've heard that the Canadian tar sands oil production requires a minimum price of around $85/barrel to be viable. If we start digging up oil shale it's got to be a lot more than that.
It's worse than that: more exotic sources of crude oil require more energy to extract—potentially more energy than is available in the oil itself! Because energy density is high from crude oil, it may make sense to "waste" energy in extraction because the result is useful as a transportation fuel, and also to stabilize relative prices between energy sources (e.g. spending cheap natural gas to produce expensive crude). But it still means that some energy extraction is a net loss, which is a very bad starting point.
If Walmart wants to buy bread from BreadCo, what are they going to pay for it with? Walmart gift cards?... This isn't a recipe for a stable economy, it's a mess.
I'm not sure what your point is with all of this. Your argument seems to be "if the US government disappears overnight, things fall apart." But that's not very constructive, because it's based on an extremely thin premise: immediate devaluation of USD to 0; no massive worldwide selloff, just *poof* it's gone. Furthermore, you don't seem to be able to see past the initial messy period. Sure, there will be a large barter economy. But that's not new, people have survived with barter economies in the past! So, something will appear to fill the USD void, and stability will slowly return. Because if it didn't, then we wouldn't be talking about this today. We would be trading goats and ball bearings, and murdering 70-year-old men in suits.
Well I do have to admit that when I took my Mac into the shop the guy at the Genius Bar didn't even blink when I told him it was running Linux. So none of this "you are running the wrong software" shenanigans there.
As a counter-example, I had "you are running the wrong wireless access point" problems from the Genius bar. My wife was seeing occasional DNS resolution failures and generally slow web browsing, which turned out to be packet loss between the laptop and the access point. At least two techs immediately argued that the problem must be the access point, and that we should replace it with an AirPort. It took four tries (phone calls and in-person) to find someone who would honor ping statistics from a variety of wireless devices.
I'm not saying Javascript is superior or inferior to C.
I'm not trying to argue that any language is better, either. I originally responded to this:
Name one other language that is as well supported and as broadly implemented as JavaScript?
and your subsequent reply moved the goalposts by arguing about deployment effort. Yes, you're right, C software requires more work to deploy to N platforms, but that is irrelevant to the presence of broad multi-platform support. I'm really not trying to say that C is better than Javascript. But surely it has a larger footprint across platforms!
I think it's safe to say that you prefer C to the exclusion of everything else.
Actually, no. I can read C fine, but I don't code fluently in it. I usually switch between C++, Python, and bash depending on the task.
Python has definitely replaced Perl where I work. It's also very quickly catching up to R (statistical/quantitative analysis), but from what I hear there is still a network effect keeping R on top for bleeding-edge research.
Yes, deployment requires compilation once per target. How many platforms exist which have a javascript interpreter but no C compiler? I believe my point stands.
Since nobody has offered any other languages to your challenge, I'll suggest Lua as a trivial alternative: the core language is implemented in ANSI C, so it is likely that Lua is portable to any platform that supports C. However, the core functionality of Lua is ridiculously hamstrung (ANSI C doesn't support sockets, for example) so the language is not well-suited for general-purpose programming.
Except on platforms that ban third-party native applications.
Even if the walled gardens don't permit software implemented in C, it is extremely likely that some part of the walled garden's own software stack is still written in C—because C is ubiquitous.
Many fighting games feature reaction windows no more than 5 ms wide, and some have windows ~1 ms wide. And players can hit them.
I've heard of fighting games (e.g. Street Fighter) with 1 frame windows, but the games were 60 fps ~ 16.67ms. That is more in line with your figures from John Carmack's experimentation. Your 1ms figure does not sound credible, can you provide a reference?
The PEP you quoted only applies to packages within the standard library. It also spends a few paragraphs warning against overzealous whitespace "harmonization". Even though a link to that PEP is extremely useful in this thread, please tone down the arrogance.
He made the case [why one should never use Python] very convincingly.
How so? It sounds like you and the AC are just looking for an excuse to whine. Let me explain again: I maintain a non-Python codebase with horrendous whitespace, and a Python codebase with consistent whitespace. The non-Python codebase is full of maintenance developers shitting on each other's indentation, and it makes future maintenance more expensive.
[whitespace] can't be discerned thoroughly via ordinary tools used in the ordinary way like cat,
How frequently do you look at code with cat, that invisible whitespace errors are a problem? It doesn't even paginate, ferchrissakes.
... less,
I have no solution on this one, but as a quick hack I would start by searching for tab characters, or more-than-one space characters. The terminal highlight should help.
... vi,
This works just fine in vim (not sure about vanilla vi):
:set list listchars=tab:\\_
That makes all hard tabs look like \___. Replace with prettier unicode line-art as you wish. I maintain a non-python codebase with some rather... creative... variations of whitespace, and it is trivial to match local whitespace conventions with listchars enabled.
... emacs
I'm not an emacs guy, but if vim has a solution then I'd put money on the existence of an emacs solution.
I never got a straight answer to how python deals with a mixture of tabs and space characters in the indenting.
I do work with python regularly, and I still can't answer this. The practical solution is "don't mix indentation styles." While it is more than zero effort to do this, it should be all up-front effort learning the capabilities of your tools, and trivial effort day-to-day.
In fact, it's very popular to pull over when rain/snow/fog is so thick.
It doesn't take much snow to cover lane markings, and pulling over is not a practical response to a fresh layer of snow. Snowfall is a different story, but snow on the ground is the problem at hand:
And now that white line is very reflective on almost all roads (speaking from the US at least), it seems that, if anything, we can tone down the headlights.
LEDs are hard in most places, but it is getting better.
I'm a fan of CREE can lights. High CRI, a good coating, and built-in trim makes them look better than the previous lights. I haven't had them very long, but so far they are handling brownouts better than anything with a ballast. The remaining CFLs tend to discolor (toward pink???) and dim significantly if they are not fed exactly the right voltage. The biggest downside is that the LEDs cost about 10s the cheapo "pink" CFLs, which adds up quickly. It will take years to see any cost savings even with 100% survival rate of the LEDs.
Slashdot Mirror
This is a weird analysis. HFTs are market-neutral, meaning they are trying to avoid taking any big directional bets. Because they are buying and selling symmetrically, they tend to have very little impact on long-term market prices. Instead, their profit comes from buying low and selling high on average, meaning that they are profiting at the expense of their trading counterparties. At the end of the day, the value of the stock should be unchanged by HFTs. Except when their systems go bonkers, a la Knight Capital.
Most transaction taxes discussed are a percentage of the notional value of the transaction (price * quantity, e.g. 100 shares of a $4 stock is $400 notionally). So Sweden's 1% tax could have easily been 1% of the value of the transaction, which is not at all stupid. In general, a transaction tax can be a function of the notional value of the transaction, quantity of the transaction (shares or contracts), or fixed per transaction; and in any case it will discourage frequent trading.
You are definitely moving the goalposts, but I will play along. Wikipedia names several products which use Infiniband, mostly for storage (not a surprise that NAS systems want high-bandwidth interconnects). On the HPC side, Los Alamos National Lab has IBM's Roadrunner cluster, which uses Infiniband. Finally, your underlying objection sounds a lot like "640k ought to be enough for anybody." Why wouldn't we want networks to get better? IB may eventually go the way of Betamax (there are other competing low-lateny/high-bandwidth interconnects out there), but even so it is currently providing value and pushing engineering boundaries.
Getting back to the original topic, I don't think HP deserves much credit for pushing IB. The customers whose needs are met by it are probably already working directly with all of the vendors in the chain: IBM or Intel for chips, HP or Dell for the base systems and BIOS, Mellanox and Cisco for networking, etc.
HPC clusters and cloud providers. Several financial exchanges (CME, NASDAQ) appear to be in the process of adopting Infiniband, but every reference I see sounds like a press releases from Mellanox and not yet a demonstrable application.
Nurses are likewise professionally regulated. In their particular sub-field, they are much closer to doctors than they are to laypersons. A better analogy for Uber drivers would be a CNA.
What I am describing is exactly arbitrage. There is not one order book, there are fourteen order books (one per exchange). When one order book gets cleared out, the arbitrageurs make a bet that the other order books will get cleared out as well, so they take on the position with the hope of now being long at the new bid, or short at the new ask. They do not know that the other books will get cleared out, because they don't know if you wanted e.g. all 22,000 Intel shares, or just 2,000 (which just so happened to clear out 3 exchanges, but not the others).
This is definitely a problem for large executions: you move the price before you are done with your whole "trade". This has always been a problem for executing orders larger than the current top-of-book. It is made worse because there are so many exchanges, but also because some of them are so darned fast that HFT systems can beat brokers' order routers. You could argue that there should be a delay in publishing market data to ensure that routers can compete. You could also argue that it doesn't make sense for fourteen exchanges to exist, with regulation that merely attempts to paper-over fundamental natural laws (simultaneity). But you can't argue that it is not arbitrage.
There exist regulations to establish a "National Market", but the reality is that right now there are 14 different exchanges*, and therefore 14 independent order books to participate in. The HFT that you object to in particular is the style that performs arbitrage among the order books. If you think that arbitrage is front-running, you should start complaining to the SEC about the massive fragmentation in the US stock market which creates this situation in the first place.
* NYSE, NYSE ARCA, NYSE MKT (formerly the American Stock Exchange), NASDAQ, NASDAQ PSX (formerly the Philadelphia Stock Exchange), NASDAQ BX (formerly the Boston Stock Exchange), NSX (formerly the Cincinnati Stock Exchange), CBOE, Chicago Stock Exchange, BATS, BATS-Y, EDGX, EDGA, and now LavaFlow. Notice that's 14 exchanges with three owned by NYSE, three owned by NASDAQ, two owned by BATS, two owned by DirectEdge. Clearly market fragmentation benefits the exchanges.
For firms paying for retail order flow, I expect front-running is not worth the risk of getting caught. Why bother front-running when they can just pick which retail orders to be the counterparty against? And if they route the "toxic" retail orders to the open market, they could conceivably generate their own orders and send them after the retail order to a different exchange, and potentially still trade before the retail order trades (violating the spirit—but not the letter—of the regulations). I think it would be hard to build a case against a "well-done job".
Such a thing exists, but under a different name: SEC Section 31 Assessments amount to a tax on sales to fund the SEC's activities. As market volume is constantly changing, the rate is periodically updated; the current rate is $17.40 per $1 million sold (notional value, so price × quantity). This assessment is applied to all sales, so it behaves as a tax on HFT (half of whose volume is sales on a given day, so they can go home without a position). Right now the rate is only adjusted for budgeting and volume predictions, but it could conceivably be used as a punative measure against excessive trading. If it was adjusted by a large amount, you can expect that market spreads would widen accordingly and total trading volume would drop. I think the rate could probably go higher than the current value without much impact, but there's definitely a tipping point where the "friction" from the assessments would cause major liquidity problems. For scale, consider that a 1% tax on the notional value of all trades would be one thousand times larger than the current Section 31 rate.
It's worse than that: more exotic sources of crude oil require more energy to extract—potentially more energy than is available in the oil itself! Because energy density is high from crude oil, it may make sense to "waste" energy in extraction because the result is useful as a transportation fuel, and also to stabilize relative prices between energy sources (e.g. spending cheap natural gas to produce expensive crude). But it still means that some energy extraction is a net loss, which is a very bad starting point.
I'm not sure what your point is with all of this. Your argument seems to be "if the US government disappears overnight, things fall apart." But that's not very constructive, because it's based on an extremely thin premise: immediate devaluation of USD to 0; no massive worldwide selloff, just *poof* it's gone. Furthermore, you don't seem to be able to see past the initial messy period. Sure, there will be a large barter economy. But that's not new, people have survived with barter economies in the past! So, something will appear to fill the USD void, and stability will slowly return. Because if it didn't, then we wouldn't be talking about this today. We would be trading goats and ball bearings, and murdering 70-year-old men in suits.
If he murders people left and right and scares the fuck out of everyone else, then yeah I would stay off of his lawn.
As a counter-example, I had "you are running the wrong wireless access point" problems from the Genius bar. My wife was seeing occasional DNS resolution failures and generally slow web browsing, which turned out to be packet loss between the laptop and the access point. At least two techs immediately argued that the problem must be the access point, and that we should replace it with an AirPort. It took four tries (phone calls and in-person) to find someone who would honor ping statistics from a variety of wireless devices.
I'm not trying to argue that any language is better, either. I originally responded to this:
and your subsequent reply moved the goalposts by arguing about deployment effort. Yes, you're right, C software requires more work to deploy to N platforms, but that is irrelevant to the presence of broad multi-platform support. I'm really not trying to say that C is better than Javascript. But surely it has a larger footprint across platforms!
Actually, no. I can read C fine, but I don't code fluently in it. I usually switch between C++, Python, and bash depending on the task.
Oh god help us all, complex objects like integers?
Python has definitely replaced Perl where I work. It's also very quickly catching up to R (statistical/quantitative analysis), but from what I hear there is still a network effect keeping R on top for bleeding-edge research.
Yes, deployment requires compilation once per target. How many platforms exist which have a javascript interpreter but no C compiler? I believe my point stands.
Since nobody has offered any other languages to your challenge, I'll suggest Lua as a trivial alternative: the core language is implemented in ANSI C, so it is likely that Lua is portable to any platform that supports C. However, the core functionality of Lua is ridiculously hamstrung (ANSI C doesn't support sockets, for example) so the language is not well-suited for general-purpose programming.
Even if the walled gardens don't permit software implemented in C, it is extremely likely that some part of the walled garden's own software stack is still written in C—because C is ubiquitous.
C is ubiquitous.
I've heard of fighting games (e.g. Street Fighter) with 1 frame windows, but the games were 60 fps ~ 16.67ms. That is more in line with your figures from John Carmack's experimentation. Your 1ms figure does not sound credible, can you provide a reference?
The PEP you quoted only applies to packages within the standard library. It also spends a few paragraphs warning against overzealous whitespace "harmonization". Even though a link to that PEP is extremely useful in this thread, please tone down the arrogance.
How so? It sounds like you and the AC are just looking for an excuse to whine. Let me explain again: I maintain a non-Python codebase with horrendous whitespace, and a Python codebase with consistent whitespace. The non-Python codebase is full of maintenance developers shitting on each other's indentation, and it makes future maintenance more expensive.
How frequently do you look at code with cat, that invisible whitespace errors are a problem? It doesn't even paginate, ferchrissakes.
I have no solution on this one, but as a quick hack I would start by searching for tab characters, or more-than-one space characters. The terminal highlight should help.
This works just fine in vim (not sure about vanilla vi):
That makes all hard tabs look like \___. Replace with prettier unicode line-art as you wish. I maintain a non-python codebase with some rather... creative... variations of whitespace, and it is trivial to match local whitespace conventions with listchars enabled.
I'm not an emacs guy, but if vim has a solution then I'd put money on the existence of an emacs solution.
I do work with python regularly, and I still can't answer this. The practical solution is "don't mix indentation styles." While it is more than zero effort to do this, it should be all up-front effort learning the capabilities of your tools, and trivial effort day-to-day.
It doesn't take much snow to cover lane markings, and pulling over is not a practical response to a fresh layer of snow. Snowfall is a different story, but snow on the ground is the problem at hand:
I'm a fan of CREE can lights. High CRI, a good coating, and built-in trim makes them look better than the previous lights. I haven't had them very long, but so far they are handling brownouts better than anything with a ballast. The remaining CFLs tend to discolor (toward pink???) and dim significantly if they are not fed exactly the right voltage. The biggest downside is that the LEDs cost about 10s the cheapo "pink" CFLs, which adds up quickly. It will take years to see any cost savings even with 100% survival rate of the LEDs.