Better way to orchestrate a set of indicators within an EA?

[Marcel Fitzner]

Hi guys,

writing an EA that accesses signals from indicators comes with the task to fill their parameters when creating their handles.
Because I am not integrating all of these indicators in an EA - I have to re-define all parameters of these indicator in the EA.

A brief example to outline what I mean:

My-Special-EA

| input int InpParamForLongMA = 200
| input int InpParamForMediumMA = 100
| input int InpParamForShortMA = 50

| ---- Indicator1 [m_handle1 = IndicatorCreate(Symbol(), Period(), IND_CUSTOM, 1, InpParamForLongMA); ]

| ---- Indicator2 [m_handle2 = IndicatorCreate(Symbol(), Period(), IND_CUSTOM, 1, InpParamForMediumMA); ]

| ---- Indicator3 [m_handle2 = IndicatorCreate(Symbol(), Period(), IND_CUSTOM, 1, InpParamForShortMA ); ]

This example is really super simple, but imagine you have like 10 indicators with each varying parameter count starting from 1 up to 10. The list of parameters to redefine in an EA is becoming a real burden. Not to speak of the terrible long list that the user has to visually manage when he/she configures that EA.

Is there any smarter way to completely avoid this code duplication?

I thought of placing parameters in an ini-file, so that pairwise both the EA and the indicator could access the parameters, but then running the EA in a Strategy Tester won't work anymore.

Any comments are appreciated!

Cheers,

Marcel

[[Deleted]]

Marcel Fitzner: ...Is there any smarter way...any comments are appreciated...

Yes, there is. As I see you have a development background so I'll comment in more technical terms.

Express your indicator conditions in a more generalized way, independant of input parameter restrictions. For example for simple moving averages:

input Entry = "@uptrend(<name>,<timeframe>,<parameters>) ||(@uptrend(<name>,<timeframe>,<parameters>) && @uptrend(<name>,<timeframe>,<parameters>))";
input Exit  = "@downtrend(<name>,<timeframe>,<parameters>) || @profit(3%) || @loss(-1%)";

This way you can express with 2 inputs whatever indicator condition you like. Indicator parameters go into the field <parameters> and are separated by e.g. commata. So any number and type is supported.

If you add a new indicator to your logic you have to add the <name> and <parameters> parser for the new indicator only once, no changes to your input section is needed. The disadvantage of this approach is you cannot easily optimize anymore as parameters are hidden by a string representation. Imho still a good compromise.

Look at my public SnowRoller EA . There I have about 10 trend indicators with different number and types of parameters which I can easily switch/combine to entry/exit conditions without code changes. Parsing logic e.g. for the Jurik Moving Average (3 parameters) is here: double GetJMA(int timeframe, string params, int iBuffer, int iBar). You may want to support default values to not have to specify the full list of available parameters: While the ALMA supports 4 parameters most of the times a single one (periods) is enough: double GetALMA(int timeframe, string params, int iBuffer, int iBar).

[Marcel Fitzner]

Woa, very nice, mate! Thanks for your reply - very much appreciated! I'll have a look into this and come back if need be - but I guess your example will be more than sufficient! :)

Best wishes - M.