Re: [amibroker] Re: TimeFrames: Is their use flawed?, AmiBroker Email List Archive

TimeFrames were conceived in the pre-computer age where they simplified calculations and displayed useful EOD charts. imo, That is what they were designed for and they work fine in that context. EOD data may have 'significant' higher TimeFrame boundaries, like weeks, months, years. I have never been able to find any such significance in Intraday periods like in 5, 10, 15, etc minutes. The reason seems obvious: traders around the world are all experiencing a different trading delay. This diffuses and delays market response to events. I have never been able to detect significant and well-defined TimeFrame boundaries in RealTime, i.e., times where action queues up and is released (like the EOD open and close of the market).

Traditional traders, and TA in general, are gradually and at a VERY slow pace, creeping up to scientific data acquisition methods. The reason is that successful traders are reluctant to change their ways. While I can understand that, it slows down progress. An exception would be where traders/institutions use scientific software to do their analysis.

imo, In RealTime trading it doesn't make sense to use a TimeFrame of 10 minutes, on 1-min charts, and randomly throw out 1-9 quotes. TimeFrames are referenced to the begin of the day, thus the last indicator value is subject to a variable delay. A one bar delay can kill a trading system. Backtesting and Optimizing with data where 90% (in a 10-min TF) of the TF indicator values are subject to a variable delay makes no sense to me.

Additionally, TimeFrame Indicators are discontinuous; most days show an abrupt discontinuity at the end of the day. TF-Indicators are distorted when the TimeFrame re-synchronizes itself at the start of the day. Good luck trading the Open with such indicators.

Some of the contributors have suggested ways to make TimeFrames 'more timely'. While I think this is progress in the right direction I am not convinced this is the optimum solution. Perhaps there is simply no need for TimeFrames in a RealTime environment? I think this may be another example where the TA community is reluctant to change ;-)

just my 2-cts worth :-)

herman

Tuesday, August 25, 2009, 9:14:37 AM, you wrote:

> Same here. FWIW, my take on this: the crucial difference is in terms of what

> expandFirst does in a chart vs a backtest. In general, if you use it in a

> backtest, it will "look into the future" and thus make any results useless. In

> a chart, for some of us, this is what you actually prefer, because the focus

> is on the latest "evolving" period (in whatever terms this is defined via TF),

> i.e. you want to use the most recent bar/tick as your last value for any

> TF-period, rather than wait for the official full fill of any of the TF-defined periods.

> At the end of the day, using formal or assumed last values, TF philosophy

> basically boils down to efficiently capturing convergence/divergence of multiple cycles.

> PS

> --- In amibroker@xxxxxxxxxps.com, "sidhartha70" <sidhartha70@...> wrote:

>> I'm not an expert on this, but I have been following this thread with some interest (because I day trade using multiple timeframes, and currently simply switch all my interval linked charts from one timeframe to another - I have a hunch there may be a better way of operating).

>> Anyway, if what you have written below is correct, if seems in complete conflict with what AF wrote on this post in reply to TJ,

>> http://finance.groups.yahoo.com/group/amibroker/message/141366

>> Perhaps the experts (Jorgen & AF - or indeed TJ) could clear this one up...?

>> --- In amibroker@xxxxxxxxxps.com, "gunoicb" <gunoicb@> wrote:

>> >

>> > Hi guys,

>> >

>> > I want to be sure that I understood correctly the use of higher timeframes in my backtesting, so here is my question:

>> >

>> > TimeFrameSet( -1);//I'm using for backtesting tick data

>> > //I compute below emas for each time frame

>> > TimeFrameSet( in1Minute);

>> > EMA5_1m= EMA (C,5);

>> > TimeFrameRestore();

>> > TimeFrameSet( in5Minute);

>> > EMA5_5m= EMA (C,5);

>> > TimeFrameRestore();

>> > TimeFrameSet( 15*60);

>> > EMA5_15m= EMA (C,5);

>> > TimeFrameRestore();

>> >

>> > The following will give me the values for each ema updated for each tick, tick by tick, not waiting for the candle to be completed (1min, 5 min or 15 min)?

>> > TimeFrameExpand( Ref(EMA5_1m,0),in1Minute)

>> > TimeFrameExpand( Ref(EMA5_5m,0),in5Minute)

>> > TimeFrameExpand( Ref(EMA5_15m,0),in15Minute)

>> > I mean, if I have 200 ticks during a 15 minute candle, I get 200 values for TimeFrameExpand( Ref(EMA5_15m,0),in15Minute)?

>> >

>> > while the following will give me the emas values based on complete previous candle (1min candle, 5 min candle and respectively 15 min candle)?

>> > TimeFrameExpand( Ref(EMA5_1m,-1),in1Minute)

>> > TimeFrameExpand( Ref(EMA5_5m,-1),in5Minute)

>> > TimeFrameExpand( Ref(EMA5_15m,-1),in15Minute)

>> >

>> > I'm using the same principle as Jorgen for backtesting, but I'm not sure that I'm using correctly. I don't want to use the higher emas as staircases, but rather as "irregular" as Jorgen pointed out that image loaded by him. I don't want to wait for 15 min candle to be completed, but rather to take a decision based on its value at each tick.

>> >

>> > Am I right? Or should I read again http://www.amibroker.com/guide/h_timeframe.html ? :-)

>> >

>> > Thank you

>> >

>> > --- In amibroker@xxxxxxxxxps.com, "af_1000000" <af_1000000@> wrote:

>> > >

>> > > I have not tried more complex indicators for one simple reason. If the higher timeframe compressed data contains all values I need (including incomplete last bar) I do not have to do anything . Build in indicators and my scripts will do everything for me. You calculate indicators on higher timeframe and expand them on a lower timeframe. If data compression on higher timeframe does not include everything you need you have to combine somehow data on higher timeframe with data on lower timeframe and invent new implementation of the indicators or create new intelligently combined weekly and data array, so build in indicators can use this array. That's why my preference is to fix data compression on the higher timeframe first before I start thinking about an exotic stuff.

>> > > So far, I have used multiple charts to avoid unnecessary programming.

>> > > I do not understand why you would use "expandFirst". Create two charts higher and lower timeframe in a layout and play bar by bar. I believe the code is correct. Of course, I did not test every possible case, that's why you found few mistakes. The main objective was to prove the concept and highlight the differences between "traditional" method and your method.

>> > > Sometimes loops are more efficient than array processing especially when you use lastvalue, nested barssince, nested valuewhen,.. etc. Every situation is unique, so it is hard to say in advance what is the best implementation. Always check "Code check $ Profile" and "Display chart timing".

>> > >

>> > > Regards,

>> > >

>> > > AF

>> > >

>> >

> ------------------------------------

> **** IMPORTANT PLEASE READ ****

> This group is for the discussion between users only.

> This is *NOT* technical support channel.

> TO GET TECHNICAL SUPPORT send an e-mail directly to

> SUPPORT {at} amibroker.com