brownegg

Correlations will tend towards 1 when using a large-enough time frame. On a microstructure scale, correlations go haywire in liquidity distress.

Which part of "buy and hold" includes "sell when it goes down"?

You're conflating two things (in my mind). L2 is very useful to people like me. If it's useful to you, you should be able to handle spoofing.

The "average investor" doesn't need L2, and doesn't care what it says, including flashing "fake" orders.

They don't get unnecessary volatility unless they're paying attention to the order book all the time. Realized equity volatility is MUCH MUCH MUCH lower in the era of HFT.

Yes, "flash crashes" exist, and normally because of liquidity disappearing. Yes, algos are basically sheep that all bail at the same time. But overall, the net effect is massively beneficial to everyone except lazy traders (which include fund managers who miss the days of getting lots of steak dinners from their favorite brokers).

Your question is exactly correct. As long as they are real orders, with real risk of being executed, there should be nothing at all wrong with this behavior. If people are so stupid as to move their orders trivially based on others' actions, they deserve what they get.

The reason this gets prosecuted is that it's an easy target for the exchanges to make it look like they care. They are now publicly-traded companies interested in profits first and foremost--not market integrity (which maybe used to be the case--different discussion).

source: 25-year vet of futures markets, the last 10 in HFT; many many millions of orders and executions

A senior/experienced person offering potentially-qualitatively-better "stuff" in the realm of something like code isn't the point. I'm sure there are exceptions, but in general no one is saying, "Let things be bad." If something would be a lot better, it's not two cents, it's two dollars.

The point is that when the difference is opinion (or close to), such as matters of color, font, position, etc., there is no reason to tweak things. If you're not going to make a big difference, don't make one at all.

If we throw out, even if momentarily, that there's more to success in the markets than pure luck, then people who have succeeded have done so in a very pure way: you can only make money in trading by being right. When you're right as often and to the extent that someone like Soros is, you have insight that 99.9999% of people don't.

Soros is definitely weird at times, and he is almost always too-certain. But your negative characterization of "billionaire investor" is a disservice to you and him. Rather than learn about the world by selling products or climbing a political ladder, he formed opinions and made bets. Massive, massive respect.

You are certainly right that it was fun.

But basically the hypergrowth of the '90s was borrowed from the future. All policy was good if GDP grew. Greenspan noodled on the problem--"irrational exuberance"--but unfortunately became convinced the existing pyramid scheme was working. He's since publicly expressed regret over a ton of those decisions.

Why do you need to prevent 40MB downloads?

Does it not resonate? That line hit me like a ton of bricks. I'm almost an OO fanboy, but that is a _very_ good point.

If it's $862m, last I checked, it will take them about 30 hours to bring in the necessary revenue--if they want to pay out of profits (I'm totally guessing here, what are real net margins on their hardware? 15-20%?), it'll take a couple days.

I expected to see (1995) tagged to the end of this article.

+1.

The "making hundreds of millions" part made me laugh too. Bet that's news to the index desks.

I can't upvote this hard enough. OP is right in my mind, but....

I'm straight (and divorced), and we got married for many of the same reasons that LGBT folks want to--it makes sense. Visitation rights, inheritance, tax treatment, etc.

It's unlikely that marriage would be removed as something of concern to lawmakers--has that kind of thing ever happened anywhere, any time, any way?

I respect OP's opinion, but it's ivory tower and we're talking about real people right now.

possibly unnecessary edit: just want to reiterate that I think OP is _right_, it's just not practical, and I'll sacrifice rightness for a rather-large "quick and dirty win".

All true. Also been true for ~7 years, so maybe it doesn't matter much.

Agree re: the rate limiter--totally irrelevant in the case of OP.

As the great Jules Winnfield (http://en.wikipedia.org/wiki/Pulp_Fiction) once said, "Well, allow me to retort."

I think the author would have been better suited without mentioning HFT, maybe algo trading model?, as its a lighting rod for controversy.

Don't be so quick... in a world where keeping score is simple and the odds are tilted for many, any publicity is good publicity.

4) Back testing, no HFT trade idea's go into production without backtesting, Every HFT firm is different but I think they'd all adhere to this rule.

I'm sure the majority do. But I really didn't. The problem with backtesting low latency (by which I mean switch-to-switch roundtrips of < ~ 50us) is there are so many sources of jitter the data is basically "mean of x, st dev of 6x^3". Too much noise to signal to make it worth it.

So I would run something "in sim" for a while on live market data but simulated execution. I never looked for profitability--I looked for predictability. If you know the knobs on your system, you can make it work in any market. If you don't know the knobs, you have no business trading it. After a run of a week or so with no major problems I'd go into production. BUT:

before you write anything else, you write hte risk system.

Oh Dear Lord yes. Not counting life-supporting, military, etc. tech, these are some of the sharpest tools you can imagine. Knight lost $440mm in less than an hour. And they were decidedly not of average expertise. That failure was a much bigger deal than most realize. Luckily smart people noticed and a lot of risk stuff changed after that (imo that was when people finally started to say "fast enough, I need to generate smarter orders").

