rhettinger's comments

Traditional unit testing doesn't work well with the strategy component in high-frequency trading programs.

* The need to rapidly iterate and refine strategies is not supported by writing tests which can prematurely lock-down the logic. Likewise, freezing the business logic with tests can become an impediment to adapting to changing market conditions (some opportunities have a short life).

* Like chess and poker games, the opponents have a say in how the logic plays-out. You will not be able to create a mock-object that accurately simulates how the rest of the market will respond to your bids and offers.

* Trading can be viewed as a concurrency problem. A flood of messages (orders and cancels) from independent actors (your competitors) go into an exchange computer which matches orders and emits quotes -- this is a race condition by design. Behaviors of concurrent systems with race conditions are notoriously hard to test.

* The OP mentions an order simulator (fake orders used for testing) but should be aware that that system can introduce a new risk, that of failing to switch the inputs when going live with a strategy. I've seen this happen (fake orders in, live orders out, not good).

* For managing risks, there are reasonable alternatives to testing. For example, strategy monitoring can shut down a program with order streams that are too large, too frequent, or that accumulate large positions. These dynamic reasonable checks provide protection against irrational strategy logic. Dynamic monitoring of trading logs provide real-time logic validation (i.e. with the actual inputs received, did the strategy make correct decisions).

Many components of a trading system are unittestable, but the strategy engine (the business logic) is more amenable to other techniques.

How Python's super() actually gets used:

http://www.google.com/codesearch?as_q=super\(&as_lang=py...

Code Prion -

n. a really bad idea dressed-up as a good idea thereby becoming contagious in a way that never seems to die out.

n. memes adopted as a religion by the clueless because "it seems like a great idea" while drowning-out the opposition because the arguments against are subtle.

* "Our object model makes it hard to implement NaNs" -- famous last words before adding hundreds of if_special() checks to your code and transforming your object model into something that defeats your ability to reason about programs by undermining common notions of equality as being reflexive, symmetric, and transitive. If you doubt that identity-implies-equality, then you're infected.

* Most ideas for pre-commit hooks are code prions. If your process depends on crippling a developer's ability to make a check-in, then you're infected.

* "Our dynamic language doesn't implement static language feature X". If you think Ruby and Python need Enums and Interfaces, then you're infected. Those features cost nothing in compiled languages and often only serve to overcome the limitations of those languages.

* "We're making everything clean and pure by deprecating everything we don't like anymore." Hey, it only takes you ten minutes to add the deprecation, who cares if it consumes hundreds of hours of user-time to update their programs or if they stick with an old version just to avoid your deprecation hassles. Better to just document it as obsolete than to inflict pain on a large user base. (By the way, authors of books will hate you too -- it makes their books go out-of-date prematurely). If you think of published APIs as mutable, then you're infected.

* If you think self.assertLessEqual(x, y) is the right way to spell, "assert x<y", then you're infected. Get nose.py or py.test and live free.

* "Everybody knows eval() is an egregious security hole, so you should never use it." Learn to differentiate between trusted and untrusted code; otherwise, your fear will keep you from using your most basic and powerful tools. This code prion is chonic and progressive -- eventually you'll find yourself unable to write "import collections" because someone might have stolen you ssh key, logged into your machine and added their own collections.pyc file which would appear to run normally but actually emails your mother's secret porridge recipe to wikileaks. If you think eval() is evil, you're infected.

There's room for debate on whether grades should reflect homework completion and timeliness, but some of the grading practices were nuts:

"...their grades are more accurately reflecting their knowledge, not whether or not they brought in a box of Kleenex for the classroom, a factor that had influenced grades at Ellis in the past."

I applaud the effort to separate knowledge grades from "life skills" grades. I can't imagine anything more useless than making a kid repeat a class or defer their graduation when they've already acquired the requisite knowledge.

One client was charging-off sizeable bad debts on their accounts receivable, but the program did not recognize that some of the receivable balance was for the sales tax.

