I have a formula which is working OK on 1 minute chart:
But I am having difficulties making it work while using 5sec chart.
I still want trade to start on Open of 1 minute candle, but obviously it triggers on Open of 5 sec candle...
I understand that I should use different timeframe for this signal, but so far my attempt to solve this didn't work ^^'.
Luckily now we have a solution for both - backtesting and automated trading!
Being new to Amibroker it's still a bit unusual to me that backtester is using its own "logic" at times and is not following formula 100%. But it's pretty obvious that it is a necessity.
Pardon my ignorance, but if someone would work with different timeframes. For example, using a minute chart and triggering trades on hourly bars. Would it still be preferable to use a similar technique or will there be a need to use:
Thank you for your precious time spent enlightening us
TimeFrameSet can be used but there is no reason to do so. TimeFrame functions are costly and definitely NOT for such simple tasks.
Unless you want to calculate and mix indicators in different time frames there is no reason to use time frame functions. I don't know why but TimeFrame functions seem to be most abused functions (or used incorrectly, in incorrect places). This phenomenon continues to amaze me. I don't know why everyone seem to be jumping onto those functions when they should not be used in 99% of cases.
For hourly bars (trade only on beginning of the hour) you can detect starting hour same way, or using Minute() function
Buy = Buy AND Minute() == 0;
For minute bars (trading only on beginning of minute) you can also use
Buy = Buy AND Second() == 0;
instead of TimeNum. As for logic of backtest vs automated trading it is not different. It is pretty much the same. The only difference is for automated trading you are only interested in LAST VALUE of array, not entire array, because you want to place a trade NOW, not for all bars.
So for automated trading you can simply add
If( LastValue( Buy ) )
That is actually the only difference but it is obvious when you think about it. I modified previously posted code to better illustrate this.
Coming from a game dev background it was quite easy for me to realize that afl code executes constantly. Similar to Update() methods in C#, etc.
"Famous" AFL arrays also didn't take too long to become cautious about (I still sometimes get errors where an array is wrongly placed inside and if, but it's an easy fix ).
However when we take both, real-time execution, add arrays complexity and on top of that add different timeframes with compression and expansion, that's when my head starts to spin and brain refuses to tackle the challenge ^^'
That's when we rely on documentation, knowledge base and of course this forum. And most of the time answer will have etiher TimeFrameSet or TimeFrameGetPrice. Guess "lazy" brain just doesn't want to think of any other ways after that =)
I can't express how grateful I am to people here who support newcomers.
Thank you Tomasz and thank you guys.
Thanks for interesting feedback regarding your "first look" experience as a game dev. This kind of feedback is very valuable in making docs better.
Anecdotally, years ago, when there was no TimeFrame functions, people were just using ValueWhen function, which essentially can do pretty much the same as time frame functions with regards to accessing OHLC data from different time frame, like for example this:
// on minute bars assuming close at 16:00
DailyClose = ValueWhen( TimeNum() == 160000, Close );
... and as I wrote the only obstacle in the old days was calculating and mixing indicators in different time frames and that wasn't as simple as single ValueWhen call and that is why TimeFrame functions were added.