2) The system has no rate limiter, what do you do when the quotes come in too fast for you to deal with?

I've been out of the guts for ~2 years, but by universal unforgiving law, the volume of quotes has got to be ridiculous now. People talk about "low latency" when they're talking about serving static HTML at 1000/s. So few people have actually seen the nuts and bolts of feed handlers--it's not their fault, this isn't widely available stuff--but the traffic spikes are mind-boggling. Good adapters combined with a tuned network stack will translate signal into "book" data, meaning usable basically, in ~ 5us. Meaning they do that 200 times per MILLIsecond. And it's not enough sometimes. And you and your rival firms are spending a lot trying to make that number 4us. Blah blah blah, I kinda miss it.

It is so, so infrequently that I get to say this about something HFT-related on the internet: fucking awesome, dude. There is actual information here that is of use and doesn't mislead. It's amazing.

edit: s/dude/guy-who-made-this

The latter is somewhat true, and probably unavoidable at this point. "The cat is out of the bag", so to speak--markets can't just go back. The problem is that the incentives are so wildly disproportionate. If a really smart guy works for the SEC or some surveillance body, he might $200k a year. That same really smart guy might make $200 MILLION trading. It has to be awfully damned unlikely to not choose the latter. And in reality, you're probably pulling $100k somehow or another while you wait.

With respect to the idea that this guy is the culprit, that's literally laugh-out-loud funny. It's possible he was spoofing, etc., even with decent size. But the clearing firm (Hi, MF!) controls the throttles on those pipes. But there is what is called "sponsored direct access" in these markets, and that basically means the clearer wants your business enough you can just hook up directly so you can go really fast, and they (the clearer) will just pretend that they're looking at your stuff.

I'm in the "professional automated trading" space. This is by far the most common vendor mistake. "We make trading simple!" is pretty much a surefire way to mediocrity at best.

"We make tax law simple!"

"We make heart surgery simple!"

^^ similar silly things, only you don't ever see them

The thing is, no one actually DOES make anything simpler. They just restrict the toolset with which you can solve problems to things that work for the 80% cases.

Can't answer for OP, but for this new user, a Chrome app would be dandy.

These are standard "tricks" in the high-frequency / low-latency trading space.

Congrats on your success--you have the best kind of problem.

1. You have a working product--do not do a full rewrite. Rewriting has so many pitfalls in the best of cases, and if it's just you, the context switches between the "old" (which you will still be spending most of your time maintaining) and the "new" systems will be brutal.

2. This is the prototypical "real world" case. You're basically asking how you can prioritize immediate enhancements vs. long-term flexibility and maintainability. But maintainability is a feature. Any (good) book on agile development methodologies will tell you that consistent refactoring and cleaning of the code has direct user benefit, in that future velocity (user enhancements) will be better.

3. The prudent way forward is to chip away at the problems. As you "touch" various parts of the system, start doing small refactoring work, adding comments, tests, etc. Remember, you're starting from nothing--anything you do in this regard is improving your situation.

4. If you're not doing some sort of iterative development methodology, start. Personally, I have a preference for Scrum, because of its time-boxed nature. It lends itself well to devoting a section of each dev cycle (sprint) to the kind of cleanup work you need to do.

Good luck!

The children here are potentially misinterpreting this. I don't see this comment as being judgmental. The fact that Apple has accomplished this does NOT mean that the poster is saying Apple adherents are mindless drones or fanboys.

What's inherently wrong with "brand tribalism" or "proof of discerning taste"?

I read this is a tribute to Apple, nothing more.

I think you need to drink something other than the Kool-Aid. Java has its warts, but all languages do. Get over yourself.

How about none of the above? Directly to the CEO is the only thing that makes sense. And the CEO had better be focused on Product (or Service) Management above all else, and all those other things should report INTO the PM organization.

Engineering? Implementation of PM strategy.

Marketing? Communicating the PM message.

Sales? Delivering the product spec'd and built by PM.

Etc....

Make sure to check out his LP under the name Gramm.

first track: http://www.youtube.com/watch?v=4kHEu50uq3w

(Of course) the data won't be free. They don't get it for free--"tape" fees are a major source of exchange revenue.

(Although it's possible some delayed feeds may be available, etc.)

I don't agree. Giving 30 books vastly increases the chance that any given reader can find the "right" 20%. Your 20% might not be mine; although I would find it interesting if you posted your top 5 books, I'd rather see the 30 that you read, so that I can read them all and find my own top 5.

My reaction tends to be opposite yours: when someone gives me the "top 5", I consider it only a trailhead; it's unlikely my top 5 would be the same.

This is true, but FPGAs can still only handle relatively simple algorithms. FPGAs make certain kinds of tasks nearly trivial (think truly parallel tasks such as decoding market data for different instruments), but there's just not enough gates (in most cases) to do interesting stuff in the application / logic layer.

FPGAs canonical use case is still as very fast codecs. There are exceptions, but they're really only the very simplest of arbitrage strategies. And in order to make those work you need top-of-the-line network gear and engineers as well.