Current location | Thread information | |
![]() ![]() ![]() ![]() ![]() ![]() |
Last Activity 10/7/2016 12:00 PM 7 replies, 669 viewings |
|
|
Printer friendly version |
^ Top | |||
John W![]() Elite ![]() ![]() ![]() ![]() Posts: 654 Joined: 10/11/2012 Location: Sydney, NSW, Australia ![]() |
This is a feature request. When a dynamic portfolio is created, it’s only possible to see the results going forward in time. It’s often useful to be able to see how a portfolio may have fared through an earlier timeframe, assuming of course that the strategies existed in that earlier timeframe. Although it’s possible to look backwards in time with a Custom portfolio, it’s not possible to do this with a dynamic portfolio. I built a dynamic portfolio over the period 1/31/2013 - 1/31/2014. Now look what happens when I go back to (say) 1/31/2012 – 1/31/2014. All strategies selected were in use at the earlier 1/31/2012 timeframe. As you can see, the portfolio provides no information about its performance in the timeframe preceding its Jan 31 2013 build date, although the strategies do exist at the earlier timeframe. [Edited by John W on 8/11/2014 7:15 AM] ![]() | ||
^ Top | |||
Steve Mayo![]() Legend ![]() ![]() ![]() ![]() Posts: 414 Joined: 10/11/2012 Location: Austin, TX ![]() |
It's a known limitation that needs to be better documented. As you know, it takes a lot of time and horsepower to run the ECA so it's not practical to automatically re-run everyone's dynamic portfolios backward on-the-fly over periods they didn't test originally. You can always just build a new dynamic portfolio with the same strategies and the same settings, except for an earlier start date. | ||
^ Top | |||
John W![]() Elite ![]() ![]() ![]() ![]() Posts: 654 Joined: 10/11/2012 Location: Sydney, NSW, Australia ![]() |
So theoretically the simplest way to handle this is to do one run off all the EF's at the earliest possible date, then there is no need to change the date settings and then the issue is solved forever? Perhaps that's the simplest way forward programmatically, is for Nirvana to build the Portfolio at the earliest possible date for the 'lookback period' selected by the user. No date settings are necessary! This would save all of us crunching PW over different date settings - just do it once (because date settings would then be irrelevant) and then that's it until you decide to add another EF or you want to try different strategies or lookbacks! What do you think? [Edited by John W on 8/11/2014 4:39 PM] | ||
^ Top | |||
Steve2![]() Elite ![]() ![]() ![]() ![]() ![]() Posts: 750 Joined: 10/11/2012 Location: Annapolis, MD ![]() |
John, I would not be in favor of doing this. PW run times seem to be linear based on the number of months in the simulation date range, number of enabled EFs, and number of enabled strategies/strategies selected. Having PW runs automatically compute the entire date range for all EFs would cause runs to take much longer, reducing the total number of runs that could be performed per day which would lead to longer wait times for all Pro users. An individual user is free to submit runs like that (and wait a long time for them to finish) but I think that should be the user's choice. Unless there are VERY significant performance improvements that can be made in PW, I think the way it works now is best. What Nirvana does need to do is (1) clearly document the difference in how static vs dynamic portfolios work in simulations and (2) have OV generate warning messages when there is a mismatch between simulation date ranges of the account and any dynamic portfolios configured into the account. Steve [Edited by Steve2 on 8/11/2014 5:15 PM] | ||
^ Top | |||
Steve Mayo![]() Legend ![]() ![]() ![]() ![]() Posts: 414 Joined: 10/11/2012 Location: Austin, TX ![]() |
That's actually what I had suggested at first too. :-) Currently, Nirvana is working to add the ability to parse parameters (such as the slow/fast in an MACD) which will could result in a huge number (100's, maybe 1000's) of EF permutations. The thinking was that most users wouldn't want to endure a multiple-day processing time as a default for such a run. Instead, we thought it better to give users the OPTION of running longer time spans on an individual portfolio basis, i.e., just the few out of those 100's that you might actually want to trade (after running a shorter period to get a first look). | ||
^ Top | |||
Steve2![]() Elite ![]() ![]() ![]() ![]() ![]() Posts: 750 Joined: 10/11/2012 Location: Annapolis, MD ![]() |
Steve, Any idea if N will add additional resource management capabilities before allowing runs to compute a bunch of EF parameters. I would be worried about a small number of users essentially blocking everyone else for several days. Seems like it would be good for N to support multiple queues and route runs to the appropriate queue based on estimated run time. Steve | ||
^ Top | |||
Mark Holstius![]() Elite ![]() ![]() ![]() ![]() Posts: 744 Joined: 10/11/2012 Location: Sleepy Hollow, IL ![]() |
That sounds like an excellent idea, Steve(2). Actually, I told Ed I saw where you can get a small Cray for $500,000... ;-) Mark | ||
^ Top | |||
Steve2![]() Elite ![]() ![]() ![]() ![]() ![]() Posts: 750 Joined: 10/11/2012 Location: Annapolis, MD ![]() |
Naw, nothing that drastic needed. A handful of blades will do the job as long as the architecture supports distributing runs across them. All kidding aside, hopefully there is a plan to rapidly scale the HW config as the number of users grows. At some point things will take off and they need to be ready to react quickly. Steve |
|
|
Legend | Action | Notification | |||
Administrator
Forum Moderator |
Registered User
Unregistered User |
![]() (un)/Freeze thread | |
Toggle e-mail notification |