No! Spotware, do not hard implement sophisticated special versions of WFO like anchor, rolling, flying, diving, or whatever.
As I mentioned above, simply give the programmers via an API the chance to call one backtest or optimization cycle programmatically. Every programmer then can implement whatever WFO strategy he/she likes.
No! Spotware, do not hard implement sophisticated special versions of WFO like anchor, rolling, flying, diving, or whatever.
As I mentioned above, simply give the programmers via an API the chance to call one backtest or optimization cycle programmatically. Every programmer then can implement whatever WFO strategy he/she likes.
There is actual spread in bar information. The concept of spread makes sense only in the contect of tick data and bid and ask prices.
Best regards,
Panagiotis
Hi Panagiotis
I think your statement “There is actual spread in bar information” is wrong when we look at history .zbars file format. The current format of history .zbars files looks like this: - Opening time of the bar in milliseconds since 1.1.1970 - Opening BID price of the bar - Highest bid price during the bar - Lowest bid price during the bar - Closing bid price of the bar - Volume of trades during the bar
There is no information about the spread in .zbar files ! Instead when using bars and not ticks as the data rate for back testing and optimization, the spread must be a) set as a constant or b) is randomly generated as it can be seen here:
Because of this behavior, bars as data rates cannot be used for accurate back testing or optimization when accurate spreads are needed. Instead, the much slower tick data rates must be used if someone needs accurate spread behavior. Especially over midnight or rapid changing prices the spread can dramatically change.
A solution to this issue is very simple! Just add spread information to the .zbars files like this: - Opening time of the bar in milliseconds since 1.1.1970 - Opening BID price of the bar - Highest bid price during the bar - Lowest bid price during the bar - Closing bid price of the bar - Volume of trades during the bar
- Opening ASK price of the bar OR - Spread of the opening price (ask - bid)
and add a 3rd option to the selection window box above: “Take spread info from history file”
There is actual spread in bar information. The concept of spread makes sense only in the contect of tick data and bid and ask prices.
Best regards,
Panagiotis
Hi Panagiotis
I think your statement “There is actual spread in bar information” is wrong when we look at history .zbars file format. The current format of history .zbars files looks like this: - Opening time of the bar in milliseconds since 1.1.1970 - Opening BID price of the bar - Highest bid price during the bar - Lowest bid price during the bar - Closing bid price of the bar - Volume of trades during the bar
There is no information about the spread in .zbar files ! Instead when using bars and not ticks as the data rate for back testing and optimization, the spread must be a) set as a constant or b) is randomly generated as it can be seen here:
Because of this behavior, bars as data rates cannot be used for accurate back testing or optimization when accurate spreads are needed. Instead, the much slower tick data rates must be used if someone needs accurate spread behavior. Especially over midnight or rapid changing prices the spread can dramatically change.
A solution to this issue is very simple! Just add spread information to the .zbars files like this: To the already existing 6 entries per bar - Opening time of the bar in milliseconds since 1.1.1970 - Opening BID price of the bar - Highest bid price during the bar - Lowest bid price during the bar - Closing bid price of the bar - Volume of trades during the bar just add - Opening ASK price of the bar OR - Spread of the opening price (ask - bid)
and add a 3rd option to the selection window box above: “Take spread info from history file”. Of course because the format of the .zbars file have been changed, a complete reload of all .zbars files is necessary after the change.
same here. I rented a 96-Core machine to optimise an algorithm and here I have a usage of ⅓ of the cores. I am able to run 3 instances of CTrader with optimisation running, every instance tests 31 combinations…
Thanks for reporting this. Could you pleasesend us some troubleshooting information the next time this happens? Please paste a link to this discussion inside the text box before you submit it.
Quantrosoft
23 Aug 2024, 06:48
No! Spotware, do not hard implement sophisticated special versions of WFO like anchor, rolling, flying, diving, or whatever.
As I mentioned above, simply give the programmers via an API the chance to call one backtest or optimization cycle programmatically. Every programmer then can implement whatever WFO strategy he/she likes.
@Quantrosoft