So here we have bug #396 and it is again one in the category Major. Took me only 1.5 day to find, after seeing that I am (this time virtually only) losing money. Mind you, there would be no way I had discovered this, if I first hadn’t had a reference of something working correctly. And again, am I the only one running into this ?
This will comprise of (at least) two posts. The first (this one) showing the correct situation. After that the wrong situation will be shown. I hope this works out because if something appears incorrect in an earlier post, I can’t change it.
1
2
3
4
5
6
7
8
9
10
11
12
13
IfNotOnMarketorStrategyProfit<>StrategyProfit[1]then// 31-03-2022,PS, Like this. Watch out : works better but is not waterproof to all resets ! 03-07-2022,PS, Commented out the 2nd part for Test.
The above tries tot show the severity of the impact. In other words, if that If fails, resets take place which shouldn’t (or do not take place when they should, but it is not about that).
1st : Shows the bar preceding the Exit.
2nd : Shows the bar at the Exit detection and it shows how StrategyProfit is not equal to StrategyProfit[1]. Thus reset is triggered.
3rd : Shows the first bar of the Not OnMarket situation.
If you’d follow the red line, you will see that preceding this all it is a straight line. No Resets take place while OnMarket. Beyond it, the red line follows the price, hence resets keep on taking place.
What is crucial to let this work correctly, is the chart at a TimeFrame of 1 minute, together with this line of code; mind that the code snippet above is under the scope of this TF command below :
1
timeframe(1minute,UpdateOnClose)
4th : Shows the chart setting.
(yes, I know that these labels and (here not visible) order arrows can be shut off, but these are exactly my references of something which works fine)
On a side note and FYI : That check for the changed StrategyProfit is necessary because the Not OnMarket is ambiguous when working with Limit orders. For people at ProRealTime : You may not know it, but there is no decent (or intuitive ?) way to find out “changed position”.
1st : Now I change the TF of the chart to 10 seconds. You can already see the red line now never being straight, while OnMarket it should be.
2nd : Bar before the Exit.
3rd : Bar at the Exit.
4th : 7 bars after the Exit. Notice the steps showing in the “updating” of the reset line, which is because only once in the 6 bars (6 x 10 seconds = 1 minute) the code of concern is executed.
In this case it is clear that StrategyProfit[1] (“Previous”) is not updated. It stays like this forever. Well almost. The next post will show that.
Thus, not sure (yet) what causes “Previous” to update once in a while, but 1st shows that where “Current” updates, “Previous” should do too. But that changes only 3 times.
2nd : Shows that out of the blue (in a Not OnMarket situation), “Previous” is updated. And as it now equals the “Current” (both lines are at equal level now). My hunch : some reset, looking at the time (Amsterdam time).
3rd : This does not confirm this, BUT this is an OnMarket situation (not shown, but trust me) and :
4th : Is again Not OnMarket and now at a similar reset (??) time.
I would stay out of anything working with a chart with lower timeframe than certain (which ???) code parts executed under a longer timeframe until it is confirmed that this is solved.
IfNotOnMarketorStrategyProfit<>StrategyProfit[1]then// 31-03-2022,PS, Like this. Watch out : works better but is not waterproof to all resets ! 03-07-2022,PS, Commented out the 2nd part for Test.
What is crucial to let this work correctly, is the chart at a TimeFrame of 1 minute, together with this line of code; mind that the code snippet above is under the scope of this TF command below :
1
timeframe(1minute,UpdateOnClose)
Thus that is already there, though in UpdateOnClose format. I don’t think it would matter, and the default TF from the chart is not used, except for where I want it, more below.
Anyway, a TF command before my line 1 is thus already there.
Of course I don’t want to be ignorant, so I wanted to try, but all got worse from it :
Today, whatever I try, I would not be able to create my original post again. All now works as intended. This in itself is worse, because how to know when – or when it does not work. Well, this adds to it :
Several times already (in this forum too) I mentioned that something is wrong with the timeframes based on seconds. The one from the example is “seconds” too, namely 10 seconds in the chart. If I today want to bring forward more than 3 days of backtesting, then I can’t go beyond June 29 (see attached). It does not matter how many units are in the chart, this is just it. And THIS worked the past weekend, and I never saw that before. I also never saw StrategyProfit not working as should which today is fine. So both seem related.
2nd attachment with 180K units (of still 10 seconds) no difference to be seen.
And out of all I just give *this* very bug to PRT Support last Friday (thus bugs me for many months), feeling ashamed because the past weekend I could not justify that, would I need to. It just all worked linearly. BUT that StrategyProfit issue.
I now feel that both are related.
The platform was restarted many times last weekend, so it can’t have been a glitch in “requires a restart”.
The issue I see again today is not related to TF commands, as I am having this issue prior to using TF commands. Also see 3rd attachment which is again from the 180K units of 10 seconds and where you can see that the data is just not (loaded) in the chart.
As a bonus, see the 4th attachment. This is from real history (1M bars of 10 seconds) and *that* works. This I told support too. And btw, that too shows the correct StrategyProfit (can be seen in the screenshot).
I see PRT Spport picked this up already, and I am afraid this is completely vague now.
Roberto, thank you for your help.
To help us continually offer you the best experience on ProRealCode, we use cookies. By clicking on "Continue" you are agreeing to our use of them. You can also check our "privacy policy" page for more information.Continue
.
