That's an interesting algo. I like the combination of ideas.

I think that it shouldn't be too hard to keep track of how many signals you have. One question would be, when you go from 3 to 4 signals, for instance, whether or not it's worth the transaction costs to do the rebalancing.

It might be interesting to use set_universe too, and see what different universes of stocks look like in this.

For the negative cash, there are a couple possible reasons. 1) You have $1000, and the price is $100, so you buy 10 shares - but the price you get is $101, so you have negative cash. or 2) You place a big order on day 1, and it gets partly filled. On day 2, you still have a lot of cash, and you place more orders, and then the old and new orders are filled, and you have negative cash.

The first one is hard to avoid without using limit orders. The second one you can avoid by adapting Gus's order code.

You could also check out a template that is still in development but limits leverage on a portfolio - https://www.quantopian.com/posts/template-limiting-leverage-by-brandon-ogle-and-dan-sandberg - in the case of the template, orders that would generate negative cash are canceled. You can amend the template to iteratively scale down the order until you do NOT generate negative cash.

Also, with regard to investing more of your capital "at the beginning", the template I posted includes a "pause" function that will invest in the benchmark until a set timestep. This way you can collect data in the backtest for a certain period of time and then "start" investing.

For everyone who's intrested:

I made a few quick improvements:
- Algorithm is now investing all availible cash
- More intelligent distribution of availabe cash (only those sid's with signal_strength > 0 are considerd)
- Evaluation of signals (instead of buying whenever one of them occured, buying now when at least two occur)

Thanks for your suggestions i'll be looking into them as soon as i can. Also I'm thinking of further improving distribution of cash (distributuion according to signal_strength which ranges from 0 to 4). I'm sorry my documentation is a bit weak. I'll improve upon that in the next version as well

There is a bug in the code calculating signal_strength, and results in signal_strength higher than 4. Adding in a comparison with sum(signals), and from log we can see the difference. I still have no idea why the following code could get a strength of 18 or so.

        for signal in signals:  
            if signal == True:  
                context.signal_strength[cur_sid] = context.signal_strength.setdefault(cur_sid, 1) + 1  
        print [signals, sum(signals), context.signal_strength[cur_sid] ]  

2008-03-20PRINT[[False, False, False, False], 0, 16]
2008-03-20PRINT[[False, False, False, False], 0, 13]
2008-03-20PRINT[[False, False, False, False], 0, 9]
2008-03-20PRINT[[False, False, False, False], 0, 10]
2008-03-20PRINT[[False, True, False, False], 1, 18]

My first guess is i need to reset signal_strength every time handle_data is called. Forgot to do that, thanks.

EDIT:
Adding the line:
context.signal_strength[cur_sid] = 0
Anywhere before the code seen above fixes the problem.

The aforementioned bug actually makes profit a lot higher than the original algorithm. From this, I think it tells us that signals a few days back also holds some useful information. Thus I change the algorithm to look 5 trading days back and trigger buy when there is a sum of signal_strength greater than 8. I also make stop loss price lower to be 0.9 of purchase price.

@Roy Zuo
I'm not convinced that past signals are relevant. Performance increases, that is true. However every security within the portfolio is rising pretty much over the whole period of the backtest anyway. I do not have time to test your changes with other securities right now (exams), but it might be that it does quite a lot worse than my original algo. Than again it might perform better... we will see.

I've been toying around with 90%, and other values, of bought price as well. However i experienced best performance with 100%. This might however also be caused by choice of securities.

@Johann Seber

I agree with you that choice of stocks may make a great difference. The best way I can think of to verify is to use a universe instead of hand picked securities. However, right now there is a bug with set_universe and it does not work with ta-lib very well, and we may want to wait for a few days for the bug to be fixed.

set_universe bug fixed. Backtest for set_universe security selection added. I use event objects' stddev function instead of talib's because this makes backtest run faster.