optimize() limitations?

Posted By: DdlV

optimize() limitations? - 07/07/13 16:26

It appears optimize() can't be used with BarPeriod? (& other System Variables?) Is this correct? Are there any other optimize() limitations?
Posted By: jcl

Re: optimize() limitations? - 07/08/13 06:55

AFAIK there are no optimize limitations. Maybe you've changed BarPeriod at the wrong moment, such as after loading the asset?
Posted By: DdlV

Re: optimize() limitations? - 07/08/13 13:22

I've tried with exactly one BarPeriod = optimize(...).

With no if(is(INITRUN)), Train works but the parameter graph is identical for all values, no matter what optimize settings I've tried (so far).

With the BarPeriod = optimize(...) inside an if(is(INITRUN)), Train gives an error 040, Bar 1:2 - Bar 2:0.

Zorro 1.12.
Posted By: jcl

Re: optimize() limitations? - 07/08/13 13:55

You can find the meaning of all error numbers in the manual under "Error messages". Error 040 just means a wrong number of optimize calls. You can not sometimes optimize and sometimes not - either you call optimize in every run, or not at all.

http://manual.zorro-trader.com/optimize.htm

If you can't find the problem, please post your script here and I'll look over it.
Posted By: DdlV

Re: optimize() limitations? - 07/08/13 14:26

Thanks jcl. I've been to the manual many times. But that doesn't mean I understand it all! laugh

First, shouldn't the error/result be the same no matter where BarPeriod is set?

As for the example code, this:
Code:
function run()
{
	set(PARAMETERS);
	BarPeriod = optimize(240,60,1440,60);
	Stop =	10 * PIP;
	Trail =	10 * PIP;
	enterLong();
}


gives identical results for all optimize parameters I've tried so far.

This:

Code:
function run()
{
	set(PARAMETERS);
	if(is(INITRUN)) BarPeriod = optimize(240,60,1440,60);
	Stop =	10 * PIP;
	Trail =	10 * PIP;
	enterLong();
}


gives the Error 040.
Posted By: jcl

Re: optimize() limitations? - 07/08/13 14:48

The Error 040 is because you called optimize() only in the first run. It is not allowed to have a different number of optimize calls in different runs.

As to why you got identical results, I'll have to ask. Maybe once the bars are built, subsequent changes to BarPeriod have no effect. If so, then you have to use TimeFrame instead of BarPeriod for optimizing the bar period:

Code:
function run()
{
	BarPeriod = 60;
	set(PARAMETERS);
	TimeFrame = optimize(4,1,24,1);
	Stop =	10 * PIP;
	Trail =	10 * PIP;
	enterLong();
}
Posted By: DdlV

Re: optimize() limitations? - 07/08/13 15:01

Thanks jcl. It's so much fun being a junior programmer again & making such idiotic mistakes... frown

At least now it's maybe sunk in that optimize() is not a "meta" process set up once at the beginning of strategy execution, but rather implemented as a regular function call...

But BarPeriod may be... Thanks for the TimeFrame code.
Posted By: DdlV

Re: optimize() limitations? - 07/09/13 20:51

jcl, I tried your TimeFrame optimization above but am suspicious of the results. Every odd parameter value (e.g., 1, 3, 5, ... 23) has exactly the same result. Some of the other results are duplicated too, but not that often. This has happened with every asset I've tried so far. Do these results really make sense?
Posted By: jcl

Re: optimize() limitations? - 07/10/13 08:50

I also had to ask and learned that they are correct, but do in fact not make much sense. Reason is that for TimeFrame only the time frames on the Period slider are supported. Inbetween time frames are ignored, so as if you had not set time frame at all.

This was not documented and is in fact an unnecessary limitation in my opinion, so in the next Zorro version all time frames will be supported, even odd values.
Posted By: DdlV

Re: optimize() limitations? - 07/10/13 11:54

Thanks jcl. Please clarify what the "time frames on the Period slider" are. I though the Period slider set BarPeriod, not TimeFrame. For a given BarPeriod, what TimeFrames are currently supported in 1.12?
Posted By: jcl

Re: optimize() limitations? - 07/10/13 12:51

When you move the period slider, you'll notice that it does not move continuously, but sets certain time periods, like 30 minutes, 1 hour, 4 hours, and so on. They are the standard time frames used in trading programs, and they can be set with TimeFrame.
Posted By: DdlV

Re: optimize() limitations? - 07/10/13 23:41

OK, I created an array of the 19 allowed TimeFrames based on the values given by moving the period slider. I set TimeFrame via using optimize to step through the indexes. (BarPeriod = 1) (Yes, I understand this is going from linear indexes to non-linear values, etc. This is just testing/playing! laugh )

At this point I don't trust the results. 5 & 15 gave identical values. 10 & 30 gave identical values. 20 & 60 gave identical values. 45, 120, & 240 gave identical values. 180 & 300 gave identical values. And 1440 gave the biggest numbers & took forever - shouldn't it have been the smallest & fastest?

(What are those numbers, anyway? % & win/loss, w/o regard to value?)
Posted By: jcl

Re: optimize() limitations? - 07/11/13 10:22

It's the result of the objective function - you can find it in default.c.

As to the identical values, we'll check that. To tell the truth, AFAIK no one had ever optimized the bar period or the time frame with the optimize function, so I suspect that there's something wrong with the identical values.
Posted By: DdlV

Re: optimize() limitations? - 07/11/13 13:02

I gather the % is the return from the objective function, but what are the x/y displayed afterwards? The Num's, Total's, Max's, or other?

Thanks.
Posted By: jcl

Re: optimize() limitations? - 07/11/13 13:41

Yes, the x/y are winning and losing trades.
Posted By: DdlV

Re: optimize() limitations? - 07/11/13 13:42

It seems the x/y are NumWinTotal/NumLossTotal, without removing the biggest win & loss, correct?
Posted By: jcl

Re: optimize() limitations? - 07/11/13 13:48

Yes. The biggest win and loss are removed in the objective function.
© 2024 lite-C Forums