Originally Posted By: jcl
In lite-C, TimeFrame is a simple variable, not an extra argument to all functions. For a daily ATR(60) just write:

ATR(60 * 1440/Barperiod)

or

TimeFrame = 1440/Barperiod;
ATR(60);

No extra functions required.


ok, when playing with BarPeriod and TimeFrame yesterday, i came up with something similar to your second solution.
Although it is not ideal as you expose it, because it means you are messing up with TimeFrame, and if you want to use other TimeFrame-sensitive functions (TA or price functions), then you have to make sure you set TimeFrame every time.
Or restore it to its previous value once you've used it...
Which is the solution i came up with yesterday.

Here is actually how i "solved" this :
- i created 2 "general-purpose" functions to set and restore TimeFrame;
- for EACH TA function( ATR(),EMA(), etc), i created a function made of an extra "layer" on top of the Zorro function, which saves TimeFrame, calls the Zorro TA function, restores TimeFrame, and returns the result...

Here is an example with ATR():

Code:
//------------------------------------
int __saved_tf;
void set_timeframe(int tf_minutes)
{ // set Zorro's TimeFrame based on the required tf_minutes and the script's BarPeriod
	// save globals that we need to change
	__saved_tf = TimeFrame;
	// set Zorro's TimeFrame based on the required tf_minutes and the script's BarPeriod
	TimeFrame = tf_minutes/BarPeriod;
}
		
//------------------------------------
void restore_timeframe()
{
	TimeFrame = __saved_tf;
}
	
//------------------------------------
var atr(int tf_minutes, int length)
{
	// tf_minutes : timeframe in minutes,
	// to feel like in MT4!
	// length: <=> 'period' in MT4 
	// (num of 'bars' in the given timeframe)

	set_timeframe(tf_minutes); // set Zorro's TimeFrame based on the required tf_minutes and the script's BarPeriod
	
	// now that TimeFrame is set properly according to Zorro specs, we can calculate the ATR()

	var atr = ATR(length);
	
	// restore TimeFrame as it was before entering this function
	restore_timeframe();

	return(atr);
}



function run()
{
  set(PLOTNOW);
  BarPeriod = 60;
  TimeFrame = 1; // timeframe for builtin functions (series(),etc)
  StartDate = 2011;

  // we need to change LookBack to accomodate different BarPeriod and TimeFrame settings...
  LookBack = 100*1440/BarPeriod/TimeFrame;

  plot("adr(1440,60)", atr(1440,60)/PIP, NEW, BLUE);
  plot("ATR(60*1440/BarPeriod", ATR(60*1440/BarPeriod)/PIP, 0, RED);

  plot("BarPeriod",BarPeriod, NEW, BLUE);
  plot("TimeFrame",TimeFrame, 0, RED);

	//plot_balance_equity();

	PlotWidth   = 1000;
	PlotHeight1 = 100;
}

//end



It is heavy, but it works fine, and avoids mistakes with TimeFrame.
And it also gives a clear "atr(timeframe,length)" API.

No messing around with TimeFrame in the "active code", therefore no risk of miscoding it.

Just for THAT single reason : NO risk of hard-to-find errors in the code, i think this approach is much more robust.
You should really consider providing this kind of improvement in the APIs, this will make coders life easier, and less questions/answers in the forum in the future as well;
And believe me, i know exactly how it feels to be bombarded all day long with the same questions again and again because people don't know how to (correctly) use your APIs... wink


Back to my script example with ATR above :
i coded a simple run() function to compare the 2 methods :
- the first one you provided : ATR(60 * 1440/Barperiod)
- the second one, coded with my "enhanced" atr() function, which is equivalent to your second suggestion;

The script is very simple, it will plot both results on the same sub-window, just to make sure they return the same value;
Which it does!

It also plots a second subwindow showing the values of BarPeriod and TimeFrame values as they were set at the beginning of the script;

Now the catch is this :
although both atr methods give the same result (that was expected), if you change the BarPeriod value in the script, then the ATR value will give you a totally different range of values, although the curves have the same shape...

Try with BarPeriod=60, then BarPeriod=5, then 1440, you'll see what i mean.
They should all give the same value ranges and the same curve shapes.
The only one that is correct is when BarPeriod=1440 (120-160p)
In M1/EURUSD, it gives you a DAILY range of ... 2.5-4pips crazy


There's a bug somewhere.
Either in the way i am using ATR(), although both suggested solutions give the exact same (wrong) results,
or in the ATR() function itself!


Another somewhat confusing element is LookBack.
It must be set to a large enough value to accomodate the "longest" "timeperiod" parameter used in any of the TA or price functions.
When playing with daily timeframes, for instance ATR(60 days), if you want to run the script on M1 candles, you will need LookBack > 100*1440 (apparently, any lower value gives an error).
If we set BarPeriod to 1440, then only LookBack can go down to 100 only.

The minimum value also seems to be affected by the value of TimeFrame.

So i came up with this work-around :

LookBack = 100*1440/BarPeriod/TimeFrame+1;

which will accomodate up until ATR(60 days) at least.

But what if i want to calculate ATR(150 days) ?
Then i have to go back and change LookBack again.

This is quite important for backtesting because changing LookBack will greatly affect how far in the past we can backtest.
No way I would set it once for all to 100*1440;
We couldn't run any test with BarPeriod=1440...



Sq