Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust lower-resolution fill-forwarded strict end-timed daily bars #8412

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

jhonabreul
Copy link
Collaborator

@jhonabreul jhonabreul commented Nov 15, 2024

Description

Adjusting lower-resolution fill-forwarded daily bars when strict end time is enable, which allows to get fill-forwarded bars with unchanged time stamps. In regular cases, like and hourly subscription or a daily subscription (without strict end times) and a minute fill forward resolution, the "intra-resolution" fill-forwarded bar times are rounded down to the actual subscription resolution.

So for instance, for an hourly resolution subscription, 59 bars will be emitted between two consecutive hours, but the start and end times are always the same, which is the start and end hour of the given range. Same happens for a daily resolution. Sor daily resolution with strict end times, this was not respected, so whithin a day, the fill forwared second, minute or hour resolution fill-forwared bars would have times increasing in the given resolution.

With this changes, the "intra-resolution" fill-forwarded bars times are respected regardless of the resolution and whether or not stritct end timing is enabled.

Algorithm.CSharp/BasicTemplateFuturesWithExtendedMarketDailyAlgorithm.cs data point count reduction:

This fixes a bug in master, were a Sunday followed by a closed Monday (holiday) would cause a bar for Sunday to be emitted, when for extended market hours FF daily bars are never emitted. These changes make sure those bars are not emitted in this case.

Test data changes:
FillForwardBars.Zip

FillForwardBars.Zip#ff_Daily_Minute.txt

image

Fill forward daily bars now have the same time/end times as the actual bar being fill forwarded, keeping resolution. In master this is different, since the fill forwarded bars resolution was the lowest subscribed resolution (minute in this case).

So if data has a bar for 2024/11/25 9:30am-4pm and the next bar is for 2024/11/25 9:30am-4pm, the fill-forwarded bars for 2024/11/26 will all have the same time stamps (2024/11/25 9:30am-4pm) until market close, where a new FF bar will be emitted for 2024/11/26 9:30am-4pm, which will be FF until 2024/11/27 4pm.

The same applies for FillForwardStrictEndTimeMinuteRegressionAlgorithm.zip and FillForwardStrictEndTimeHourRegressionAlgorithm.zip:
image

Related Issue

Closes #8392

Motivation and Context

Requires Documentation Change

How Has This Been Tested?

Regression algorithm and existing algorithms

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • Refactor (non-breaking change which improves implementation)
  • Performance (non-breaking change which improves performance. Please add associated performance test and results)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Non-functional change (xml comments/documentation/etc)

Checklist:

  • My code follows the code style of this project.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

@jhonabreul jhonabreul force-pushed the bug-8392-fill-forwarded-data-in-consolidators branch from 99f4920 to 7e3ff28 Compare November 27, 2024 20:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IdentityDataConsolidator Does Not Handle Fill Forward Correctly
1 participant