Design question about many symbol EA - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
gordon - thanks for the links, this site has so much info and the 1+2 idea will be looked at - obviously, I do not spend nuff time reading around - maybe the fire is burning out.. oh merde!
[...] if it's such a CPU hogger as jjc suggests, then no point even trying it.
Your suggestion of running the EA on an infinite loop with something like a Sleep(100) should be fine in terms of resource usage.
The thing I was referring to which kills the processor is forcing another call to start() from within a call to start(). You basically end up with start() being called as often as the processor can manage. Which continues until one of the calls gets dropped, and the EA then goes dark as normal until the next real tick.
damn, have really worked hard to make multisym but reading all of above seems to highlight how I've blind-sided self due to the hahaaa coolness of just one EA.
I'm still staying out the broader design question, but there's one other advantage to multiple EAs. It gets mentioned a lot, but not yet in this topic... You can backtest the multiple EAs, and aggregate the results. You can't backtest a single EA which is trading all the symbols.
You can safely ignore them. jjc's got the winner. Anyway, if it's such a CPU hogger as jjc suggests, then no point even trying it.
Good point, but the material should be read I think, if only for the education...
One thing I use all the time now is a FSM design. That, for me anyway, works great for multi sym and massively no-pain modifiable. Use it also for trade entry/management/exit recognition especially when chart signals could mature over many bars.I'm getting the hint that generally, you people do the single sym design and then just shove out to all charts etc.
Your suggestion of running the EA on an infinite loop with something like a Sleep(100) should be fine in terms of resource usage.
The thing I was referring to which kills the processor is forcing another call to start() from within a call to start(). [...]
It hadn't occurred to me that you could do something like a Sleep(100) in the call to start() before triggering the next call. That would probably solve the performance issue, but it wouldn't solve the reliability. There'd also still be problems getting access to the properties window.
I'm still staying out the broader design question, but there's one other advantage to multiple EAs. It gets mentioned a lot, but not yet in this topic... You can backtest the multiple EAs, and aggregate the results. You can't backtest a single EA which is trading all the symbols.
I've got that covered via internal checks if testing... so can run with tester on any chart.
Design wise, my idea was to have the platform for simple implementation of any fx system. All the surrounding code is there to be called as required by the system under scrutiny. iow, only have trade entry and exit decision functions which are needing mods to use new system while the rest of code deals with management.
however, it still begs the question as to why I've taken this route and bought into the added complexity.
anybody know of a good head doc??? lol
Your suggestion of running the EA on an infinite loop with something like a Sleep(100) should be fine in terms of resource usage.
I know... I thought u were reffering to my number 2 suggestion (which is similar to yours).
The thing I was referring to which kills the processor is forcing another call to start() from within a call to start(). You basically end up with start() being called as often as the processor can manage. Which continues until one of the calls gets dropped, and the EA then goes dark as normal until the next real tick.
One thing I use all the time now is a FSM design. [...]
What's FSM?
What's FSM?
Pastafarianism
Now I am confused. Let's say u do my number 2 suggestion from 4 other pair, on average the EA will run 5 times as much as it did before... That's not going to be so bad for the CPU (even if the EA is extremely resource intensive). What am I missing here?
You're not missing anything in terms of performance. This form of multiple-chart arrangement does worry me, however, because an EA can get its own chart handle reliably, but there are many practical issues involved in one chart getting the handle of another chart.
WindowHandle(Symbol(), Period()) is more or less guaranteed to work regardless of what the user does. It even seems to work reliably if there are multiple charts for the same symbol and timeframe. Whereas, on the other hand, retrieving the handle of another chart requires four things to be configured/known correctly:
I'm not saying that that your suggestion #2 won't work in any sense - and I didn't give it enough attention first time round. But it would worry me in terms of the scope for user error.