Change vwap(3) to (1)

posted

Only change the vwap(3) to vwap(1).

24 responses

This's cloned from "discuss the sample algorithm" - https://www.quantopian.com/posts/discuss-the-sample-algorithm

Crazy how sensitive it is to the days of vwap. That's one of the hardest problems with parameter optimization - discrete values can cause big dislocations in the behavior.

Disclaimer

The material on this website is provided for informational purposes only and does not constitute an offer to sell, a solicitation to buy, or a recommendation or endorsement for any security or strategy, nor does it constitute an offer to provide investment advisory services by Quantopian. In addition, the material offers no opinion with respect to the suitability of any security or specific investment. No information contained herein should be regarded as a suggestion to engage in or refrain from any investment-related course of action as none of Quantopian nor any of its affiliates is undertaking to provide investment advice, act as an adviser to any plan or entity subject to the Employee Retirement Income Security Act of 1974, as amended, individual retirement account or individual retirement annuity, or give advice in a fiduciary capacity with respect to the materials presented herein. If you are an individual retirement or other investor, contact your financial advisor or other fiduciary unrelated to Quantopian about whether any given investment idea, strategy, product or service described herein may be appropriate for your circumstances. All investments involve risk, including loss of principal. Quantopian makes no guarantees as to the accuracy or completeness of the views expressed in the website. The views are subject to change, and may have become unreliable for various reasons, including changes in market conditions or economic circumstances.

Oh, actually, there's another difference - I think you're code has asymmetric notional limits $10M and -$100k, which gives it a very strong long bias. Since the stock is AAPL, I suppose it isn't shocking that the long biased returns are great.

Disclaimer

Yes, then genetic algorithm appear on the stage which should be save a lot of labor.

Yup, although we've been thinking it may be more efficient to just do a brute force exploration of discrete parameters. We are working on a walk forward optimizer, and I'm looking forward to trying it on this algorithm. I'm curious if the scale factor used on the vwap could be optimized more effectively than the number of days in the average, since the factor is continuous.

Disclaimer

Thomas Wiecki

Raymond: Yeah, genetic algorithms (GA) are definitely on our radar (among other things like particle swarm or gradient descent). Even though metaheuristic optimization methods like GA do not require the objective function to be smooth or concave/convex they do require it to not be totally unstructured.

I am currently running some experiments where I'm testing how the objective function looks like under systematic changes in the parameters to see whether that is the case. Once I have something to show I'll do a blot post about it.

Disclaimer

http://pastebin.com/F507tCRT

@fawce Oops! Thanks for pointed out this. Yes, the limits has been changed. A walk forward optimizer would be great! looking forward.

@Thomas Wiecki Looking forward to this too! Since I'm not a programmer, more lazy tools would be better. But also want to learn more knowledge in the programming for sure.

Rob Terhaar

@Thomas
I attempted to pass a variable into vwap() via context, but I received the following stack trace:

KeyError: __vwap_3  
File /zipline/lines.py:153, in stream_results  
for event in self.gen:  
File /zipline/gens/tradesimulation.py:108, in simulate  
for message in performance_messages:  
File /zipline/gens/tradesimulation.py:271, in transform  
self.simulate_snapshot(date)  
File /zipline/gens/tradesimulation.py:295, in simulate_snapshot  
self.algo.handle_data(self.universe)  
File algoproxy.py:425, in handle_data  
self.ns['handle_data'](data, self.algo_context)  
File test_algorithm_sycheck.py:36, in handle_data  
File algoproxy.py:394, in _transform  
return self.transform(sid, tnfm, event, *args, **kwargs)  
File algoproxy.py:457, in transform  
t_hash = self.transform_visitor.get_hash(t_name)  
File transformvisitor.py:197, in get_hash  
return self.transforms[name].get_hash()

