1. If I have a system with, let's say, 5 parameters but only want to optimize 2 of them, is there a way to run the G/O and only optimize some, not all parameters?

2. Is it possible to optimize non-integer parameters in increments of 0.5? It seems like if you use type "Real", G/O uses the increment of 0.01.

3. Can you stop the G/O run without shutting down TradersStudio? The "Cancel" button doesn't do anything.

If you want to skip a variable you can make the max and min the same value.

 I though the ESC key worked. I will look into it.

 In terms of optimizing using steps that would create problems because GA are a optimization method and moving in steps would make us more likely to get stuck in local minimums.

 Any ideas you have please write Murray@TradersStudio.com and tell him. We will look into adding these features in the next upgrade.

 

 

 

Just so you know, setting the min and max to the same value doesn't do the trick. The G/O still optimizes those variables, actually all variables. I had a suspicion that that was the case, but couldn't prove, but I just ran what seemed like a simple optimization (less itterations than what you show in the G/O manual), which took an hour and half, and the best results spreadsheet had optimized the parameters that were supposed to be left unchanged (min/max -- the same value).

And, btw, when you try to cancel the run you get a "Wait" dialog box that says "Please wait to finish the last step". The only way I see to stop the optimization is to kill the task in the Windows Task Manager.

I think the Genetic Optimizer is a fantastic tool, and I would love to use IT, rather than run the traditional optimization, but it seems like unless your parameters are integers, it would be impractical to run it, especially if you have a lot of markets, and a lot of years of data. 16 markets, about 5 years of daily bars each, 2 real parameters -- my run times were estimated at 3-4 hours. I think part of the problem was that the optimizer was optimizing the parameters that I wanted to leaved fixed, and no doubt, brute force optimization would probably have taken much, much longer, but still...Any comments on this?

Brute force would have taken much longer.  Please E-Mail Murray@TradersStudio.com and give your ideas for improving the product. We will make a upgrade in the early fall September -October  and improve the product even more.

 GA users tell us what you want to see and we always try to keep our customers happy.

 

Murray,

I think darshanksy may be right regarding the GO ranging all variables in its optimization process, even those that are set to have no range.

I took the basic TSStockBAHAdjust session and ran the brute force (BF) optimizer on it as a baseline.  The session, as you know, had 4 variables.  I optimized only three of them - Lookback, BearMult and BullMult just to see what would happen.  I kept the ranges "chunky" because I was just trying to get a feel for performance:

• Lookback: range from 4-12, step 2 (5 iterations)
• BearMult: range 1.1 - 1.5, step 0.2 (3 iterations)
• BullMult range 1.0-1.6, step 0.2 (4 iterations)
• DisStop: no range.  25
  

for a total of 60 permutations.  Running the BF optimizer took about 3:07:00 with a stop watch.

Today, I set up a GO optimization of the same system with the same variables and same ranges.  To avoid optimizing DisStop, I set its upper and lower bounds identical.  Lookback I set as an interger.  BearMult and BearMult I set as real numbers, and DisStop was set to integer.

Results: as of this posting, the GO is 39% complete after 2:02:44 with an estimated completion time of 5:15:35 (and rising through each step).  Clearly this is significantly longer than BF optimizer.

It seems likely that the GO is using finer steps than those I explicitly set in the BF optimizer.  In addition, if DisStop is in fact being optimized as darshanksy reports, it would greatly increase the number of permutations and explain the apparent performance disparity.

You are correct. You need to compare the optimization time to all variables in steps of 1.The GA is capable of  using the smallest defined steps.  Which would have taken much longer. In addition there are some issues with setting variables to not be optimized, for example no range, this generates a few cases in current version. This will be fixed in the next upgrade.

What controls the number of trails is Population size and Number of Generations. Without using advance setting we multiple these two number together and that is the default trials run by the GA.