It would be useful if we can add the option to fire a signal (using the Gainium indicators) from the current candle and not from the closing candle.
For example if we set an indicator on the 1h timeframe to fire a signal to start a new deal we need to wait at least 1h before getting the signal (close candle) - instead the above suggestion takes into account the previous candle and will fire the signal immediately IF that condition on the current 1h timeframe is already true (current candle).
Practically this way any indicator could be used as a filter enabling endless possibilities.
If an option were implemented to fire signals from the current (unclosed) candle using Gainium indicators, it could definitely offer quicker entry/exit opportunities and open up new possibilities for real-time filtering.
One way this could be more robustly implemented and even backtestable, especially when considering the limitations of historical data for intra-bar movements, would be to use lower timeframe data (e.g., 1-minute bars) to calculate the developing state of the higher timeframe indicator (e.g., 1-hour RSI). This allows the system to trigger early based on more refined data
However, it’s important for users to be aware of key differences even with this approach:
Potential for “Whipsaws”: A condition might briefly appear true on the developing higher-timeframe candle, trigger a signal, but then reverse before the candle fully closes. This could lead to premature entries or exits.
“Repainting”: Even when using lower timeframe data, the final value of the higher-timeframe indicator might still differ from its earlier, developing value.
Increased False Positives: You might encounter more signals that don’t ultimately lead to a sustained move in the intended direction.
Backtesting Limitations (if not using LTF data): If this “current candle” trigger isn’t based on underlying lower-timeframe data, the detailed, real-time “interbar” price action is generally not available in standard historical candle data. This means strategies based purely on an unconfirmed single bar snapshot would not be reliably backtestable.
So, while firing signals from the current candle (especially when informed by lower timeframe data) offers speed, it requires a very cautious approach, higher risk tolerance, and a keen eye on real-time price action to manage these unconfirmed signals effectively. It’s a trade-off between getting in earlier and having a more confirmed signal, with important considerations for testing!
Closed 1-Hour Candles: For all past, closed 1-hour candles, Gainium would calculate the RSI (or any other indicator) exactly as it normally would, based on the Open, High, Low, Close of those completed 1-hour bars.
The Current 1-Hour Candle (Interbar Data): This is where the 1-minute data comes in.
As a new 1-hour candle begins, Gainium starts collecting the Open, High, Low, Close of each successive 1-minute candle that forms within that 1-hour period.
It then continuously (or at defined intervals, e.g., every minute) synthesizes a “virtual” or “developing” 1-hour candle using this accumulated 1-minute data. For example, the “Open” of the virtual 1-hour candle is the Open of the very first 1-minute bar in that hour. The “Current Close” of the virtual 1-hour candle is the Close of the most recent 1-minute bar. The “High” is the highest High among all 1-minute bars so far, and “Low” is the lowest Low.
The 1-hour RSI is then calculated using the actual Close prices of the preceding closed 1-hour candles and the Current Close (or other appropriate price point, depending on the RSI calculation’s exact formula) of the developing virtual 1-hour candle.
If the RSI condition (e.g., “RSI crosses above 30”) is met based on this developing virtual 1-hour candle, the signal fires immediately, without waiting for the actual 1-hour candle to officially close.
Example:
10:00 AM UTC: A new 1-hour candle (10:00 - 11:00) begins.
10:15 AM UTC: After 15 minutes (15 x 1-minute bars), the accumulated 1-minute data, when used to calculate the 1-hour RSI, shows that the “virtual” 1-hour RSI has crossed above 30. A signal fires.
10:59 AM UTC: The 1-hour RSI is still above 30.
11:00 AM UTC: The 1-hour candle closes. The final calculated 1-hour RSI (using its official close) confirms the cross, or it might have reversed. The initial signal, however, fired at 10:15.
2. During Backtesting:
Historical 1-Hour Data (for completed candles): The backtesting engine processes all past, closed 1-hour candles just as it would in live trading to calculate the indicator.
Simulating the Current 1-Hour Candle (Interbar Data): This is where the crucial part for backtestability comes in:
For each historical 1-hour candle being processed, the backtesting engine will then load (or access) the corresponding 1-minute historical data for that exact 1-hour period.
It will then iteratively “replay” that 1-hour period minute-by-minute (or whatever the chosen lower timeframe is).
For each 1-minute step, it will perform the same “virtual 1-hour candle” synthesis and indicator calculation described in the live trading section.
If the RSI condition is met at any point during this minute-by-minute simulation of the 1-hour candle’s formation, a backtest signal is generated at that precise historical 1-minute timestamp.
Example:
Backtesting a 1-hour period from 10:00 - 11:00 on a historical date.
The engine first uses the closed 1-hour candles before 10:00.
Then, it starts processing the 10:00 - 11:00 1-hour period by looking at the historical 1-minute
bars for that hour.
It processes the 10:00 1-minute bar, then 10:01, then 10:02…
At 10:15 (after processing the 10:15 1-minute bar), it recalculates the “developing” 1-hour RSI based on the 10:00-10:15 1-minute data. If the condition is met, a signal is recorded at 10:15 in the backtest results.
It continues until 11:00, then moves to the next 1-hour period.
Key Takeaway for Backtestability
The ability to backtest this strategy hinges entirely on having historical data available for the lower timeframe (e.g., 1-minute) that corresponds to all the higher timeframe periods we want to test. Without that granular historical data, we cannot accurately simulate how the “developing” higher timeframe indicator would have behaved.
What it does: For every new 1-minute candle, it performs one RSI calculation using the last N (e.g., 14) 1-minute candle closes.
Resources per hour: It performs 60 RSI calculations (one for each 1-minute bar in the hour).
Scenario B: Calculating a 1-Hour RSI Indicator with 1-Minute Interbar Triggering
What it does:
For past 1-hour candles: It performs RSI calculations based on closed 1-hour data. This only happens once per hour (when a 1-hour candle closes), but needs Nprevious 1-hour closes.
For the current, developing 1-hour candle: For every new 1-minute candle, it performs an RSI calculation. This calculation uses N-1closed 1-hour candle closesand the current developing 1-hour candle’s close (which is derived from the latest 1-minute data).
Resources per hour:
It also performs 60 RSI calculations (one for each 1-minute bar within the hour) for the current developing 1-hour candle.
Additionally, when each 1-hour candle actually closes, there might be a final, “official” calculation using the confirmed 1-hour close.
Conclusion
It would require a very similar amount of real-time calculation resources during active market hours with only a subtle differences:
Calculation Frequency: Both approaches are driven by the 1-minute bar updates. If the 1-hour interbar calculation is done on every new 1-minute bar, then both scenarios are performing an RSI calculation approximately once per minute. So, in terms of number of calculations per unit of time, they are very similar.
Data Required for Calculation:
1-Min RSI: Needs the last N 1-min closes.
1-Hour RSI (Interbar): Needs the last N-11-hour closes and the current stream of 1-min closes to build the developing 1-hour bar’s “current close.”
The type and amount of historical data you need to keep in memory might be slightly different. For the 1-hour interbar, you need to retain the history of both N 1-hour bars and the ongoing 1-minute data for the current bar.
Logic Overhead:
1-Min RSI: Simpler. Just takes the N most recent 1-min closes.
1-Hour RSI (Interbar): Slightly more complex logic because it has to:
Recognize when a new 1-hour period starts.
Keep track of the Open, High, Low for the developing 1-hour bar from the 1-minute data.
Combine N-1high-timeframe values with 1 synthesized developing high-timeframe value.
In practical terms:
The new version of our indicator with additional interbar evaluation for the open higher timeframe candle would be evaluated on the chosen lower timeframe and combine historical data of the higher timeframe with the data of the last closed candle of the lower timeframe.
For a single indicator, the difference in CPU or memory usage between calculating a pure 1-minute RSI and calculating a 1-hour RSI with 1-minute interbar updates would likely be negligible. The slightly more complex logic and data handling for the interbar approach are very minor.
The primary resource consumption comes from the frequency of calculation, which is similar (driven by the 1-minute updates in both cases).