For code/output blocks: Use ``` (aka backtick or grave accent) in a single line before and after the block. See:

New behavior: Resampling on End of Session

  • administrators

    There is a commit in the development branch which works on getting the resampled bar pushed out at sessionend time if the timeframe is TimeFrame.Daily.

    This should not break any existing behavior.

    A sample using some recent intraday data.

    First without the new behavior

    Len,83,Dt,2017-01-05 21:50:00,Len0,83,Len1,0,Dt0,2017-01-05 21:50:00,Close0,3310.0,3311.0,3308.0,3309.0,Dt1,0001-01-01 00:00:00,Close1,nan
    Len,84,Dt,2017-01-05 22:00:00,Len0,84,Len1,0,Dt0,2017-01-05 22:00:00,Close0,3308.0,3310.0,3305.0,3307.0,Dt1,0001-01-01 00:00:00,Close1,nan
    Len,85,Dt,2017-01-05 22:00:00,Len0,84,Len1,1,Dt0,2017-01-05 22:00:00,Close0,3308.0,3310.0,3305.0,3307.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0
    Len,86,Dt,2017-01-06 08:10:00,Len0,85,Len1,1,Dt0,2017-01-06 08:10:00,Close0,3305.0,3305.0,3300.0,3302.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0

    The following happens:

    • At data point 83 the time is 21:50 for dt0 which is intraday 10-minutes and dt1 which is the resampled version to 1-day is not yet delivering any data.

    • At 84 dt0 reaches the end-of-session limit which is 22:00, but dt1 still doesn't deliver

    • At 85, dt0 has paused (its length remains at 84) giving a chance to dt1 to deliver the fully resampled bar.

    • From there on the story is repeated each day. This is ok for offline backtesting, because the backtrader engine pauses the minor timeframe, to keep it synchronized with the larger timeframe which has said it wants to deliver.

    • But: it can do so because it recognizes that at data point 86, dt0 will deliver a bar which has a timestamp already into the next day/session.

      Obviously when dealing with live data, the pausing happens: next day

    There seems to be a use case for people who want to do something right at the end of the session and hence the need for the resampled bar to be delivered as soon as possible.

    New behavior (not yet part of the main release)

    Len,83,Dt,2017-01-05 21:50:00,Len0,83,Len1,0,Dt0,2017-01-05 21:50:00,Close0,3310.0,3311.0,3308.0,3309.0,Dt1,0001-01-01 00:00:00,Close1,nan
    Len,84,Dt,2017-01-05 22:00:00,Len0,84,Len1,1,Dt0,2017-01-05 22:00:00,Close0,3308.0,3310.0,3305.0,3307.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0
    Len,85,Dt,2017-01-06 08:10:00,Len0,85,Len1,1,Dt0,2017-01-06 08:10:00,Close0,3305.0,3305.0,3300.0,3302.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0
    Len,86,Dt,2017-01-06 08:20:00,Len0,86,Len1,1,Dt0,2017-01-06 08:20:00,Close0,3302.0,3304.0,3301.0,3303.0,Dt1,2017-01-05 22:00:00,Close1,3298.0,3315.0,3290.0,3307.0

    And now:

    • At 84, both the 10-minutes and 1-day data feeds produce the bar for 22:00.

    • The length of the system (84) and that of the minor timeframe (84) remain synchronized because it's not being paused

    • At point 85, the minor timeframe has moved into the next day/session (08:10) whilst the only available resampled value from the previous day is still offered.

      Note: Should you need the larger timeframe to deliver the updated daily bar, you are then looking for the replaydata functionality in cerebro and not for resampledata

Log in to reply