- Joined
- 13 June 2007
- Posts
- 838
- Reactions
- 136
Greetings all --
Several recent threads in the Yahoo AmiBroker inspired this posting which focuses on issues related to portfolio construction. It may be interesting to some of the ASF members as well. http://finance.groups.yahoo.com/group/amibroker/
Portfolio construction is an interesting and important problem. But it is not easily solved without either violating good modeling and simulation practices or making some restrictive assumptions.
One complication arises from the two-stage nature of the portfolio creation. Stage one is system development for the individual trading systems, call them A, B, and C; stage two is the system development for the portfolio system, call it P. The portfolio, P, draws from a single trading account and allocates resources to trades signaled by A, B, and C. The desire is to construct the portfolio to manage resource allocation, manage risk, net out trades, and so forth.
To begin, I'll give a simpler illustration -- an individual trading system that uses equity curve feedback to gate trades. There are two stages in this system. The basic logic of the system, call it D, and the equity curve filter logic, call it E. There is afl code for each stage, and the goodness of each stage can be measured by the score of the objective function.
Assume that system D is developed by itself, without the equity curve feedback logic in its afl. System D produces buy and sell signals and a resulting equity curve. If there were no equity curve filter logic to follow, this is the system that would be tested and validated through use of the walk forward process. But these signals and this equity curve are not final -- they will be passed to the equity curve filter logic. Call the results from system D the "shadow" results. The equity curve filter logic, in its own afl module, accepts the shadow results data series produced by D as its input. That is, the shadow buy, sell, and equity from D are input to E. System E has logic and parameters which are adjusted in a system development process and evaluated by computing an objective function. System E must pass the validation process. System E cannot use the same in-sample period that was used to develop system D. The output from that period is "too good" and is not representative. The equity curve logic, system E, must use out-of-sample results from system D as its in-sample data. The complication this creates is that the two stages use different data streams and different data periods for their respective in-sample processing. It will probably be necessary for system D to write its shadow output to a temporary data file, and for that data file to be edited so that it contains only system D's out-of-sample results concatenated together so system E can process them.
Alternately, assume the equity curve filter logic, E, is incorporated with the logic of system D into a single afl code module. Call that new system DE. The shadow trades and signals from the D logic are processed by the E logic during a single pass. The in-sample period is the same. The output is already gated. The system DE can be validated in one pass.
Moving on to the creation of the portfolio. Portfolio logic -- that is trade selection and position sizing logic for the portfolio -- is similar to equity curve filter logic -- it is a second phase. It is a trading system in its own right. Its logic and parameter values will be selected through an optimization process, and its result will be evaluated by an objective function. The objective function for the portfolio may have different component metrics than the objective function for the individual systems. For example, it may have trade size and risk components in addition to the more traditional components such as equity curve smoothness.
An immediate question that arises is whether to use systems A, B, and C as they are individually developed at their individual optimums. Or if there are better logic and parameter choices for A, B, and C as they are to be combined into a single portfolio.
Again, the choice will be between multistage development and single stage development.
The multistage approach assumes that the best individual A, B, and C create the best portfolio P. This approach has each of A, B, and C being developed, tested, and validated separately. The output of these systems is again "shadow" output, since it must be processed by the portfolio logic. Again, temporary files will be necessary and only the shadow output's out-of-sample results can be used for the portfolio development. The messiness and complexity of portfolio construction has increased considerably over the equity curve example.
When we consider performing the entire portfolio development in a single pass, some other issues arise.
One is the curse of dimensionality -- the increase in the dimension of the search space for logic and parameters. If each of A, B, and C have four optimizable parameters, each with ten steps, an exhaustive search will create and evaluate 10,000 alternatives for each system. If P has two optimizable parameters, each with ten steps, an exhaustive search will create and evaluate 100 alternatives. The total is 30,100. At 1000 per minute, this takes 30 minutes. If those same parameters are searched in the all-in-one logic, which now has fourteen parameters, an exhaustive search will create and evaluate 10 to the 14th power alternatives. At 1000 per minute, this takes about 200,000 years. AmiBroker's non-exhaustive search will help, but this will still be a long run.
Another, perhaps more significant, issue is the standardization of the length of the in-sample periods. Each system is a combination of a model (the part that contains the logic) and the data processed by that model. The system will have a sweet spot in terms of in-sample length. Using too short an in-sample period does not allow the logic to identify the pattern it is designed for; while using too long an in-sample period dilutes the data and lowers the signal to noise ratio. A system that trades the S&P long and short with five day holding periods will probably not have the same in-sample length as a system that rotates among nine sector ETFs with 20 day holding periods. But, if P, the all-in-one system, is to be tested and validated using automated walk forward procedures, the in-sample period will the same for all the individual systems and the portfolio. Of course, at the cost of additional complexity, the in-sample length could be set to the longest period needed, and those systems that need shorter periods could include logic to ignore the first portion of data. The in-sample results from the starting date up to the date when all the systems are active would have to be ignored when computing P's objective function.
Note also that, when each of systems A, B, and C are being tested separately, they each have their own objective function. The objective function for the system that swing trades might be different than the one for the sector ETF rotator. The objective function guiding development of the all-in-one portfolio system, P, is different still. Unless care is taken to gather trade statistics from each of systems A, B, and C, and apply whatever internal filtering is desired, it is quite possible that the parameters chosen for A, B, or C, in the effort to satisfy P, will result in non-optimal choices for A, B, or C. In fact, there might be intentional losing trades and a very ugly equity curve when it is viewed by itself. Unless the person trading this system understands the process by which it was created and is comfortable with it, they may decide to pass some signaled trades that appear to be obvious losers, thereby changing the system completely.
All of these issues must be considered and dealt with before going on to position sizing -- fixed fraction, fixed ratio, optimal f, partial f, and so forth -- which is much more complex for a portfolio than for an individual trading system.
All in all, portfolio creation and management is more complex than it appears at first glance. In my next book, "Advanced AmiBroker," I will be discussing these issues in more detail, and making suggestions for measuring and managing portfolios. That book is scheduled to be out near the end of 2009, after my return from speaking at the Australian Technical Analysts Association annual meeting. http://www.ataa.com.au/
As always, this is my opinion. If whatever you are doing now works for you, ignore me and don't change a thing.
Thanks for listening,
Howard
http://www.blueowlpress.com
Several recent threads in the Yahoo AmiBroker inspired this posting which focuses on issues related to portfolio construction. It may be interesting to some of the ASF members as well. http://finance.groups.yahoo.com/group/amibroker/
Portfolio construction is an interesting and important problem. But it is not easily solved without either violating good modeling and simulation practices or making some restrictive assumptions.
One complication arises from the two-stage nature of the portfolio creation. Stage one is system development for the individual trading systems, call them A, B, and C; stage two is the system development for the portfolio system, call it P. The portfolio, P, draws from a single trading account and allocates resources to trades signaled by A, B, and C. The desire is to construct the portfolio to manage resource allocation, manage risk, net out trades, and so forth.
To begin, I'll give a simpler illustration -- an individual trading system that uses equity curve feedback to gate trades. There are two stages in this system. The basic logic of the system, call it D, and the equity curve filter logic, call it E. There is afl code for each stage, and the goodness of each stage can be measured by the score of the objective function.
Assume that system D is developed by itself, without the equity curve feedback logic in its afl. System D produces buy and sell signals and a resulting equity curve. If there were no equity curve filter logic to follow, this is the system that would be tested and validated through use of the walk forward process. But these signals and this equity curve are not final -- they will be passed to the equity curve filter logic. Call the results from system D the "shadow" results. The equity curve filter logic, in its own afl module, accepts the shadow results data series produced by D as its input. That is, the shadow buy, sell, and equity from D are input to E. System E has logic and parameters which are adjusted in a system development process and evaluated by computing an objective function. System E must pass the validation process. System E cannot use the same in-sample period that was used to develop system D. The output from that period is "too good" and is not representative. The equity curve logic, system E, must use out-of-sample results from system D as its in-sample data. The complication this creates is that the two stages use different data streams and different data periods for their respective in-sample processing. It will probably be necessary for system D to write its shadow output to a temporary data file, and for that data file to be edited so that it contains only system D's out-of-sample results concatenated together so system E can process them.
Alternately, assume the equity curve filter logic, E, is incorporated with the logic of system D into a single afl code module. Call that new system DE. The shadow trades and signals from the D logic are processed by the E logic during a single pass. The in-sample period is the same. The output is already gated. The system DE can be validated in one pass.
Moving on to the creation of the portfolio. Portfolio logic -- that is trade selection and position sizing logic for the portfolio -- is similar to equity curve filter logic -- it is a second phase. It is a trading system in its own right. Its logic and parameter values will be selected through an optimization process, and its result will be evaluated by an objective function. The objective function for the portfolio may have different component metrics than the objective function for the individual systems. For example, it may have trade size and risk components in addition to the more traditional components such as equity curve smoothness.
An immediate question that arises is whether to use systems A, B, and C as they are individually developed at their individual optimums. Or if there are better logic and parameter choices for A, B, and C as they are to be combined into a single portfolio.
Again, the choice will be between multistage development and single stage development.
The multistage approach assumes that the best individual A, B, and C create the best portfolio P. This approach has each of A, B, and C being developed, tested, and validated separately. The output of these systems is again "shadow" output, since it must be processed by the portfolio logic. Again, temporary files will be necessary and only the shadow output's out-of-sample results can be used for the portfolio development. The messiness and complexity of portfolio construction has increased considerably over the equity curve example.
When we consider performing the entire portfolio development in a single pass, some other issues arise.
One is the curse of dimensionality -- the increase in the dimension of the search space for logic and parameters. If each of A, B, and C have four optimizable parameters, each with ten steps, an exhaustive search will create and evaluate 10,000 alternatives for each system. If P has two optimizable parameters, each with ten steps, an exhaustive search will create and evaluate 100 alternatives. The total is 30,100. At 1000 per minute, this takes 30 minutes. If those same parameters are searched in the all-in-one logic, which now has fourteen parameters, an exhaustive search will create and evaluate 10 to the 14th power alternatives. At 1000 per minute, this takes about 200,000 years. AmiBroker's non-exhaustive search will help, but this will still be a long run.
Another, perhaps more significant, issue is the standardization of the length of the in-sample periods. Each system is a combination of a model (the part that contains the logic) and the data processed by that model. The system will have a sweet spot in terms of in-sample length. Using too short an in-sample period does not allow the logic to identify the pattern it is designed for; while using too long an in-sample period dilutes the data and lowers the signal to noise ratio. A system that trades the S&P long and short with five day holding periods will probably not have the same in-sample length as a system that rotates among nine sector ETFs with 20 day holding periods. But, if P, the all-in-one system, is to be tested and validated using automated walk forward procedures, the in-sample period will the same for all the individual systems and the portfolio. Of course, at the cost of additional complexity, the in-sample length could be set to the longest period needed, and those systems that need shorter periods could include logic to ignore the first portion of data. The in-sample results from the starting date up to the date when all the systems are active would have to be ignored when computing P's objective function.
Note also that, when each of systems A, B, and C are being tested separately, they each have their own objective function. The objective function for the system that swing trades might be different than the one for the sector ETF rotator. The objective function guiding development of the all-in-one portfolio system, P, is different still. Unless care is taken to gather trade statistics from each of systems A, B, and C, and apply whatever internal filtering is desired, it is quite possible that the parameters chosen for A, B, or C, in the effort to satisfy P, will result in non-optimal choices for A, B, or C. In fact, there might be intentional losing trades and a very ugly equity curve when it is viewed by itself. Unless the person trading this system understands the process by which it was created and is comfortable with it, they may decide to pass some signaled trades that appear to be obvious losers, thereby changing the system completely.
All of these issues must be considered and dealt with before going on to position sizing -- fixed fraction, fixed ratio, optimal f, partial f, and so forth -- which is much more complex for a portfolio than for an individual trading system.
All in all, portfolio creation and management is more complex than it appears at first glance. In my next book, "Advanced AmiBroker," I will be discussing these issues in more detail, and making suggestions for measuring and managing portfolios. That book is scheduled to be out near the end of 2009, after my return from speaking at the Australian Technical Analysts Association annual meeting. http://www.ataa.com.au/
As always, this is my opinion. If whatever you are doing now works for you, ignore me and don't change a thing.
Thanks for listening,
Howard
http://www.blueowlpress.com
