Resampled dataframes are shifted 1 candle.

[S3b4Bus0]

Hello, I have a problem just like this bug #60. The resampled dataframes are shifted 1 candle.

Example

dataframe_1h = resample_to_interval(dataframe, 60)
dataframe_1h['TEMA9_1H'] = ta.TEMA(dataframe_1h, timeperiod=9, price='close')
dataframe = resampled_merge(dataframe, dataframe_1h, fill_na=True)

FREQTRADE - BTC/USDT(BINANCE)
----------------------------TEMA9_1H
2022-06-01 00:00 - 31,794
2022-06-01 01:00 - 31,857
2022-06-01 02:00 - 31,892
2022-06-01 03:00 - 31,855
2022-06-01 04:00 - 31,743

TRADINGVIEW - BTC/USDT(BINANCE)
----------------------------TEMA9_1H
2022-06-01 00:00 - 31,857
2022-06-01 01:00 - 31,892
2022-06-01 02:00 - 31,855
2022-06-01 03:00 - 31,743
2022-06-01 04:00 - 31,642

in these images you can see the shift to the right of the indicator in the top image

What am I doing wrong?

[S3b4Bus0]

I answer myself...

maybe I still don't understand what is explained in:
freqtrade/freqtrade#4073

but I consider that this way it works correctly because I haven't got delay in the indicators.

please let me know if it is necessary to create a PR.

[xmatthias]

it's pretty dangerous to compare screenshots with screenshots of tradingview without further information.
Tradingview is known to easily allow repainting - (using candle close values before the candle is actually closed - causing the signal to fluctuate) - which is a great way to bump backtest results - but won't work in live.

The change you did above will cause the same exact problem - which will mean that maybe your backtesting results will look great - but the bot will most likely never trade in live.

---

assuming a 15m / 1h timeframes (for simplicity) - as in freqtrade/freqtrade#4073:

The main point here is to consider that all candle dates are candle open dates.
So a candle 1h candle from 22:00 will go from 22:00-23:00 - and the same 22:00 candle goes from 22:00-22:15.

The candle 22:45/15m is closed / available at 23:00 - the same goes for the 22:00/1h candle (which also closes at 23:00).

The "modified" date (resample_{resampled_int}_date_merge) does account for that - while resample_{resampled_int}_date does not.
Freqtrade will not care which way you do it for backtesting - so your results may look great, as you're looking into the future.

---

with your "fix": you use data available not before 23:00 (the 1h close) at 22:00.
basically, you use the close value from the candle at 22:45-23:00 at 22:00.

Given, it's a pretty complicated topic, but one we spent several days thinking about (several times, too).

I can be profitable 100% of the time if i know in the morning how today's daily candle will close. Your change would facilitate this - but for live - such a thing will not be possible.

[S3b4Bus0]

Thank you xmatthias for taking the time to answer my question. Now I can understand the purpose of freqtrade/freqtrade#4073

I agree that it is a complicated issue. However, I think it is not useful for 100% of the cases. I want to use it as a protection and not to determine the entry to a trade. So the displacement in a timeframe of 4H or more is a long time of delay.

What is your opinion of this change?

[xmatthias]

Also for protections you'll have the same issue (repainting) - so the moment you use ANY other value than open (also through an indicator) - you'll think backtesting works great - but it doesn't work well on live. If you use it as signal or protection does not change the matter.

The function will not be changed to allow looking into the future.
You're obviously free to use a plain "merge" in your strategy (noone forces you to use this method to merge the dataframe back), and no one will prevent you from implementing fake backtest results.

As a library / framework, we'll however try hard to protect people from accidentally doing this - therefore we'll try to design as much as possible to protect from this.

This also includes no option to "enable backtest cheating" - which this option would effectively be.