Skip to content

fix(ClusterSearch): keep realtime results consistent with a full bar recalculation - #180

Open
AlbertoAmadorBelchistim wants to merge 1 commit into
AtasPlatform:Developfrom
AlbertoAmadorBelchistim:fix/ClusterSearch-realtime-consistency
Open

AlbertoAmadorBelchistim wants to merge 1 commit into
AtasPlatform:Developfrom
AlbertoAmadorBelchistim:fix/ClusterSearch-realtime-consistency

Conversation

@AlbertoAmadorBelchistim

Copy link
Copy Markdown
Contributor

ClusterSearch: keep realtime results consistent with a full bar recalculation

Problem

In realtime, OnNewTrades only re-evaluates the price windows that contain the new trades. With some settings, a window's result depends on other data as well, so the forming bar shows different clusters than a recalculation of the same bar. The difference disappears when the bar closes (OnCalculate recalculates the closed bar in full), but until then clusters are missing or stale and alerts fire late or not at all.

Affected cases:

  • MinPercent / MaxPercent: each level's percentage depends on the bar's total volume. Trades at level B change the percentage of level A, but A is not re-evaluated.
    Example: MinPercent = 10, total 1000, level A = 120 (12%) is shown. After 300 more contracts at another level the total is 1300 and A is at 9.2%, but it stays on the chart until the bar closes.
  • OnlyOneSelectionPerBar: when the selected level stops passing the filters, or another level becomes larger, the selection is not moved to the next best level.
  • Body and wick locations: the ranges depend on Open/Close, which can move without a new High or Low. Levels that move from the body to a wick (or back) are not updated.
  • PriceRange > 1: the incremental loop stops at High - (PriceRange - 1), while the full calculation evaluates window starts up to the top of the price ranges (the High for location Any). Windows starting near the High are not updated live.

Changes

  • RequiresFullBarUpdateOnNewTrades() now also returns true when MinPercent/MaxPercent is set, when OnlyOneSelectionPerBar is enabled, and for the Body / UpperWick / LowerWick / AtUpperLowerWick locations. These cases use the existing full-bar update, the same path already used for MaxVolume and the exact-zero Ask/Bid search.
  • The incremental loop in OnNewTrades uses the same upper bound as the price ranges of the full calculation.

No behaviour changes for historical bars or for settings not listed above; those keep the incremental path.

Testing

Built against the current Alpha and ATAS X Alpha SDKs.

Manual check on a live chart:

  1. Add Cluster Search with PriceRange = 3, location Body, MinPercent = 5 and OnlyOneSelectionPerBar enabled.
  2. Note the clusters of the forming bar, then force a recalculation (change any setting and revert it).
  3. The clusters before and after the recalculation are the same. Before this change they differed in the cases above.
  4. Repeat with location Any and check the windows near the High of the forming bar.

…recalculation

The incremental OnNewTrades path only re-evaluates the windows that contain the
new trades. Several settings make a window's result depend on other data, so the
forming bar showed different clusters than a recalculation until the bar closed:

- MinPercent/MaxPercent: every level's percentage changes with the bar's total volume.
- OnlyOneSelectionPerBar: when the selected level stops passing the filters, or
  another level becomes larger, the selection has to move to another level.
- Body and wick locations: the ranges depend on Open/Close, which move without a
  new High or Low.

These cases now use the existing full-bar update. In addition, the incremental loop
used High - (PriceRange - 1) as its upper bound while the full calculation evaluates
window starts up to the top of the price ranges (the High for location Any), so
windows starting near the High were not updated live. The loop now uses the same
upper bound as the ranges.
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.

1 participant