Merry Christmas - 2007

The picture above is from December 2006. Our first snow in Missouri. There is a bit of snow on the ground today...but quickly melting. We may have more snow tomorrow.

Hope everyone is having a great Christmas. I've spent my time drinking coffee my daughter gave me and putting together all the presents for the kids. Next step is grilling some nice tenderloins wrapped in bacon. No thoughts about the markets or programming. Just kicking back and enjoying the day.

Oh, and very thankful for the great gift a friend of mine gave me last year. I've never owned a cordless drill before. A friend of mine felt sorry for me and gave me a full set of Dewalt cordless power tools. All these years I've been cussing at putting toys together...until now. Wow, what a difference Dewalt makes. Thanks, buddy!

MT

Quote of the Week - 12/17/2007

"Do what you gotta do so you can do what you want to do"
-- Denzel Washington

MT

To Design or Code?

"The one who does the work decides." -- KDE principle

Jeff Atwood over at the Coding Horror blog discusses a fascinating problem in software development. Doers and talkers. Designers and coders.

I believe all developers need to have a bit of both in their toolbox. Mainly, because the first design is most always changed due to scope creep (failure to see all the pieces to the puzzle). If you spend all your time talking about that first design...you never get to coding. And if you can't get to the coding...you'll fail to find those missing puzzle pieces. And fail to deliver a prototype for the customers to evaluate.

Designers, this means getting your hands dirty in order to create something to improve. Developing systems is an iterative process. Design, code, design, code. And yes, even code, design, code, design. The ultimate goal is to refine the process until you and your customers are satisfied. Whatever it takes. And yes, that means moving to the coding stage even when the optimal design has yet to reveal itself. It's really a Kaizen process. Small accomplished improvements to the initial design pays dividends to all.

Coders, this means before plunging forward hacking away at the problem...ask for feedback of your idea and possible alternatives to the problem. It's important to starting coding down the right path. One that encompasses as much information of the problem as possible. This means you'll need to bring some information to the design table yourself. Perhaps a bit of discovery coding must take place to figure out what elements are involved and possible problems or bottlenecks in your proposed solution. This also helps in keeping the design discussion focused.

So, how does this apply to investing? Well, how many investors/traders do you know that invest without a plan? Without a design? An overriding investment philosophy? Just plunge ahead into the market?

These type of investors would be well served by stepping back a bit and design their investment model. Then ask for feedback of their proposed design. It's okay to perform some discovery trading first. Determining how the market handles your ideas. But, gather what you need and then design. Then invest with the goal of continually refining your design.

What about investors/traders who are afraid of the market? Have not found an investment model that is perfect? And refuse to step a toe in the market waters until they feel 100% comfortable in their design? Problem with this thinking is knowledge requires experience. And nothing is ever 100%...especially in the market. So, create your investment manifesto and then try it out. You can't improve upon something that isn't there to improve. And you can't design a successful investment strategy if you don't have market experience.

Later trades,

MT

Breakthrough Programming

“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.” -- George Bernard Shaw

Scott over at the scottberkun.com blog links to an amazing paper on Managing for Breakthroughs in Productivity. The article discusses how breakthroughs occur...and don't occur. My favorite quote...

For breakthroughs to occur, people must be given a chance to do work than can not be proven: ambition and risk are necessary for breakthroughs. If individuals are not trusted to take risks, breakthroughs are unlikely.

Spot on! Programming and risk goes hand in hand. As do programming and ambition.

To be an effective programmer you must have the ambition to automate tasks...all tasks. That's your job. If you spend your time manually putting widgets together...then you're not really programming.

And in order to automate tasks...a programmer has to take risks. Cause you are programming something that has never been done by a computer before. At least that computer. And most likely, never been programmed by you before.

MT

Programming Culture

Hat tip to Howard Lindzon for sharing this post...Software Engineering Tips for Startups

Alex's tips for startups is one of the best posts I've read in a long time on building a programming culture. I realize the focus is on tech startups. But, I believe his points are applicable to all companies with programming departments.

Some of my favorite quotes...

So the first tip is to always have a strong technical co-founder. Someone who shares or invents the business along with others, but also has the technical feet on the ground. Someone who can make sure the business is mapped onto technology correctly.

Avoid hiring managers...What you need are experienced technical people who love coding. These are going to be natural mentors for your younger engineers. Mentors and not managers.

