throwaway283719

The UK soccer league is the most popular sport in the UK, and has a huge following elsewhere in Europe as well as in South America and Asia. For many of the biggest teams, the majority of their fan-base is outside of the UK. For many people, playing or watching soccer is their primary leisure activity. There are 6-10 premier league games screened each weekend across a variety of channels, not to mention the other leagues (which also have huge followings going down into the 2nd, 3rd and 4th leagues) and the various regional and international competitions that UK teams compete in, as well as the untold hours of soccer-related programming that isn't showing games.

I don't think the comparison with a hypothetical reality TV show is very meaningful.

It is also useful for rewriting routines in the critical path for slower, but more productive languages. Particularly languages that need to do a lot of heavy-duty data crunching (think Python, R, Matlab, Octave).

I mean, I guess you could do that in C++ instead. But why would you bother if C is good enough (and it typically is for most numerical algorithms).

The situation is different because there isn't a 2000+ year history of Java developers discriminating against Lisp developers.

In fairness, thinking that 1 is a prime number (or just not knowing that it isn't) is in quite a different league to not knowing how to calculate the average of a list of numbers.

It is one of the top-ranked universities in Canada (roughly equivalent to an Ivy League university in the US, or Oxbridge in the UK).

Which other asset classes are you thinking of? I think that most transactions in cash equities, spot fx and futures are now done electronically.

I'm sure that a large proportion of derivative trades are still done over the phone, but that's because they tend to be (a) quite customizable and (b) quite hard to price.

It is incredible that treasuries are still traded over the phone, however, given how (relatively) easy they are to price. Even treasury futures, which are harder to price due to the basis and optionality, are mostly traded electronically, which tells me that there must be some parties with a pretty strong interest in keeping bond trading a "closed shop".

tptacek already responded to your previous comment about Flash Boys below [0]

[0] https://news.ycombinator.com/item?id=9045150

The trouble with this argument is that, on basically every exchange in the world, you do not get to find out if someone has matched with your passive order until after the trade has happened.

There is no possibility to "back away when a matching order comes in" because the first time you find out about the matching order is when you are informed about the trade that you just did!

What can happen is that a market maker will post liquidity on multiple exchanges A, B and C, and will remove their orders from exchanges B and C if they are filled on exchange A (assuming they are fast enough to do it!)

This is not shady or nefarious. In fact, it is the only way that a distributed market could possibly work.

The market maker has some finite capacity to provide liquidity (e.g. they have position limits, they need to post margin, they have certain risk tolerances). They want to maximise the chances of their orders being traded on (i.e. providing liquidity), so they post liquidity on all available markets.

When they match on one of those markets, their capacity to provide liquidity has diminished, until they manage to offset their position somewhere (either on the same market, or on a different one). Moreover, they have just received a new piece of information about the supply/demand imbalance for this particular stock. For both of these reasons, it is natural to assume that they would want to adjust the prices they are offering on other exchanges. The market cannot function any other way.

That would be a groupoid - http://en.wikipedia.org/wiki/Groupoid

No. For example, a FilePath is (after resolving a few other type aliases)

  data Root
	  = RootPosix
	  | RootWindowsVolume Char
	  | RootWindowsCurrentVolume

  data FilePath = FilePath
	  { pathRoot        :: Maybe Root
	  , pathDirectories :: [String]
	  , pathBasename    :: Maybe String
	  , pathExtensions  :: [String]
	  }

Would you back up your 99.9% confidence level with a bet? For example, I will send you $1 if he is convicted, and you will send me $1,000 if he is acquitted?

If not, how much would you put at risk for the chance to win $1 if he is convicted?

Yes. You can get significant signal attenuation (particularly at high frequencies, i.e. above 10 GHz) when it is raining.

The problem is that it is absolutely not a good primer on the subject, and the only way you could know this is if you have experience in electronic trading already.

If you are trying to learn about electronic / high frequency trading by reading "Flash Boys" you are actively working against yourself. You will literally be more incorrect after you have read this book.

What markets is this done on? On most markets that I'm aware of, there is a fee for passive trades and a fee for aggressive trades. Sometimes the fee for a passive trade is negative (a rebate) which encourages liquidity provision, but I don't know of any market that actually charges per order, and then rebates that proportionally to the liquidity providers.

One proviso is that I've never worked on US equity markets, so if this rule is in place there then I wouldn't know about it.

But McDonald's makes a profit every time I buy a cheeseburger from them. It's like the know the true price in advance, and set their prices so that they always make a profit.

The cheeseburger market is rigged.

It looks like 20-25 of the Forbes "30 under 30" are YC founders or otherwise involved in YC - is that correct?

An incredible achievement if so!

Most market making algorithms work like -

  Market state                                     -> price forecast
  Price forecast + other factors (risk, liquidity) -> trading decision

If you know (or have a good guess) how the algorithm works, you can work out what state of the market would lead to a price forecast in your favour, i.e. would lead to the algorithm offering liquidity at a price favourable to you.

You then manipulate the state of the market to look like that (generally this is "spoofing" or "layering"), wait for the algorithm to respond, and then take advantage of the favourable liquidity it offers.

When people calibrate their algorithms, they use real market data. Most of the time, someone isn't actively manipulating the market, so the model is not calibrated to handle those situations.

You generally receive a salary (dependent on what you do, what kind of firm you work for and how experienced you are, but $60-200k probably captures 95% of people) and a performance-based bonus which could be anywhere from 0x to 10x your salary, again depending on exactly what you do, how the firm performs that year, how your team performs that years, and how "close to the money" you are.

I don't think programmers in the field have an appreciably shorter lifespan than in other industries. I don't think that working in an algo trading company is intrinsically any riskier than working in any other kind of firm.

The hours tend to be longer and the work tends to be slightly more stressful than if you are working at a generic bigco, however.

One (slightly cynical) answer is that people like to hire people like them. Most quant types working in hedge funds are very good at brainteasers, and if other people are good at brainteasers it ticks one of the "this person is like me" boxes whilst also ticking the "this person is smart" box.

It also allows an endless pissing contest of comparing new brainteasers among your colleagues, and telling stories of helpless candidates who couldn't even manage the first gasp of a hint of an idea towards the solution.

I tend not to like extremely complex brainteasers as interview questions, and especially not ones that require an "aha" moment to solve them correctly, because mostly what you're testing for is whether the candidate has seen that question before (or one like it).

On the other hand, I am a big fan of asking relatively easy math questions (i.e. first year undergraduate) in interviews, because if I'm going to be paying someone $100k+ to work on mathematical models, I'm damn well going to make sure that they understand basic probability, statistics, calculus and linear algebra. These are a bit like fizz-buzz for quants - if the candidate can answer them it doesn't prove anything, but if they can't answer them then you can stop the interview right there.

Kudos for having enough doubt that your intuition was correct to actually write the simulation!

Self-doubt is a quantity often found wanting among smart people, computer programmers, and especially among the intersection ;)

