Pro order different from probacktest
- This topic has 41 replies, 5 voices, and was last updated 3 years ago by
.
-
I’m sure PeterSt will have some more to say,
Well, he’s intrigued.
At least this Strategy is independent of the “sequence” I mentioned (scalping works too “strict” for it to deviate at the 3 minute interval).First off : a deep hats off to GraHal who has been “able” to find the differentiation by means of using those separate buttons. Without that, no dice ! (and only the winning strategy).
Next, of course an apology to Jos because all I said is not in order / applicable.Then :
When using the button for Preparing the Strategy for AutoTrading, we receive the message in the 2nd attachment, and it tells us to replace the Optimisation Variables with direct assignments in the code. And well, I can’t be 100% sure yet, but it seems to go wrong there. Regarding this, the message should not be there in the first place, that is, not that I know of because PRT will replace them with ONCE assignment in “my” normal situation. So what I am saying is that what you see in the 3rd attachment is a perfectly normal situation to exist, even meant to fill (change) the parameters to the Strategy at handing the Strategy to the AutoTrading system. Thus, I could change LotSize to 15 when I hand it to Autotrading. PRT will make this of it in the top of the code :
1ONCE LotSize = 10or when I changed it to 15 :
1ONCE LotSize = 15All the parameters to the Strategy (yes, it’s “parameters” now) are set like this with ONCE statements. And it is here where something will go bananas, already because this message (2nd attachment) appears. Jos will be doing similar (though possibly (??) not with ONCE statements but normal assignments (LotSize = 10)) and now the Strategy won’t work because the virtual ONCE’s will not be there and a variable may accumulate instead of starting at its initial value at each call when the 3 minute bar is closed.
(hey, this is ad-hoc reasoning 😉 )Because that message should not appear anyway, I think the intelligence of the PRT AutoTrading engine can see in advance that something is ambiguous. This can easily be because of the TimeFrame commands (it is not that, see more below). Regarding this, also notice that the ONCE assignments will (and can only) be inserted at the top of the code, while you might need some to be under an other TimeFrame (like under line 14).
For better understanding of my reasoning, please notice that with normal BackTesting, the ONCE statements will be be there just the same, but we can never see that. When Prepared (for AutoTrading) we can by clicking the link in the window with our Strategies. In this particular case it won’t come that far because the message orders us to inject those statements ourselves. Maybe one, maybe two, maybe all.
Jos, or anyone, I suspect that if you’d insert those statements yourself, there will be a difference between ONCE and the normal assignments. And if PRT would kindly provide a copy-paste facility from the Optimisation Variables, then I would be very happy with it anyway, but I would also have done it myself (no lust to copy them by means of typing and making typo’s, at this time). And Jos, you will already have done that, so you may want to paste them in a next post (or I do it myself anyway because I am too eager for the result).
A year or so back I have created a topic somewhere named “Something is fundamentally wrong with Optimisation Variables” (or something of that order). This is about (for example)
1LotSize = LotSize + 1Giving unpredictable results in the variable itself. Thus, internally this will be
12ONCE LotSize = 10LotSize = LotSize + 1And the system can’t cope with that. However, when *you* insert it like you see right above here, it will be fine.
Lastly … I got the hunch of commenting-out the TimeFrate statements. And wonder oh wonder, the result is exactly the same for both (GraHal’s) buttons. This was not to be expected at least for the winning situation. No change ?? Does Jos recognise that this can be ? (I didn’t look into the functional code itself at all).
1 user thanked author for this post.
Possiblly it comes down to what I wrote over here.
I am as far as the normal BackTest now giving the same results as the one with the “other” button (not the Editor’s one), BUT see below. When I add a dummy Optimsation Variable (all others are now defined in code) I can still see the normal gain of 9450 popping up.
In the 3rd attachment you see me varying LotSize, which behaves as expected. But when clicking any of the result lines, the results are nicely linearly negative again.
It is that I did not have any time for backtesting the past week, or else I would have done something with my own topic (see given link) because it is not workable any more. So this weekend seems to be lost now …
Thus :
- The negative results can also be incurred for by backtesting (just stuff in the code all the Optimasation Variables, with or without ONCE);
- When #1 has been applied, I see no way to let it behave “normal” with actually no clue of what normal would be.
More dangerous : I wondered why nobody mentioned that error message (obtain variables in code etc.), but I just found that despite the message the code is accepted for the AuoTrading ?!? (see inordinate 4:22 times).
Also see next post …
1 user thanked author for this post.
*if* we could only find the cause.
There are loads of ‘zero bars‘ prodiced by this Algo … enter, make profit and exit all on 1 bar. These zero bars do not show as positions under the equity curve.
The Algo uses … set stop ptrailing sl //Line 82 … with sl = 7 . I think this may be partly responsible for some of the weirdness with this Algo??
PS / EDIT
Above is why I mentioned (in a previus post) that it seems like tick by tick disabled – but acting in reverse – gives us all the losing trades and equity curve all below zero.
Tick by tick disabled but acting in reverse, meaning … PRT is counting every trade as if it loses every time if a zero bar. (instead of gaining ever time, which is the normal action for zero bars with tick by tick disabled).
Hope above makes sense. just say if it doesn’t? Another lively Saturday morning this is truning into! 🙂
1 user thanked author for this post.
The Algo uses … set stop ptrailing sl //Line 82 … with sl = 7 . I think this may be partly responsible for some of the weirdness with this Algo??
Haha, I came back to exactly report that.
1Once TrailingStopSize = 0 // 7So change that to 0 and all is fine.
And may I recall my again other written issue (somewhere the past weeks, related to MikeBoorman, but nobody could understand it) that there’s something fishy with the Pending Stop stuff ?
Mind you, eliminating the Pending Stop per
1Once TrailingStopEnable = 0does not help (it works out too differently).
So, salvation is near !
🙂PS: But I would not prefer this version, so now it requires something else for the Pending Stop. –> My (elsewhere proposed) Limit again …
1 user thanked author for this post.
Find exclusive trading pro-tools on 
