What I am going to write hereunder, is merely a reasoning of what could be going on, than that I can really prove things. That things are wrong is for sure.
In the attachment you see a small list of results a varying “BrokerFee”.
In the 2nd attachment you see that the BrokerFee is 16. It always is, no matter which of the result lines I select (from the 1st attachment). Non of the profit “Winst”) results is OK.
1
//BrokerFee = 19
This is the only assignement in de code. I can replace that with any of the numbers you see in the 1st attachment and the results will be fine.
The 16 the program comes up with (2nd attachment), is an old value I had in there as a fixed value in the Optimisation Variables list, from a previous version of this strategy (I created the current one this morning). Setting the BrokerFee value to a fixed value does not help a thing. Whatever it is set to (like 19 or 23 or 51 etc.), in the program it is still 16. However, when I engage the code :
1
BrokerFee=19
It readily works as should.
Now on to why I think something is fundamentally wrong. Two issues – first an only inconvenient one (but related) :
StopProfitFollowOrg=BrokerFee+BrokerFeeRange+10// 03-04-2021,PS. But 10 must be a variable.
endif
With no further assignment of this variable elsewhere, this does NOT error out. Well, might someone think it is convenient to let this go without error, then I tell you it is the opposite. This is no-way-of-working (enormously error prone) . Besides I can give you a 1000 examples of this erroring out for sure. But not in this case … (I know, I have seen people here attesting that an unassigned variable will have been initialised to zero).
Then the main one :
1
2
3
//BrokerFee = 19
//graph currencyfactor as "currencyfactor" // 1.02613
BrokerFee=Round((BrokerFee/CurrencyFactor),0)
The BrokerFee = commented-out 19 line, anticipates the Optimisation Variable of the same name. We know what PRT makes of this, right ? (possibly since recently) … Assumed the Optimisation list has a fixed 19 (the range I can not check), then this will be in there :
1
OnceBrokerFee=19
And this is wrong. The Once should not be there.
Look again at this line :
1
BrokerFee=Round((BrokerFee/CurrencyFactor),0)
and know that part of the construction in my strategy is determining the actual currency rate per trade. And not per bar. So mind you – and it is just an example – when I have something relative to the same variable, like in this case, a Once is not allowed. In such a situation the variable has to be initialised at each bar (per call of the program). And since this is an Fx strategy, the currency factor changes all the time and thus my BrokerFee would change all the time during the strategy and the call per the bars when On Market.
Not that I would not be able to solve this, but no human being would know this without, well, knowing it first.
Without further testing, it is my guess that something goes odd (or maybe not, but I cant’ sufficiently see-through) with the Once assignment(s) the program applies internally and which may not reset at a next iteration of the Optimisation. It will not be a coincidence that there are two different result sets (two different results for profit all together), which seems to be the first iteration (see bottom value in 1st attachment) and the others.
The program seems to choke on referring to such a variable which changes its value by means of its own value as a base (A = A + 1).
Last thing: I have ran into more unexplainable matters in this very same realm, but just solved it to satisfaction. This can be seen and done when you’re dealing with one varying variable because you see it happening, like here (nothing changes for Profit plus the debugging tells you after some examination of the Why). However, when you use two or more varying variables, you won’t see a thing because of too many results and the same profit values will not even be noticed. Still this particular one variable is choked and then also comes up with an old (ever back used) value ?? (the 16 in my case)
If I am not aware of a very common approach to such matters, then I hope someone can kindly let me know (I will post my own “general” solution to this, once I found an acceptable one).
Meanwhile we have been reading quite some more issues which most probably will originate from the same. So I hope this helps someone.
The solution can go like this (I see that I applied it that way more often) :
1
2
3
4
5
//BrokerFeeA = 19 // A-version required because of changing this variable with reference to itself..
BrokerFee=BrokerFeeA// 03-04-2021,PS, Because of a PRT bug.
//graph currencyfactor as "currencyfactor" // 1.02613
BrokerFee=Round((BrokerFee/CurrencyFactor),0)
So BrokerFeeA now is the varying variable (whether fixed or not, the issue is the same and the solution is also the same).
First thing we do is make the original BrokerFee equal to BrokerFeeA – next we can reference to it and change it (the last line above).
Since Jan 22, 2021 I have been working with this bug. Thousands of BackTests further (live too) and only then I notice it. Mweh. 😉
I have marked this topic as resolved, although I would not really agree with that. If only others know that this plays and how to deal with it …
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
.
