Is there some kind of error here? Line 222

: Current ratio of long-term debt < last year's ratio of long-term debt

long_term_debt = current_data[sid]['long_term_debt_equity_ratio'] > old_data[sid]['long_term_debt_equity_ratio']  

Well spotted! That must have been a typo by the original author. That 1 char change significantly impacted the drawdown and total returns as shown below.

looks like the earning season is killing this algo every once a while. Is there any way to avoid that?

We have data partners who provide earnings calendar data. One such example is EventVestor.

This data isn't currently usable in an algo, only accessible in Research right now. But you can familiarize yourself with it in preparation for the day that these partner data sets are usable inside algos. (that day is coming!)

The event data is well suited for risk management, as you suggest above.

And looking at the content of the algo, I'd bet that the new Pipeline API would make this type of algo a lot simpler and open you up to a larger universe of stocks to rank. The initial fundamentals query limits you to 490 stocks right now. The Pipeline API lets you build ranking systems over the entirety of the tradeable universe.

The thing is, earnings often move the price significantly - that is just part of any algo that is in the market all the time.

I think what would make this a killer algo is adding shorting for the reverse of its rankings. Right now it is long only - which reflects in the performance of 2015 - i.e. not very good. Making it long / short with zero market exposure would really make it something nice.

Josh is right - using pipeline api would help with better rankings, specially when it comes to identifying the shorts.

Sorry for my misunderstanding. I am new to this field. So what I am looking for is abnormally patterns, and from the back-testing results, I notice the earning season is not favoring our algo. Therefore, is there anyway to limit the earning season results to our algo? For example, don't trade in the earning season. Overall, this is just a thought from a beginner. Thanks!

Well, Im not sure what your proposal would be. You could exit the longs just before earnings announcements, but like Josh said, you would need to know exactly when earnings are - which would require access to an earnings calendar in the algo - which we don't have right now.

Also, Im not sure how you concluded that "the earning season is not favoring our algo"? Did you test this theory?

Any idea what the time delay is on updated Fundamental Data? There could be significant returns lost due to delayed data.

Hi Mohammad,

I am new to this area so I might come up with some idea that is not so relevant to your algo. No offense at all. So I did not test this theory. And what I did is simply look at the graph. Noticing that quite a few downturns happened during the earning seasons. This is simply a naive hypothesis.

Is there anyway we could omit earning season effect, which means we do not trade during Mid Jan to Early Feb, etc. Again, it is just a thought. Probably I will do myself when I learn more coding. Thanks anyway!

@Haolun, it is not possible to implement what you are suggesting with Quantopian right now - but probably will be in the near future considering how fast the Q team work on extending the platform.

In the meantime, I tried adding the "sell in May and go away" strategy to the system, but it was not fruitful.

If you want to play with it yourself, you could drop something like this into the algo:

    date = data[data.keys()[0]].datetime  
    month = date.strftime("%B") #get current month as a string  
    if month in ('May', 'June', 'July', 'August', 'September'):  
        context.sell_all = True  
        for stock in context.portfolio.positions:  
            if (stock in data):  
                order_target_percent(stock, 0)  

Thanks a lot! I will check the results.

Hi guys,

How come this error appears after about 5% achieved of a 2003-2015 backtest ?

Something went wrong. Sorry for the inconvenience. Try using the built-in debugger to analyze your code. If you would like help, send us an email.
Exception: inputs are all NaN
There was a runtime error on line 90.

Try using the debugger and set a conditional breakpoints around the dates the algo is failing. You can step through the parameters and see how they're getting populated.

I played with pipelining but it's super slow and breaks because of memory.

Hi Lucas,

I just remade your algo to optimize it a little bit more memory-wise. I split up all of the subcomponents of the Piotroski score into individual CustomFactors. The logic behind this was that you don't actually need a 100-day window for each of the data fields. By breaking them up into individual components, you don't spend any time/memory getting data you don't need! I then sum them all together in the before_trading_start function into the Piotroski score.

I hope this helps!

thank you jamie i am working at the same thing and this is my first attempt, i have to rank a make the scores now, mabye i will continue with my code just as an exercise but your example here is very usefull to me thanks!

how do you utilize minute data with this?

@Daniel: Unfortunately, pipeline is only designed to operate on daily data for performance reasons. In order to run this on minutely data, you would have to implement the algorithm without pipeline. As a result, you would be bound by the 500 security limit to filter from. You would have to filter only a specific list of stocks.

Ah, I got ya. Ok. Thanks for letting me know.

@Mohammad how to eliminate this 1 year wherein.. there's no activity.. its so annoying.... tnxs...

Im not sure you can. I think it needs 1 year of data to get the scores. If you look at line 173 it specifically makes sure that a year has passed before it calculates the scores.

The pipelined version Jamie, Giuseppe and I were using gets rid of it, as you can see in the backtests.