With a five-line change, $250k/yr was saved (you don't have to remit sales taxes for money you never received).

The Burrows-Wheeler transform used in bzip2 is truly mind-blowing.

Many algorithms are ordinary genius (eventually you would have come up with it because the problem space dictates the solution), but this one is extraordinary genius (mind-blowingly original and non-obvious). Every time I see it, I'm amazed that it works.

This article had remarkably little content or analysis. Essentially the only point made was that LaTeX markup can separate content from presentation.

What we really need is more startups that actually have a capital gain (real profits in excess of original investment). That would be progress.

Monocle works by wrapping a single generator and translating each yield-statement into a hand-off to the event loop or reactor and resuming when the value of the deferred becomes known.

Since the code is confined to a single generator, it's not easy to factor-out the steps into subroutines. PEP 380 provides a syntax for having sub-generators which can potentially be used to factor your code into smaller, reusable components.

PEP 380 is about providing better support for nested generators including the scaffolding with try/finally, g.send(), g.next(), g.throw(), and g.close().

In short, PEP 380 lets you nest, and nesting lets you factor your code.

> Will Python 2 ever end?

It will probably be around for a very long time. Some people are trapped by dependencies third-party libraries and others are trapped by mountains of existing scripts with scant tests.

The real question is when Python 3 will take-off and become dominant. We have at least a little evidence that the transition is happening, slowly but surely. At conferences, most attendees raise their hands saying that they have downloaded and tried Python 3. More and more third-party libraries are being converted. The newer Python books target Python 3. And, the python developer forums are showing a greater focus on working out some of the transition kinks.

IMO, Python 2.7 is wonderful on two fronts. It serves users who are stuck in 2.x land and it brings the two language variants closer together so that a transition becomes a smaller step.

If my previous experience in the field is any guide, this should be a rewarding experience for you.

> Is there any reason not to go do this?

It is likely to be a high-stress job. Also, the turn-over in the industry tends to be very high.

And someday your grandmother will hear something about high frequency trading on Oprah and decide that your work is evil.

> It seems perfect - why don't more hackers take this path?

Not many are invited. Traders accept only the very best.

I've seen open source people disappear for all kinds of reasons. It is a natural ebb and flow. People tend to fall off when they are busy and they tend to come back when they've got an itch.

Too often, I see bloggers willing to give executives and public officials a pass when they are caught in a lie. The rationale is that the people are otherwise doing a good job, but the bloggers ignore the irony that part of the job was enforcing the rules and imposing judgments on others.

If you're a Dean who has ever kicked a student out of school for an honor violation, I have no sympathy when you get called-out for lying. Too many students get kicked out of school and have permanent black mark on their record for similar offenses; why should the Dean get a pass.

If you're a former President whose job as chief executive is enforce the laws of the country, then I have a hard time having sympathy when people find-out you've lied under oath. Too many people go to jail for perjury; why should the President get a pass.

If you're a former New York prosecutor famous for corruption cases, then I have little sympathy when you've been caught hiding funds to pay a prostitute. Too many people are vilified for this; why should an Attorney General get a pass.

All that being said, I don't judge this Dean, the former President, or the NY Attorney General. Instead, I judge the bloggers who have a double standard for people they like.

Pretty good start and cool idea.

Would be more impressive if the program responded to movement of the ghosts or followed a known pattern around the maze.

If you list it on your CV, someone may "remember" that they thought you were really smart but likely won't remember what gave them that impression. That is a win.

If you go to a Mensa social gathering, you may develop a meaningful relationship loosely predicated on having something positive in common. That would be a win.

I personally don't place much stock in the IQ tests but don't think there is anything wrong with joining. It's not much different than joining an alumni association or any other affinity group.

Unlike many lawsuits, this one is a testable hypothesis. It is knowable whether favorable reviews disappeared, whether an algorithm or person triggered the disappearance, and whether this occurred after a sales-rep made contact. The phone logs, syslogs, and code repositories should reveal the truth in this case.

Hopefully, this article will be counter-balanced at some point by discussions with successful entrepreneurs who had open, candid, and honest relationships with their VCs and customers. In my experience, telling the truth builds relationships and lets people focus on problem solving.

If being honest with your VC means losing funding, it may still lead to funding of another, more viable idea.

Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)

  >>> from itertools import product
  >>> twokids = product('B G'.split(), 'M Tu W Th Fr St Sn'.split(), repeat=2)
  >>> boytues = [t for t in twokids if t[:2]==('B', 'Tu') or t[2:]==('B', 'Tu')]
  >>> twoboys = [t for t in boytues if t[0] == t[2] == 'B']
  >>> len(twoboys)
  13
  >>> len(boytues)
  27