Unless something has changed, no. You just get a list, automatically sorted by "LAST MODIFIED". Even a simple option to sort by "NAME" would help (then one could do 'blah_v0', 'blah_v1', etc. and have things nicely organized).

@Grant
You have 408 algorithms,5438 backtests,2388 posts.
How do you handle them without simple organizing tools?

A lot of them are simple examples, written to assist other users, try out new functionality, debug, etc. Presently, I only have a few that I would consider works underway. It is a big mess, though. Normally, at a minimum, I would put old work in an "archive" folder.

+1 for wanting better organizing tools

Janene

We completely agree and this is on our feature roadmap. Thanks for the feedback!

Jean
Quantopian

Hi Jean,

At some point, I recall Fawce mentioning a vision of github integration (or something like it), so that algos (and research notebooks?) could be managed properly. This would also set things up for team collaboration, etc. While you could add some simple features for organization, it won't really put us on par with what is needed for full-up software development (which, for a $10B hedge fund, would be prudent).

Perhaps you could lay out the whole envisioned architecture?

Grant

Along the same lines, the compare function is very handy for looking at different versions/backtests of the same algorithm. I would think that it is low hanging fruit to integrate comparison stats (Sharpe, Beta, etc.) into that same view or even have a more verbose table representation of the previous backtests. It's rather difficult to keep track of what impact your changes are having on the algorithm if you can also see the returns of the backtest without delving into the backtest. Maybe even just an exported CSV would be easy to do?

I'd also really like just the simple feature of being able to append a note to different backtests of the same algorithm (I suppose a comment at the top of the code may be a work around though).

I would love to see versioning built-in, for several reasons. First, it would prevent accidental deletion while working on an algorithm.

More importantly, it would very useful for the versioning to keep meta-data about the backtest results for that version. The way I work-around this limitation is to create multiple versions of the same algorithm inside Quantopian, and then I manually document my parameters and the backtest results into a spreadsheet. (The side benefit of this is that I can run multiple backtests in parallel.) This method is how I identify correlations between my parameters and the backtest results.

Dear all,
I believe there are quite a lot in terms of managing one's code snippets and strategy, to the extent of one strategy including multi-strategies.This has to be done through Zipline (although not if one uses fundamentals).

My initial attempt is here: https://github.com/florentchandelier/zipline2quantopian
It includes a file structure to automatically export Zipline code to Q, with support from automatically generated Q code from bash (for common snippets).

I'm currently updating this structure to provide a more versatile one, specifically targeting multi-strategies inclusion in a cleaner way (currently folders have to be copied, or symbolically linked in linux to prevent copy/pasta).

Indeed, when you manage your own money, there is one thing you should avoid: duplicates, or copy/pasta ... -> exponential risk of bug proliferation

Best,