| View previous topic :: View next topic |
| Author |
Message |
VladGor Support Team
Joined: 26 Jan 2004 Posts: 528
|
Posted: Wed Feb 08, 2006 4:53 pm Post subject: |
|
|
| Quote: |
1. A gene is simply a parameter that you wish to test (optimise) and as
long as it is numeric, it is usable. |
Yes
| Quote: |
2. A chromosome is used to group specific genes together so (for
example) in a strategy with 20 different setups, you would logically put
all of the genes for each setup into their own unique chromosome - that
way the system wastes less time testing non-correlated combinations
between chromosomes. |
Yes
Succesful combinations of parameters in chromosomes are saved more often and more often given to next generation.
Grouping genes in chromosomes is not necessary, TSGO will work anyway, even if genes are grouped incorrectly or placed in one chromosome. Grouping genes we give additional information to TSGO and it helps to quicken optimization.
| Quote: |
3. In hierarchal systems such as a system that has algorithms that
determine biases for a given market environment, and then has setups
that are unique to each type of environment, you should use a chromosome
for each market environment algorithm (assuming more than one) and then
individual unique chromosomes for each "sub-setup." |
If you understood then Yes.
| Quote: |
4. If you set the GOMode to 1, and place the Population input ABOVE the
Gen input, then you can effectively extend the possible iterations
(generations) from 100 up to 100,000 by optimising (in Tradestation) on
Population = 1 to 100 AND Gen = 1 to 1000; Since Gen is second in line,
TS will set Population to 1 (this is an extreme example, I would
probably start population at 20, or else I would add a bit of code to
allow me to count DOWN instead of UP.) and then it will cycle through
all values of Gen before incrementing Population and restarting. This
should effectively cause you to analyse each result set as the basis for
the next analysis until you reach the last Population value. Actually, I
suppose you could even just introduce a dummy input (unused except for
being declared) and use that as your "recycling" counter for reiterating
infinitely (if you wished). |
Unfortunatelly we didn't quite understand you.
Comment.
Gen should have values from 1 to N in optimization independently from values of GOMode or other parameters.
1. When Gen = 1 initialization of optimization is performed.
2. On every following run Gen should be more than Gen in previous run.
3. If Gen on next run is <= than previous Gen then new candidate in population is not generated but best is choosen.
When optimization is finished TradeStation starts final run of strategy with the best value of Gen. It will always be <= than value of Gen at previous run. TSGO in this situation will give parameters of best sample and results that are showed on chart and report.
GOMode influence initialization of algorithm TSGO.
GOMode = 0 - Population is zeroed and optimization is began from blank. This mode is used with first run of optimization.
GOMode = 1 - Population is not zeroed and mode of fitness calculation is turned on. In this case TSGO in the beginning gives parameters of all samples existing in population. Fitness that is obtained after run replaces fitnes for this sample in populatin. This mode is needed for continuing optimization in situation price series has changed for example new has appeared. Fitness has changed so we need to reacalculate.
GOMode = 2 - Population is not zeroed and optimization continues from interrupted place. This mode is used if we have interrupted or finished optimization and then decided to continue it. Gen should change from 1 in both cases. |
|
| Back to top |
|
 |
Hannibal Guest
Joined: 08 Feb 2006 Posts: 6
|
Posted: Wed Feb 08, 2006 6:42 pm Post subject: Reiteration of Question 4 |
|
|
Let me be more clear about question 4:
I have a system that (currently) has 21 chromosomes, each with anywhere from 2 to 15 parameters. There are 3 chromosomes that focus exclusively on general market biases and the rest are actual setups (signals) tied to entry and exit code.
Overall that's roughly 150 genes each with an average of 25 possible values yielding a rather large number of possible permutations.
Given that my population is limited to 1000 and the number of generations is limited to 1000 - I need to perform several test runs in order to be comfortable that I have tried a reasonable subset of the available permutations.
First off: In performing "serial" test runs, should I set GOMode to 1 or 2? Which yields the best results or the fastest run time?
Secondly; All other parameters being correctly set, if I use an extra "dummy" input and have it count say from 1 to 5 in the TS optimisation engine while simultaneously optimising Gen from 1 to 1000, will I get the same results as if I had run a simple Tradestation optimisation of Gen from 1 to 1000, and then manually restarted the whole process again (with GOMode set to 1 or 2), repeating this process 5 times?
Thanks for your help!
Marc |
|
| Back to top |
|
 |