@Rob
The way transforms are currently implemented, the system needs to know all the arguments to any transforms used by your algorithm before we begin the backtest. This restriction exists so that we can efficiently only the information your algorithm needs to run. Since python has no way of enforcing that a variable must be constant, transforms can only take literals (ie, numerical constants, strings, booleans, etc.) as arguments. We could probably document this restriction better though, as well as give a clearer error message when a test fails like this. Thanks for the feedback!

Disclaimer

Rob Terhaar

@scott
Thank you, that makes sense. How do you think I should implement a variable vwap transform? Should I redefine the vwap variable with different conditional restraints?

@Rob
We use the very useful ast module to figure out what transforms your algorithm uses before we run your code. This means that we're essentially checking your code for expressions of the form: data[sid(<number>)].transform_name(<number>) If your goal is just to be able to switch between different length windows during the test I would recommend defining all the vwap windows you want to
choose between by putting the following at the top of your handle_data call:

vwap_3 = data[sid(context.aapl)].vwap(3)

vwap_5 = data[sid(context.appl)].wvap(5)

...etc

With these defined you could then implement conditional logic for switching which vwap you use for signalling.

By the way, for constant state like your definition of aapl, you can avoid having to write context.aapl everywhere by defining aapl = sid(24) in your algo's global namespace (ie, in the area outside your initialize and handle_data calls). By doing so, you'll be able to reference the variable aapl inside both initialize and handle data. However, you won't be able to change the value of aapl
and have that change remembered between calls to handle_data.

Disclaimer

(Apologies for the gratuitous code blocks. Our quote parsing library still has some kinks to be worked out...)

Disclaimer

Apologies for the gratuitous code blocks in my post. Our quote parsing library still has some kinks to be worked out.

Disclaimer

Rob Terhaar

@scott
this makes sense, thank you for the examples!

It would be more interesting to run this strategy over 500 stocks individually, and then sort the results by the returns. Certain strategies only work for certain stocks, and only for short time periods. Is it possible to do this in your current framework?

It would be interesting to train a classifier, any chance you could add sklearn to your namespace?

Thomas Wiecki

@Vishal: Currently not possible, but it's a neat idea. I think one would need some kind of post-simulation code mechanism.

Yes, we're in the process of adding sklearn.

Disclaimer

@Vishal, scanning the performance of an algorithm over a large selection of instruments is a great request. how would you want to select the 500 stocks?

Disclaimer

My initial approach would be brute-force based, i.e. just take 500 random but highly liquid stocks and push them through the backtester. Then i would cluster the output, and carefully analyze the buckets. I would try PCA and some lagging models (ARIMA) to see how the stocks in the various buckets are related. Then re-calibrate

@Vishal, would you be good using daily bars for the scanning across ~500 securities?

Disclaimer

are your transforms all based on daily calculations? how do you get minute data? do you have a rolling queue structure, so I can access (say) the last 30 minutes of data by array indexing?

@Vishal,
Most of the transforms are calculated using a rolling queue structure that keeps track of the last N market days' worth of events. The transform objects themselves, however, are not currently directly accessible to your algorithm. Instead what happens is each transform appends its most recent message/value to the data object your algorithm sees. That said, if you wanted to access the internals of a transform, you could calculate it inside your algorithm rather than access it from the data object. If you look at Fawce's recent GLD/GLX pair trading algorithm, you can see that he used the EventWindow class from zipline to do just this. Zipline is our internal data pipelining library, and it is what we use to load/sort/transform data from our database. We're planning on open-sourcing zipline shortly, though if you send Fawce an email he might be willing to give you preview access.

In our current state, your algorithm automatically gets a data event corresponding to every minute, reflecting the state of each sid your algorithm references at the end of that minute. There is currently a hard cap at 10 sids referenced per algorithm, because ten years' of data at minute resolution adds up quickly. We're working on allowing algorithm writers to specify their event frequencies to facilitate easier debugging and to better facilitate the sorts of training strategies you're describing where an algorithm might sample a wider range of stocks at lower resolution.

Disclaimer