More than ever, we have to concentrate on algos that are more self- adaptative to market conditions.
In this background I would like to propose SQ X to include in future some functions that could help us users deal with very varying market conditions along large periods of time. I'm aware that many functions have different degrees of complexity of implementation, bur here they are:
1) Include the possibility to chose also the IS periods to optimize. Right now we chose a period and select multiple periods of OOS. The non-selected periods are IS. If I want, for instance to select specifically periods of optimization in which ATR(14) is below a certain level (to later limit this EA to function only in that market condition) I need to work with specific IS data as well (not the IS that results from exlcuding the OOS).
2) allow for selecting the data to work with (IS and OOS) not only visually or by date periods, but also by indicators (like ATR(14) higher, lower or within certain values. Other indicators could also be used to selec the data for optimization, such as trending indicators, versus ranging indicators.
3) (this one I think it would be the more complex but also very powerful). Allow for SQ X to develop multi sub-.strategy EAs and condensate all in a single EA/MQL4 file. My idea is the following:
a) imagine one develops 4 different EAs for 4 different market conditions (say for instance 4 volatility bins as resulting from ATR measurements).
b) In the end of the workflow the user selects the 4 strategies (one for each volatility bin) and SQX would then merge all of them in a single MQL4 file/ EA and, very important, with an embedded switching function between the 4 sub-strategies as market conditions would develop, to activate trading only for the EA that had been specifically developed for that market condition, in this case for that ATR range.
c) This of course would have the big advantage to allow one final Backtesting and demo testing without any extra manual work. It would empower the traders a lot!
Having full conscience that the team has enough on its plate, I hope this can be a future development of the tool!
I try to explain better: The idea is to develop strategies for specific periods (for instance ATR (14) less than X or, also, in IS+OS in specific time periods where you think it's worthwhile to optimize/test - be it beause of ATR or any other market condition). When you set ranking filters (for instance eliminate Ret/DD (IS) less than 5) SQ takes into account all the period you are considering for IS and OS. This has two problems:
1) it can eliminate good strategies that are good for the IS period you are interested in, because in the rest of the IS period the results don't pass in your ranking filter
2) is the strategy passes the ranking filter, then you have to do specific tests to see what is the result in the IS period you are really interested in (so that you can later on apply the filter in the code you mention). This is extra heavy work on top, because you can have two, three etc. different and separated IS periods with the conditions you want to consider. Each would have to be tested separetela before you could vet the strategy as valid to move forward. It's messy and not practical at all.
In theory what you say is true but hands on it's really difficult to implement in a realistic manner.
2. I think this is a good idea. A feasible way to achieve this is to allow if, else if, else conditions. That way you can say If (ATR(X period) > || < X value) { do X rules} else if (ATR(X period) > || < X value) { do Y rules } and so on. To make it fully modular, you would have to allow the if else conditions to also accept different indicator block conditions. i.e if (macd > 0) { do x } else if ( moving average rising) {do y}
3. This is very similar to a feature I outlined for adaptable fuzzy logic strategies here: https://roadmap.strategyquant.com/tasks/sq4_4041. Adding this both of these would be a great thing.
4. I think allowing for conditional logic will expand the type of strategies that can be created greatly. However, If this is done, I think it should be mandatory to have the option to only allow user-specified else if conditions. By default, SQ should be able to have the freedom to create/discover this logic on its own however, this would prevent achieving what you'd want to accomplish which is creating logic strictly based on ATR values in order to create different rules for different ATR conditions. So some additional feature would need to be added that only used if/else if/ rules specific to a user-specified block, in your case, ATR in order to create different trading rules based on volatility.