VladGor Support Team
Joined: 26 Jan 2004 Posts: 528
|
Posted: Thu Feb 09, 2006 2:30 pm Post subject: |
|
|
| Quote: |
| Let me be more clear about question 4: |
If testing is performed on the same history, then GOMode = 2 should be used. Every run of optimization will perform additional 1000 steps of optimization.
If before instant run history has changed, GOMode = 1 should be used and number of runs should be increased to 2000.
First 1000 generations will be used for recalculation of fintess in population and next 1000 generations will be used for 1000 steps in optimization.
In the last case size of population can be decreased in order to use less than 1000 generations for recalculation of population.
In process of optimization size of population changes dynamically between 10 and set value (1000 in your case) by some
heuristics for speeding up optimization.
It's useful to turn on FreshBlood = 1 that increases effective size of population. When FreshBlood = 0, only best samples are left in population.
When FreshBlood > 0 (0.5 - 10), not only best samples are left in population so there is less possibility to have local minimum.
Speed of optimization decreases accordingly.
| Quote: |
Secondly; All other parameters being correctly set, if I use an extra
"dummy" input and have it count say from 1 to 5 in the TS optimisation
engine while simultaneously optimising Gen from 1 to 1000, will I get
the same results as if I had run a simple Tradestation optimisation of
Gen from 1 to 1000, and then manually restarted the whole process again
(with GOMode set to 1 or 2), repeating this process 5 times? |
Yes.
It's necessary for cycle of Gen to be performed inside of cycle on extra "dummy" input.
If extra input parameter influence work of strategy or history interval then it's necessary to use GOMode = 1, if not then GOMode = 2.
As example you have a look how WFO (Walk Forward Optimization) was performed:
http://www.tsresearch.com/research/wfo/tsgowfo/ |
|
| Back to top |
|
 |
Hannibal Guest
Joined: 08 Feb 2006 Posts: 6
|
Posted: Fri Feb 10, 2006 2:40 am Post subject: Summary |
|
|
Thanks Vlad;
So if I understand it correctly -
GOMode = 1 is used when either the underlying system has changed, or the underlying data (or data window) has changed since it takes the successful result population and recalculates the system using those inputs in order to validate them. In this case, Gen must be set to at least the population size, since it must first recalc each of the existing entities in the population before taking on any new generations.
GOMode = 2 would be the default if we were simply iterating through the same system and data, since recalc would be pointless.
You also mentioned setting Gen to interate 2000 times - I thought we were limited to only 1000 generations - is this not true? If not, is there a limitation to the number of Generations and if so, what is it? |
|
| Back to top |
|
 |
VladGor Support Team
Joined: 26 Jan 2004 Posts: 528
|
Posted: Fri Feb 10, 2006 5:55 pm Post subject: |
|
|
| Quote: |
GOMode = 1 is used when either the underlying system has changed, or the
underlying data (or data window) has changed since it takes the
successful result population and recalculates the system using those
inputs in order to validate them. In this case, Gen must be set to at
least the population size, since it must first recalc each of the
existing entities in the population before taking on any new generations. |
Yes
| Quote: |
GOMode = 2 would be the default if we were simply iterating through the
same system and data, since recalc would be pointless. |
Yes
| Quote: |
You also mentioned setting Gen to interate 2000 times - I thought we were limited to only 1000 generations - is this not true? If not, is
there a limitation to the number of Generations and if so, what is it? |
There are limitations in current version on
- maximum size of population = 1000
- maximum number of genes = 1000
- maximum number of chromosomes = 1000
No limitations on number of generations.
We have tested on several millions of generations.
Usually 200 - 2000 generations is enough.
Probably there is need for more generations for system with 150 genes. |
|
| Back to top |
|
 |
