Trades being executes in backtest but not in Live autotrading

Forums ProRealTime English forum ProOrder support Trades being executes in backtest but not in Live autotrading

Viewing 6 posts - 16 through 21 (of 21 total)
  • #230014

    Both systems were started at open (spot gold) on Sunday evening

    About what I noticed myself with PRT-IB (which might be different for PRT-IG !!) :

    There’s always an “unjustified” gap between (IIRC) 23:00 and 00:00 (Amsterdam). This is constructed such, that if I am not in at that moment, I always will be. So something happens there with pips or whatever, which I can’t explain. The thing is : that gap contains bar data, but no price movement. And your averages will choke on it** …

    **): This is almost for sure, although I did not test it explicitly.

    You can bet that this is backtest data related, or better : how PRT presents the bar/tick data to us (please remember, PRT-IG could treat this differently). So what I am saying is that in Live this won’t go wrong (brokers will have their act together), and it will by (my) guarantee so that what you see in the charts, will also be seen by the backtesting engine. With this, also keep in mind that the Live engine will not lie and it will deal with the live broker data.

    So try to locate these gaps, and run an (exponential) average over that hour. If you see 0, then you know what the problem is (how to interpret it, is something else). With this, incorporate the bar count. If this is 720 (# if times of 5 seconds in one hour), then what I just said applies. If the count is 0, the average of 0 will be correct (or can’t be calculated over 0 bars).

    ?

     

    2 users thanked author for this post.
    #230018

    Thanks Peter, I have experienced the issue with systems needing to run for a while before all teh calcs have the full data needed and to start triggering trades. That’s not the issue here though as two trades were triggered yesterday afternoon and this morning another was “missed”.  I’ve worked with spot gold for years too and never experienced the problem that is apparent here, so I don’t think it is anything specific to the instrument itself.

    Something interesting here though, I just wrote an update to IG Support and in the course of writing it, the “cut-off” between the two difference sets of results increased a bit further, the chart now requires approx. 78,000 bars to show all the trades. So the “cut-off” as I refer to it is moving with the chart as time progresses. Maybe this is a clue, could there be some inconsistency in the chart date at a point in time last week that is affecting results …. But only if the chart goes back far enough to include that data? . I have asked IG support the same question.

    1 user thanked author for this post.
    #230023

    So the “cut-off” as I refer to it is moving with the chart as time progresses.

    I assume that you refer to the chart being there for many hours (max 18 because then PRT quits). Is that correct ? In that case :

    Now consider that the chart indeed will contain more and more bars, because that is how it works. You may start out with 10000 5 second bars, but one hour later you’ll have 720 bars more (thus max for a trading day = 18 x 720 = 12960 bars more.
    Now it is up to you to reason out how this can influence (you know your code). But undoubtedly it does.

     

    I have experienced the issue with systems needing to run for a while before all teh calcs have the full data needed and to start triggering trades. That’s not the issue here though as two trades were triggered yesterday afternoon and this morning another was “missed”.

    Please reconsider this. This is what PreLoadBars is for. So if you had that wrong (like not explicitly targeting the situation, or JS’s 3x for EMA, of which I don’t know for which other functions it may be in order to more or lesser degree).

    On another side note again – the other day I sorted out how far back a calculation would go. This clearly shows what this “EMA” thing is about; this is a matter of graphing the result and you can see where it starts to graph (you should do that too). But this is not what my message is about; this is about the granularity of the working out of different time frames. So the one just works out more realistically than the other. Thus, an average over 6000 times one minute, sure is not the same as the same average now working per 100 times one hour. It should be, but for PRT is isn’t. N.b.: This is hard to explain, but think of an average you want to see over a day’s period which you can do with any timeframe, if it only matches that one day.
    Or what about the maximum number of periods which is not reported as an error when the threshold is crossed. It could mean that once your data contains so much that it will work over more bars than the function can cope with, it suddenly goes wrong without you noticing it. Here too, Backtest will work out differently than Live. Example from the top of my head : HMA which won’t do more than ~35000 periods. Beyond that the result is 0.

    So many pitfalls …
    And “seconds” Systems incur for all sorts of issues because of limits reached earlier (my Fx systems are 3 secs).

     

    #230028

    Batty wrote: So the “cut-off” as I refer to it is moving with the chart as time progresses.

    No. My terminology there might have confused the issue. What I am saying is: yesterday when I wrote my first notes on this point, with Sys1, if the chart contained 65,500 units / bars it returned one set of trades and if it contained 67,000 it returned more / different trades. And this corresponds with the difference I have been seeing this week between charted backtest trades and Live trades. When I did the same on Sys2 shortly after, the same thing happened but the point at which the different trades were evident was slightly higher , somewhere between 67,000 units and 68,000 units.  This morning, when I did exactly the same with Sys1 again, the point at which the different trades was evident was had moved quite a bit higher, to between 75,000 and 76,000 units / bars.
    So, yesteday evening  the difference was apparent at approx 65,000 units, and when I did the same a short while ago the difference was apparent at approx 75,000 units. That is 10,000 x 5 second units which equates to 13.8 hours …. roughly the actual time difference between when I ran this test yesterday and when I ran it this morning.  The point at which the difference appears seems to be moving along the chart, seemingly in line with  catual time. So it seems the anomoly that is causing this appears to be at a fixed point in time which moves continually onward as the back test chart progresses. So, if it was apparent yesterday at just 65,000 units, today it would need more units to be shown in the chart in order for the anomoly to affect the data in the chart. This is the root if my question above, I hope that makes sense.

    Please reconsider this. This is what PreLoadBars is for. So if you had that wrong (like not explicitly targeting the situation, or JS’s 3x for EMA, of which I don’t know for which other functions it may be in order to more or lesser degree).

    Thanks for your further comments here. I really don’t think this is a preloaded bar issue. In terms of timeframes and the base calculations used, the systems in question are identical to other systems I have been previously running for months without any such issues.

    #230035

    … and now PRT opened a trade, which was correct according to the backtesting, and closed it (also correct according to BT), and opened the trade as it should have in both my IG accounts, but only closed it in one of my IG accounts, so the automated system closed it but this was not executed into IG …. it seems the problems are mounting so I have stopped my Live systems running until this is properly cleared up.

    #230036

    this last point, the trade staying open in IG was a red herring …. I logged out of the platform and logged in again and it was in fact closed. Shouldn’t have to do that but it’s not related to the issue under discussion in this thread 🙂

Viewing 6 posts - 16 through 21 (of 21 total)

Create your free account now and post your request to benefit from the help of the community
Register or Login