A hack would be to consider if you need the full precision of each of the 5 recorded scalars. If not, you could devise a scheme to store more than 5 lower-precision scalars. For example, say that the first recorded variable is a 4 digit integer. You could break it up into two, two-digit integers, each running from 00 to 99. In your backtest, you'd need something like encode_recorded_variables() and in the research platform, a complementary function, decode_recorded_variables().

Looks like there should be plenty of precision:

In [5]:

type(result.recorded_vars.values[0,0])

Out[5]:

numpy.float64  

Or, in the algo code, if you store integers:

In [8]:

type(result.recorded_vars.values[0,0])

Out[8]:

numpy.int64  

From http://docs.scipy.org/doc/numpy/user/basics.types.html, we have:

int64 Integer (-9223372036854775808 to 9223372036854775807)

So, since Quantopian is generously using 64 bit variables, they can be chopped up (e.g. down to 12-bit pieces), probably with negligible effect for most applications, due to the lower precision.

Another angle is that there is one record() post per trading day, so back-of-the-envelope (assuming 8-bit values):

252 trading days per year x 5 recorded variables per day x 8 values per variable = 10,080 values per trading year

The longer the backtest, the more data that can be transmitted from the backtester to the research platform.

It probably couldn't be more awkward, but the "pipe" has been laid by Quantopian. It just needs a good shot of Drano!

Hey Simon,
At this point there isn't a way to have more than 5 recorded variables, but this is on the list of things to add in the future.

KR

Simon,

Depending on what you're doing, you could load algo parameters via fetcher, and also upload the fetcher file to Q research. Once you run the backtest, you could pull in the results into Q research, and also read the uploaded fetcher file.

Again, not so elegant, but for certain applications, it should work.

Of course, you could scrape the browser pages of the algo, including the log output, and upload the info. to Q research in a file.

Grant

Being able to access the log output from research to parse it would be very helpful.

Seems like including everything in context (or at least a subset) would be handy. Maybe a function store(context.my_stuff) would do the trick.