When I create a few fancy new Building Blocks along with their Genes, I run into the issue, that some complex rules apply about the combination of these Building Blocks.
Example 1: Transaction Weight.
Such a Block should be applied to an entry block only. And it is allowed only once.
Example 2: Trailing Stops.
If I have a simple Trailing Stop (a wrapper for CloseAtTrailingStop()) and a second more elaborate Trailing Exit
(With Timeout, Profit Target, etc.) then these two should be mutually exclusive.
Now, obviously I can do some checks (Parent Blocks, existing Conditions, etc.) in GenerateVarCode() and throw an exception if my rules are violated. This will stop Evolver from executing that strategy in the first Generation and remove it in the next generation.
BUT: This „illegal“ strategy occupies a slot in one Generation.
If there are several fancy Building blocks with complex rules this can slow down evolver quite a bit.
So I am Looking for a way to signal unwanted combinations to Strategy Evolver and make it discard the strategy and build another one before the next Generation is evaluated.
Similarly, I’d like to issue some warning if a user composes such a strategy.
Example 1: Transaction Weight.
Such a Block should be applied to an entry block only. And it is allowed only once.
Example 2: Trailing Stops.
If I have a simple Trailing Stop (a wrapper for CloseAtTrailingStop()) and a second more elaborate Trailing Exit
(With Timeout, Profit Target, etc.) then these two should be mutually exclusive.
Now, obviously I can do some checks (Parent Blocks, existing Conditions, etc.) in GenerateVarCode() and throw an exception if my rules are violated. This will stop Evolver from executing that strategy in the first Generation and remove it in the next generation.
BUT: This „illegal“ strategy occupies a slot in one Generation.
If there are several fancy Building blocks with complex rules this can slow down evolver quite a bit.
So I am Looking for a way to signal unwanted combinations to Strategy Evolver and make it discard the strategy and build another one before the next Generation is evaluated.
Similarly, I’d like to issue some warning if a user composes such a strategy.
Rename
QUOTE:A Trailing Stop doesn't have to be mutually exclusive with another exit. That would be a terrible restriction to impose.
If I have a simple Trailing Stop (a wrapper for CloseAtTrailingStop()) and a second more elaborate Trailing Exit (With Timeout, Profit Target, etc.) then these two should be mutually exclusive.
This was meant as an illustrative example...
Maybe you should provide an example that makes more sense to support your point of view. I read that part and immediately said, "madness!"
My example said:
Just imagine two finantic Building Blocks...
QUOTE:
then these two should be mutually exclusive
Just imagine two finantic Building Blocks...
I don't use the evolver yet. But reading this, I would say from a distance, make a single Building Block from the exclusive elements controlled by parameter.
In the example above, parameter with value 1 can stand for the first TS and value 2 for the second.
This way you get "one" block that controls which stop is used and are automatically exclusive.
The only requirement is that the parameter can also be changed by the evolver.
This is a hypothetical solution, as I have not really used the tool so far. Maybe it will help anyway.
In the example above, parameter with value 1 can stand for the first TS and value 2 for the second.
This way you get "one" block that controls which stop is used and are automatically exclusive.
The only requirement is that the parameter can also be changed by the evolver.
This is a hypothetical solution, as I have not really used the tool so far. Maybe it will help anyway.
Instead of working at the Building Block level, would it not be better to work at the StrategyGene level? A validation routine could see if a proposed Gene is valid given the current state of the Genes already in place.
This will be ready for Build 60. Added a new virtual method
to StrategyGeneBase.
So you can employ any logic you need to filter out combinations you deem invalid.
CODE:
IsValid(GeneticStrategy gs, StrategyGeneBase parentGene)
to StrategyGeneBase.
So you can employ any logic you need to filter out combinations you deem invalid.
Exactly as envisioned. Very good!
The new method IsValid is now available in Build 60, and is documented in the API doc.
Your Response
Post
Edit Post
Login is required