Hannibal Guest
Joined: 08 Feb 2006 Posts: 6
|
Posted: Fri Feb 24, 2006 8:21 pm Post subject: Fitness Algorithms |
|
|
Hello Vlad;
I have been running now for a few weeks and am getting great results - thanks for this great tool!
I have found the SystemQuality and TS.Fitness functions already in the forums, but I was wondering whether you had any other algorithms that you find useful - if so, would you consider posting them here?
In addition, I would like to post some pseudocode that I am now using to define fitness in a two tiered manner. My theory, underlying this concept, is that it is better to give unfit solutions a low weighting rather than a negative weighting, in order to allow "the best of the worst" to continue being considered within the population until such time as they are replaced by better solutions.
The algorithm works basically like this:
1) Using target values for the performance statistics that you wish to test, you normalise them such that meeting or exceeding the target generates a value of 1 and falling short generates a fraction representing how close the solution got to the target.
2) If all of the targets are met, then the fitness algorithm switches to evaluating the performance using relative merit as defined by a second "open ended" calculation that has a minumum value > 1.
I'm only including pseudocode here because it would be up to the user to determine which parameters they wished to test, and how many, as well as what they wished to use as a step 2 fitness test.
| EasyLanguage: |
Inputs: TargetPF( 2.0 ), TargetPctProfit( 50 ); Variables: PFFactor( 0 ), PctProfitFactor( 0 ), BaseFitness( 0 ); PFFactor = ( GrossProfit / - GrossLoss ) / TargetPF; PctProfitFactor = PercentProfitable / TargetPctProfit; BaseFitness = MinList( 1, PFFactor ) * MinList( 1, PctProfitFactor ); //BaseFitness can never result in a value greater than 1 If BaseFitness = 1 Then Fitness = TS.Fitness //for example Else Fitness = BaseFitness;
|
The idea is that TSGO will work to find solution sets with the Base Minumum requirements first, and then work to find the best of those using the more robust fitness test.
Thanks for all your help Vlad.
Please let me know if I am completely misunderstanding the purpose of the population database. |
|
| Back to top |
|
 |
VladGor Support Team
Joined: 26 Jan 2004 Posts: 528
|
Posted: Mon Feb 27, 2006 1:21 pm Post subject: |
|
|
| Quote: |
| I have found the SystemQuality and TS.Fitness functions already in the forums, but I was wondering whether you had any other algorithms that you find useful - if so, would you consider posting them here? |
You can have a look at examples in this forum and in our publications. For
example the last example:
Fitness = NetProfit / (K - MaxIDDrawDown)
where K - value of DD that we consider important.
| Quote: |
| The idea is that TSGO will work to find solution sets with the Base Minumum requirements first, and then work to find the best of those using the more robust fitness test. |
Yes, possible version of fitness...
In fact fitness can be complicated when using TSGO.
| Quote: |
| Please let me know if I am completely misunderstanding the purpose of the population database. |
We didn't understand this, please describe it more detail |
|
| Back to top |
|
 |
mjo Guest
Joined: 08 Nov 2007 Posts: 4 Location: Boston, MA
|
Posted: Thu Nov 08, 2007 6:03 pm Post subject: Block Manager trades not showing trades in TS chart |
|
|
I am interested in using the Block Manager concept to combine and test signals. I am having a problem with the TS.GO.Manager code.
To make sure I understand the concept, so far I have created three separate Easylanguage strategies: TS.GO.Manager, TS.GO.MA4 and TS.GO.ATR. I used the code blocks that were provided in this forum to create these files. When I apply these three strategies to a chart and run an optimization, the resulting trade names and "buy sell" lines do not show up on the chart. I can open the TS Genetic Viewer and see that the optimization has run and there are results. These results also show up on the TradeStation Optimization, but the Strategy Performance Report says "no trades were generated."
As a check, I incorporated the code from the three above strategies into a single strategy file, making the appropriate edits to remove duplicative terms. When I run this single strategy file, the trades do show up on the chart and in the Strategy Performance Report. While this is a "fix" it defeats the purpose of using the TS.Go.Manager as a "system builder" tool that can test multiple signals independently, as I understand the concept.
FYI, the "getstrategyname" is no longer a valid reserved word in Easylanguage, but this is not the problem. _________________ MJO |
|
| Back to top |
|
 |
mjo Guest
Joined: 08 Nov 2007 Posts: 4 Location: Boston, MA
|
Posted: Wed Nov 21, 2007 6:20 pm Post subject: Re: Block Manager trades not showing trades in TS chart |
|
|
After a few weeks of using the TSGO I can answer my own question.
The code above for the TS.GO.Manager is missing a reference to the ShowInd function that writes the final solution to the chart.
The code in the Manager should have a line like:
Ind=Iff(LastRun=1,ShowInd,0); _________________ MJO |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|