Coding becomes sculpting. Starting with a shapeless form you continuously refine the code to satisfy the business requirements and make sure that the system is designed and implemented correctly.

And probably my favorite in regard to hiring programmers...

...candidates need to demonstrate love for simple and elegant code.

Simple and elegant code = Simple and elegant company.

I would also like to add one more trait to look for in programmers. Willingness to share knowledge. Evidence of this sharing trait in the interview and in past performance.

For example, all programmers develop tools to make their jobs easier. But, do they develop those tools for themselves only? Or for others to use as well? We all know...developing anything for others to use is the harder path to follow. But, without knowledge transfer, the wheel will be re-invented...again, again, and again.

Have a great weekend,

MT

Quote of the Week - 11/28/2007

"The Things to do are: the things that need doing, that you see need to be done, and that no one else seems to see need to be done. Then you will conceive your own way of doing that which needs to be done — that no one else has told you to do or how to do it. This will bring out the real you that often gets buried inside a character that has acquired a superficial array of behaviors induced or imposed by others on the individual." -- Bucky Fuller

Great quote. What do you see that needs to be done? And more importantly...what are you doing about it? But, a precaution...doing what needs to be done that hasn't been done by others prompts others to stall/halt the doing. Do you have what it takes to overcome the others in order to get the doing done?

MT

Quote of the Week - 11/10/2007

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." -- Albert Einstein

Something to think about when developing systems.

MT

Backtesting Issues

I'm in the process of validating some investment ideas and thought I'd share some of the hidden biases that occur when comparing systems against each other and the market in general. I should know...these issues have bit me numerous times over my past 7 years of system testing. Maybe the testing methods below will help you as they have helped me.

Failure to Trade All Signals

• Every signal received from your idea should be tested. Which means taking trades for a stock you already own. If your idea is to buy 20-day highs and you receive your first signal for YHOO on 10/15/2007...you buy it. If you receive another signal on 10/16/2007 for YHOO...guess what? You buy it. Despite already owning the stock. Failure to do so means your filtering the idea. This is okay if you already know the idea is valid...but if so...then why are you testing in the first place?

• A big obstacle in taking all signals is money. First test the idea without money constraints. Money should not limit your trades. In fact, when testing...the only limit on your trades should be the idea.

Failure to Test the Other Side

• The Trading Digest covers idea reversals in their article on the 50/200 Moving Avererage Crossover system. In essence, any idea should be reversed, tested, and compared with the original idea.

