Just published that article I had promised about the Anatomy of a WL7 Strategy, including some discussion about variable scoping ...
https://www.wealth-lab.com/blog/anatomy-of-a-wl7-strategy
https://www.wealth-lab.com/blog/anatomy-of-a-wl7-strategy
Rename
QUOTE:
Anatomy of a Wealth-Lab 7 Strategy:... ... synchronization of symbols ...
I would copy the WL6 documentation about synchronization and include it in there as another topic as well. Yes, all the WL6 users have read that chapter and understand why that operational step is necessary. But not every WL7 user has.
And just because you know what synchronization is doesn't mean you know how to apply it. I knew what synchronization was, but I was still trying to plot multiple symbols on the same Chart without success in BacktestComplete{}. That's when you told me they all need to be time synchronized first with BarHistorySynchronizer.Synchronize(...). It was at that point that I understood what synchronization was for.
I think that deserves its own article.
You can't just share this valuable info! A user must get this information during many-many questions and discussions here bit by bit. As we did!
Good article. Most of this I know by now, but this article looks like a good timesaver for new users.
P.S. I found something interesting for me too. About scoping and static variables instead of global.
Good article. Most of this I know by now, but this article looks like a good timesaver for new users.
P.S. I found something interesting for me too. About scoping and static variables instead of global.
What exactly do you want to know? To me it seemed Superticker was looking for more elaboration on Synchronization in general. This deserves it's own article that takes time to write and edit. Is there some specific info you want answered now?
QUOTE:
What exactly do you want to know? To me it seemed Superticker was looking for more elaboration on Synchronization in general. This deserves it's own article that takes time to write and edit. Is there some specific info you want answered now?
The first part of my comment was meant to be a joke. And the second part was meant to be a compliment.
Sorry if it didn't look like that)). Maybe it's because of my English. Although, if you use only "!" without ")", the likelihood of your joke to be considered like a joke decreases dramatically in any language)).
The article is good!
haha ... ok if you really want to get across that it's a joke you can use ;)
QUOTE:
haha ... ok if you really want to get across that it's a joke you can use ;)
I just like serious-face jokes, but they can get out of control, like this one).
QUOTE:
I found something interesting ... About scoping and static variables instead of global.
Same here. I was using BarHistory.Cache["key"] for all shared objects in order to move data from Initialize{} to another block. (And for PreExecute{} and PostExecute{} operations, that's still necessary of course.)
But I see I can safely declare "common 'shared' objects" as static field variables in MyStrategy to share them between Initialize and Execute. I didn't appreciate each symbol got its own private instance of MyStrategy until now (which includes all the static field variables). This was never explained before.
QUOTE:I'll take exception to that. I explained it to you in my solution of using a static List for the synchronous Debug Log (before the new solution with the WriteToDebugLog overloaded boolean parameter).
This was never explained before.
See Posts about #13
https://www.wealth-lab.com/Discussion/Should-symbols-be-executed-synchronously-in-portfolio-backtest-6801
In fact, it looks like that's the discussion that gave Glitch the inspiration to write the Blog :)
QUOTE:
This was never explained before.
QUOTE:
I'll take exception to that. I explained it to you in my solution of using a static List for the synchronous Debug Log
I should have been clearer. I meant the use of "static" for shared variables was never explained in the WL Help or QuickRef docs. If it was in there, I would have seen it months before.
Salient details (such as handling of shared variables) should be placed somewhere in the Help or QuickRef docs so people at least know about these issues. And a link can be included there to a blog article if a more detailed discussion exists.
But I understand you're trying to prioritize the code development over the documentation right now. And that's probably the right approach until WL7 gets more filled out with critical features. It's a balancing act, and WL users appreciate that.
When I type in the following code:
the following code is automatically populated
So the complete empty code for the PreExecute() function is as below:
Should the inserted code:
be left alone.
CODE:
public override void PreExecute(DateTime dt, List<BarHistory> participants)
the following code is automatically populated
CODE:
base.PreExecute(dt, participants);
So the complete empty code for the PreExecute() function is as below:
CODE:
public override void PreExecute(DateTime dt, List<BarHistory> participants) { base.PreExecute(dt, participants); }
Should the inserted code:
CODE:
base.PreExecute(dt, participants);
be left alone.
You can delete that line, the base level implementation of that method is empty.
Thanks Glitch. Also for the
CODE:method, is it possible to access the BarHistory object within this method?
BackTestBegin()
You can access all the BacktestData using the BacktestData property ...
CODE:
public override void BacktestBegin() { BarHistory bars = BacktestData[0]; System.Windows.MessageBox.Show(bars.Symbol + "\t" + bars.Count); }
Thank you.
Your Response
Post
Edit Post
Login is required