You think it's a "bad" design decision because you think that a Python list should represent a vector of numbers (not even an array - a mathematical vector).

But a list is much more than that - conceptually it's any ordered collection of things, and not necessarily even the same type of thing. Overloading `+` to mean concatenation and `*` to mean replication means that the operators can work with any kind of list, not just lists that are mathematical vectors.

If you do want a mathematical vector, you should use a numpy array - not only are you making it clear that you have a vector of numbers, but your operations will be more efficient (because using a numpy array guarantees that the elements in it are all of the same type, so you don't have to do type dispatching on every element).

No. In the first case, the fact that the host shows you a goat has not put you in any new state of the world (the host was going to show you a goat regardless of what happened).

In the second case, you now know that you are not in one of the states of the world where the host accidentally opened a door that had a car behind it. They could have opened a door with a car, but they didn't. That gives you some information - it stands to reason that since they didn't open a door with a car, it was probably a bit more likely that they would pick a door with a goat, which makes it more likely that there are two goats than that there is one car and one goat, which is equivalent to saying that it's a bit more likely that you have already chosen the car.

The Monty Hall problem is actually a bit more subtle than this article makes out. The exact wording of the problem can change the answer. For example, in this version

> There are two doors with goats and one with a car. You choose one door from the three. The host selects one of the doors with a goat from the remaining two doors, and opens it. Should you switch doors if given the chance?

has a different answer than this one

> There are two doors with goats and one with a car. You choose one door from the three. The host chooses one of the remaining two doors at random and opens it, showing a goat. Should you switch doors if given the chance?

In the first example the hosts choice is either forced (if you chose a goat initially) or doesn't make a difference (if you chose a car).

In the second example, the host could have opened a door with a car because he was choosing the doors at random. Given that he didn't, your estimate of the probability that you have chosen the car should increase - in fact, it should increase to 1/2, and switching doesn't make any difference.

To me, this is the really interesting thing about the Monty Hall problem - the knowledge and intentions of the host are important in the correct solution to the problem! So there are two ways to come up with the answer "it doesn't matter if you switch" -

1. You understand the problem in the first sense above, and your intuition leads you to an incorrect answer.

2. You understand the problem in the second sense above, and you are correct that it doesn't matter whether you switch or not.

"The exact quote is roughly"

Um..?

Out of curiosity, what percentage of out-of-sample variance explained would convince you that a predictive model had some power? 0.1%? 1%? 2%?

I take slight issue with this quotation -

> Though the idea of a street grid seems perfectly ordinary to city-dwellers today, it was unusual at the time. Most great cities in Mesopotamia, for example, had curving streets and a more organic-looking layout.

Maybe a street grid seems ordinary if you live in a large city in the US, but most European cities don't have gridded streets (and I don't think it's the norm in many other places in the world either).

There's a fun piece of math you can do with this model. Given the relation

  w[t+1] = w[t] + (c[t] - alpha * w[t] - beta * d[t] * w[t]) / 3500

and assuming c, d are both constant (i.e. assume they are your long-run average of calories consumed and exercise done) you can solve to get

  w[t] = c / (alpha + beta * d) + const * (phi ** t)

where phi is a number smaller than 1, and const is some constant that depends on your initial weight. Over time, the phi t term decays away, and you are left with your long-term stable weight,

  w = c / (alpha + beta * d)

Using c = 2000, alpha = 12.5, beta = 0.63 and d = 0 you get a long-run stable weight of

  w = 2000 / 12.5 = 160 lb

On the other hand, if you eat 2500 calories per day but run five miles, you get

  w = 2500 / (12.5 + 0.63 * 5) = 160 lb

so if you want to eat an extra 500 calories per day, you should run 5 miles per day.

It'd be interesting to see how accurate this is.

I would say a "tick" comprises the timestamp (stored as a long int) and ten levels of the order book (bid price, ask price, bid size, ask size) each stored as a double-precision float or a long int, so that's

  (1 + 4 * 10) * 8 = 328 bytes

per tick, so 1KB isn't far off. Obviously not every level changes on every tick, so there are opportunities for compression, that can be significant.

Note that the "tick data" from histdata.com gives you prices sampled every 1 second (so not every tick) for the top level of the order book, and doesn't give you any size information at all.

Haskell -

  fizzbuzz x = case (x `mod` 3, x `mod` 5) of
      (0, 0) -> "FizzBuzz"
      (0, _) -> "Fizz"
      (_, 0) -> "Buzz"
       _     -> show i

  mapM_ (putStrLn . fizzbuzz) [1..100]

There's an undercurrent of meaning over at Nanex that says that when these unusual-looking patterns appear, they are because some bad actor is doing something naughty, like manipulating the market.

The reality is that most of these patterns fall into one of the following categories -

(a) Test patterns (e.g. checking that your orders are appearing in the market data) which are normally done at times of very low liquidity.

(b) Software bugs (this is probably the vast majority). This might not be a "bug" as such, but an edge case of an algorithm that nobody has thought much about before. Writing robust order placement algorithms is surprisingly difficult.

(c) Positive feedback loops, where you detect and react to your own orders in the market data.

(d) Unanticipated interactions between two or more algorithms.

Of these, (a) is mostly benign, (b) and (c) can be actively harmful, and (d) can go either way. None of them are generally beneficial.

Real market manipulation doesn't look "weird" like this because people doing it are taking care to make it look like they're not manipulating the market. For example, they might spoof with a large order quite deep in the book (which wouldn't change the best bid and offer at all) or layer orders at multiple levels.

It's actually quite difficult to spot this kind of behaviour in market data, even if you spend your whole day watching algorithms trading.

On the other hand, it's easy to spot unusual-looking activity in categories (a)-(d) above, which is why Nanex is full of that kind of chart.