Algo with hidden files stops in automatic trading
- This topic has 16 replies, 5 voices, and was last updated 1 year ago by
.
-
Hello Lucas. You mentioned MTF in your description. Do you have MTF code in the CALLed indicators? If so, that is most likely the cause. ProOrder doesn’t like MTF code in subroutines, but doesn’t necessarily give an error message when validating your code. But it gives erroneous behaviour in runtime. To me this is a serious bug. It has been signaled multiple times in the past. But we fall in this trap again and again. Now you know why your integrated version (all logic in one file) works well, all MTF code is in the main program, no longer CALLed.
What worked for me was putting the MTF code in the main program, pass the obtained basic values with the CALL statement, and execute the further secret calculations with these basic values in the called indicators. Hope this helps.
1 user thanked author for this post.
logic in one file with the same position size and this one is still working
You are close to finding the cause of the problem … try hiding 1 snippet of code at a time to see which snippet is causing the problem?
You could then post that snippet only on here to ask for help.
“Also be worth trying PRT direct with PRT”?
PRT provide the PRT Platform directly to users via the links below.
Thank you for the information!
Good idea about the snippets! I am now running multiple versions with different snippets hidden on my demo account and will see which ones will stop after a day and which ones keep working!Hello Lucas. You mentioned MTF in your description. Do you have MTF code in the CALLed indicators? If so, that is most likely the cause. ProOrder doesn’t like MTF code in subroutines, but doesn’t necessarily give an error message when validating your code. But it gives erroneous behaviour in runtime. To me this is a serious bug. It has been signaled multiple times in the past. But we fall in this trap again and again. Now you know why your integrated version (all logic in one file) works well, all MTF code is in the main program, no longer CALLed.
What worked for me was putting the MTF code in the main program, pass the obtained basic values with the CALL statement, and execute the further secret calculations with these basic values in the called indicators. Hope this helps.
I only have the MTF in the main code so this would not be the problem.
I have a 5 min TF in the main code which calls the strategy indicator and I have a 1 min TF in de main code which calls the stoploss indicator.1 user thanked author for this post.
When reimporting and starting it again it will work again for 1/2 days and then again it does not generate signals anymore.
Are you re-optimising after import after no trades?
Why import? Why not just restart if the Algo stopped or just leave it running as a test … a trade may pop up a few days later??
Maybe you are only getting trades for 1 or 2 days due to over optimisation so after 1 or 2 days the conditions are not being met as often?
Just more thoughts / ideas! 🙂
Thank you for thinking with me!
I also have the algo running without hiding it in indicators and that one does do trades, they use exactly the same parameters and the backtest shows the same results. Also when I run a backtest with the hidden algo over the period with no trades it shows there should be trades. However live it does not perform these trades.
I just re-imported the same code and started it again to check it because the code was working at first. For some odd reason this makes that it will work again for 1/2 days. I did not re-optimise the code, I just put the same code live again.However I do think I found something. I have deployed multiple versions of this algo with different parts hidden and when I un-hid the stoploss part the backtest was running way faster. Before when running the backtest it took a really long time to run a backtest for a period of a few days. When the stoploss part is not externalised in an indicator it runs at normal speed. So I am suspecting this could have something to do with it. I am running these on my demo account and will look if this keeps doing trades.
1 user thanked author for this post.
“I only have the MTF in the main code so this would not be the problem.
I have a 5 min TF in the main code which calls the strategy indicator and I have a 1 min TF in de main code which calls the stoploss indicator.”
So your CALLs are in different TimeZones (meaning TimeFrames ). I wouldn’t be surprised everything working correctly if you place all CALLs in the timeframe of the chart (which should be the smallest timeframe of all used in your code). But up to you to decide if this is feasible.I am not so sure that the mere fact that a Backtest is slow, when using CALLs, indicates something might be wrong in your called indicator. There are numerous examples of strategies that perform well in backtest in integrated format (minutes), perform not at all in backtest with CALLs (7 hours!) and perform without a glitch for years with CALLs live (ProOrder). The way the CALL is implemented in ProBacktest by the PRT developers is just . . . less than perfect. Another CPU consuming command is SUMMATION. You don’t need CALLs to slowdown a backtest if yo use multiples of those.
1 user thanked author for this post.
I have also tried to boost it by making the code more efficient. I came across “DEFPARAM CalculateOnLastBars = 200” would this help with the indicators?
As far as I have explicitly determined (tested), it will not matter for the result. This should mean it does not matter for speed anywhere. However, it will matter at bringing up the Indicator graphically. Thus, it matters (vastly) at when you changed something to the Indicator code and “save” it (so the saved situation is going to show in the Chart(s)).
I know, it looks/feels “wrong” to state that CalculateOnLastBars calculates everything after all. But notice that this can be tested with Backtesting only, and this may do the calculations ad-hoc per bar. So at each bar it will cause 200 bars preceding the then current bar to have been calculated. Also when that bar occurs 4 months ago. All what you need to take care of is that 200 bars is sufficient for your math (like Averages).This is all empirically found. So it is not that I read it somewhere. Thus if someone has a page with text about it … feel free to present it …
Please notice that this was tested with V11.1, 10-12 months ago.
1 user thanked author for this post.
Find exclusive trading pro-tools on 