• So, if the idea is selecting 20-day highs...the reverse of that idea is selecting stocks less than or equal to their 20-day highs. But, performing this test presents a problem. There are fewer stocks at their 20-day highs (idea #1) than stocks not at their 20-day highs (idea #2).

• It's unfair to compare 150 trades from idea #1 against 5,000 trades from idea #2. Whose to say randomly selecting 150 trades from the 5,000 trades in the idea #2 sample set wouldn't generate as good if not better results than idea #1?

• And that's just how to solve the problem...boot-strap it. Take those 5,000 trades and randomly select 150 trades. Compare those results against idea #1's sample set of 150. Of course, it wouldn't be wise to select one 150-set sample from 5,000. Take several 150-set samples...compile the results and use that for the comparison.

Remove the Best Trades

• With any system...the Pareto Principle is large and in charge. You'll find only 5% to 10% of the trades generate the majority of the idea's profits. What are the chances you would have missed a few of those trades? Throw money limits into the mix and real world events like vacations and that home remodeling project your wife has been bugging you about...and it's very easy to do. So, remove them from the test sample. Don't let a few trades in the sample play such a large role in the results.

Market Exposure

• When buying presents for your kids...the number one rule is every kid must receive the same number of presents. If you fail here...you will pay. Testing and comparing ideas are a lot like your kids. Give them equal time and exposure.

• Use the same signal starting point for the comparisons. If your testing date range is 01/01/1995 - 12/31/2004 and idea #1 kicks off it's first signal on 05/01/1995 and idea #2 kicks off it's first signal on 02/01/1996...no fair! Idea #1 received a 9 months head start on idea #2. Might not seem like much...but with markets and babies...9 months can make a difference.

• In fact, it usually pays to bucket the trades in similar timeframes. That way you can ensure not only the trades share similar signal start times but also similar bucket sizes. For example, to test 10 years of data...01/01/1995 - 12/31/2004:

Bucket 1 -> 01/01/1995 - 12/31/1996
Bucket 2 -> 01/01/1997 - 12/31/1998
Bucket 3 -> 01/01/1999 - 12/31/2000
Bucket 4 -> 01/01/2001 - 12/31/2002
Bucket 5 -> 01/01/2003 - 12/31/2004

• The buckets 1 - 5 above would be the testing date ranges. After the simulations are complete for each idea and corresponding bucket...verify idea #1's bucket 1 contains roughly the same number of trades as idea #2's bucket 1. If not, then boot-strap the larger bucket size down to the smaller bucket's size. Compare results. And remember, remove the top 5% or so trades from each idea's buckets.

[Clarification: The testing date ranges in the buckets listed above are not the start and end dates for your trades. The date ranges are the start and end dates for your idea. Meaning...all ideas triggered from 01/01/1999 to 12/31/2000 would be in Bucket 3. You would need to track those signals for as long as you stay in them...which may mean all the way to your end date of 12/31/2004. Make sense?

In essence, your overall begin and end dates are 01/01/1995 - 12/31/2004. Then you slice and dice the signals that occurred during that time frame based on entry date into buckets 1 - 5.]

Questions?

• What if the idea consists of several smaller ideas such as selecting stocks at their 20-day high and on that new high experience a 30-day volume surge? In this case, you would need to iterate through the above process twice.

• In the first pass, you'd compare the 20-day high stocks against stocks not at their 20-day high. In the second pass (if the first pass proves fruitful), compare the 20-day high stocks with 30-day volume surges against 20-day high stocks without 30-day volume surges.

As you can see, getting an idea through the validation process is quite an ordeal. Unfortunately for us system traders; very few ideas make it out alive. Thankfully, we don't have to cut those ideas from our sample set.

Later Trades,

MT

Quote of the Week - 10/10/2007

"...the most important quality for a trader to develop is discipline. As you've read, my stubborn ego and impatience prevented me from achieving lasting success and financial security. I hope my story has shown you that any fool can get lucky and quickly make a great deal of money. But, if playing the stock market was always that easy, there would be no need for research and hard work. Considering that all the information you need to be able to profit is available on the Internet, what sets successful traders apart is their ability to wade through all the muck. With regard to your sources, keep an open mind. As my losses demonstrate, if you allow your emotions and ego to control your trading, you are doomed to fail." -- Timothy Sykes from his book, An American Hedge Fund

What great words of advice! Reading Tim's book brought back the memories of what it was like trading in the greatest stock bubble of our time. In fact, I participated in the ISCO trade he mentions in the book. What a ride, indeed!

I look back and realize just how far I've come as a trader and how much further I still have to go. Tim is right...cutting through the muck is a tough chore for any trader/investor. The key to long-lasting success is keeping an open mind, learning from your failures, and working hard...really really hard. Of course, a sprinkle or two of luck never hurts.

Thanks for the book, Tim.

Later Trades,

MT

Recent Links for 09/21/2007

Newbie - converting csv files to arrays in NumPy Great message thread on how to convert csv files to numpy arrays.

Cookbook/InputOutput - Numpy and Scipy File processing examples using numpy, scipy, and matplotlib. How to read/write a numpy array from/to ascii/binary files.

Numpy Example List Examples of Numpy functions such as fromfile(), hsplit(), recarray(), shuffle(), sort(), split(), sqrt(), std(), tofile(), unique(), var(), vsplit(), where(), zeros(), empty(), and many more.

Introducing Plists: An Erlang module for doing list operations in parallel Could you spawn a trading system process for each stock of a given day's trading (a list)? What if you had 20,000 stocks for a given day? Can plists/erlang handle 20,000 processes without hitting memory constraints?

Recent Links for 09/19/2007

130/30 Strategy Backtested Disagree with comparison of 130/30 to non-leveraged benchmark/strategy. Also, the additional longs didn't improve the long portion of the 130/30 returns compared to the long-only strategy returns. Am I missing something?

Recent Links for 09/18/2007

Chapter 22. Struct and Array Modules Overview of the python struct and array modules

Building Skills in Programming Nice python tutorial.

Python Grimoire Nice python cookbook.

Recent Links for 09/17/2007

• One year ago I was a stock market analyst [Part 1]
  Very interesting how he was able to process 9,000 stocks in less than a minute.


• Goldblog - Python - Stock Quote Module
  Interesting python stock quote utility.


• Goldblog - Investment Advice
  Excellent investment advice. Keep it simple.


• NumPy for Numeric/numarray users
  Cheatsheet for NumPy Python users

Recent Links 09/17/2007

Goldblog - Investment Advice

• Excellent investment advice.  Keep it simple...
  
  • 
    There are 2 simple questions you must first answer:
    
    1. What is the time-frame in which you need access to your money? (next week? next year? 10 years? retirement?)
    
    2. How much risk and volatility are you comfortable with?
    
  • 
    The Answer:
    Asset Allocation... not fundamental analysis, not technical analysis, not market
    trending, not tips from brokers and analysts ... but straight up asset
    allocation.
    
    
  
  
  
  
  
  
  
  
   - post by taylortree

Recent Links for 09/15/2007

Links for 2007-09-15 [del.icio.us]

Posted: 16 Sep 2007 12:00 AM CDT

• Practical Common Lisp
  Excellent way to get started with Common Lisp.


• 9 Things You Simply Must Do
  Friend of mine sent me this great post on Dr. Cloud's 9 principles commonly practiced by successful people. My favorites?
  

Principle #2: Pull the Tooth - face your fears...don't put off today what you can do today.


Principle #4: Do Something

• ONLamp.com -- An Introduction to Erlang
  Great coverage of the Erlang language.


• Python Cheat Sheet
  Simple little python cheat sheet.

Recent Links 09/15/2007

Practical Common Lisp

• Great coverage on Common Lisp.
   - post by taylortree

Recent Links 09/06/2007

Quantmod - Quantitative Financial Modelling Framework for R

• Offers R language modules to...
  
  • calculate periodic returns
  • retrieve historic quotes from Yahoo, Google, FRED
  • there's even a tradeModel that looks interesting
  • and well documented.
    
  
  
  - post by taylortree

Recent Links 09/05/2007

Speed up R, Python, and MATLAB - Going Parallel

• Reduce runtime of Python, R, and MATLAB applications by 85%?  Process 10-100X  larger datasets?  With just a few code changes?  Not quite sure how...but something to explore in the future.  Their success story on speeding up MATLAB code for Monte Carlo Analysis looks pretty easy of a code change to me.  Read their blog for further insights into HPC...
  
  • Multicore:  Why all the Hubbub?
  • What is "Productivity" in High Performance Computing?
  
  
   - post by taylortree

Recent Links 09/04/2007

World Beta - Engineering Targeted Returns and Risk: More On The Endowment Style Of Investing  Annotated

• World Beta shares some links covering the endowment investing side of things...
  
  • A link to
    Frontier Capital Management
    - check out their knowledge section for more great papers similar to the ones Faber links to.
  • Faber mentions a great upcoming book covering the twelve top endowment CIO's .
  • from Alpha Magazine...Highbridge Capital Managment shares its office organization - putting traders and developers together.  I've always thought this would be a great idea in any shop.  By putting users and developers together - manual taks can be seen and automation can happen.
    
  
  
   - post by taylortree

Frontier Capital Management

SourceForge.net: tkdiff

• Great little file compare utility.  Graphic front end to the diff program.
  note:  tested this today against a large file/program (well, not that large in my line of work...but I guess to Google's)...couldn't handle it.  But, works great on small files.
   - post by taylortree

Google Mondrian: web-based code review and storage

• Online code review that works like a blog/wiki.  I wonder...is it possible to create a code review system similar to Mondrian within a source management toolset such as subversion?  Seems like most of the backend is there already...would only need to add some front end tools to display the changes being committed and allow comments on those changes.
   - post by taylortree

Recent Links 09/03/2007

ONLamp.com -- Numerical Python Basics

• Numpy basics.
   - post by taylortree

Programming in R

Finding Duplicate Elements in an Array :: Phil! Gregory  Annotated

• Interesting way to find duplicates in an array.  Enjoyed the links on the pigeonhold principle and Floyd's cycle-finding algorithm.
   - post by taylortree

Now, suppose that the array is of length n and only contains positive
integers less than n. We can be sure (by the pigeonhole principle)
that there is at least one duplicate.

So, how do we find the beginning of the cycle? The easiest approach is to
use Floyd's cycle-finding algorithm. It works roughly like this:
Start at the beginning of the sequence. Keep track of two values (call
them a_i and a_j). At
each step of the algorithm, move a_i one step
along the sequence, but move a_j two steps. Stop
when a_i = a_j.