< All Topics

Using Algo Building Blocks And Fixed Input Parameters

Using Algo Building Blocks And Fixed Input Parameters

Fixed Input Parameters give you the ability to hold one or more strategy parameters “constant” during optimization.  This is important, for example, if you wanted to test a range of stop loss amounts, but keep them fixed rather than optimize them.

Before Fixed Input Parameters, you would have to create a separate MultiWalk project for each stop loss amount (or whatever value you wanted to remain fixed).  This became increasingly cumbersome (if not impossible) if you wanted to do this with many different input parameters.

The MultiWalk Algo Building Blocks Module will now do all this for you.

When you define Fixed Input Parameters, MultiWalk will create a new MultiWalk project for each one.

Holding Parameters Constant

Let’s say you have an intraday strategy and you want to determine if there are better times than others to enter or exit trades. You can define two parameters in your strategy such as EntryStartTime and EntryStopTime. You don’t want to optimize them, but rather have them held constant while other parameters, such as StopLossDollars, ProfitTargetDollars and BarsLookback are optimized.

In the above example, 12 different MultiWalk projects will be run:

MultiWalk Project #1:
EntryStartTime 700
EntryStopTIme: 1200
Optimize: StopLossDollars, ProfitTargetDollars, BarsLookback (45 iterations)

 

MultiWalk Project #2:
EntryStartTime 800
EntryStopTIme: 1200
Optimize: StopLossDollars, ProfitTargetDollars, BarsLookback (45 iterations)

 

MultiWalk Project #3:
EntryStartTime 900
EntryStopTIme: 1200
Optimize: StopLossDollars, ProfitTargetDollars, BarsLookback (45 iterations)

 

MultiWalk Project #4:
EntryStartTime 700
EntryStopTIme: 1400
Optimize: StopLossDollars, ProfitTargetDollars, BarsLookback (45 iterations)

MultiWalk Project #12:
EntryStartTime 900
EntryStopTIme: 1600
Optimize: StopLossDollars, ProfitTargetDollars, BarsLookback (45 iterations)

All results will be consolidated in one walkforward report.

Here are the results when running this project on one symbol and bar interval (@GC-240min) with 8 walkforward in/out periods and 3 fitness functions:

Using the walkforward reports, we can compare trading results of different entry and exit time periods.

In the above report, we can quickly see the effect of entry/exit times using various walkforward in/out periods and fitness functions.

We can look for trading edges by looking at profitable scenarios to determine if there are particular entry/exit times that perform better than others.

To help narrow down our choices, we can look at the walkforward in/out report that averages the performance of in/out period groups.  In this project, we defined 8 in/out walkforward periods.  So each averaged group has 8 in/out periods:

Sorting the column on Net Profit shows that there does not seem to be any particular optimal entry/exit times (based on the time ranges we defined).  But it does seem to indicate that there may be a likely edge using the Least Avg DD fitness function.  That fitness function performed better on average than other walkforward in/out period groups.

We can narrow our choices even more by looking at the walkforward report what displays each individual walkforard in/out period (rather than averages groups):

Sorting the column on Net Profit confirms what we saw in the averages report.  While there does not seem to be an edge given the entry/exit times we defined, we do see the potential for an edge using Least Avg DD with 3 specific walkforward in/out periods.

We have now narrowed our focus to a particular symbol and bar interval that performed well on average across many different walkfoward in/out periods on a given fitness function.  We disproved our idea that there may be better times of the day to enter and exit (based on the time ranges we defined).  Another project could be created that widened the testing entry/exit time periods.

Using Algo Building Blocks

Using Fixed Input Parameters, we can test different filters, entry and exit algorithmic methods quickly and easily.  Strategies can be created that switch between different algorithmic “building blocks”.

Let’s say that you had an entry method you wanted to test against various filters.  You would add an IF-THEN or SWITCH statements to your strategy code.  Here is a snippet of the one that will be in the building blocks example strategy:

The above code snippet defines an EasyLanguage variable “FilterMethod “.  Define your optimized parameters for the strategy as usual in MultiWalk, and then add a Fixed Input Parameter for FilterMethod.  Let’s say that you want to test Filters 4, 5 and 6 against your entry and exits in the strategy.  It might look something like this:

And then run the project:

MultiWalk will run 3 projects – one for each FilterMethod define (3, 4, and 5).  The walkforward reports combine the results of all the individual MultiWalk projects.

Example Algo Building Block Strategies and Projects
Algo Building Blocks Strategy #1 – Example 1

Algo Building Blocks Strategy #1 tests various breakout methods against several filters and exit methods. These methods come from Kevin Davey’s books “Algo Trading Cheat Codes” and “Entry and Exit Confessions of a Champion Trader”.

The first example project tests across a handful of symbols and bar intervals (energy markets are particularly good for breakouts):

Since we will be using this same strategy for other building block combinations, we give it a unique sub-folder name (“Example 1”) so that we do not overwrite our results:

The project uses the following ranges:

The blue parameters are Fixed Input Parameters (used by MultiWalk) and the black parameters are normal optimized parameters (used by TradeStation).

For this project we want to test entries against no filters (FilterMethod 1) and ADX non-trending (FilterMethod 4) and trending (FilterMethod 5) filters.

Pay attention to the parameters needed for filters, entries and exits.  You don’t want to create a Building Blocks project using every filter, entry and exit method in the Building Blocks strategy.  To do so would waste massive amounts of computation time running optimized iterations for methods that may not use the optimized parameter.  The result would simply increase the number of iterations.  Since the method may not use the optimized parameter, each iteration would be exactly the same value.  But you would pay the time cost in hours or days trying to optimize that kind of Building Blocks project.

For example, notice that I only chose FilterMethods that use the optimized parameter LowThreshold.  I could have added FilterMethod 6 that uses both LowThreshold and HighThreshold, but would have had to then add the parameter HighThreshold to my optimized list.  Let’s say that I wanted to test HighThreshold from 80-95 step 5.  This would have changed the number of iterations from 600 to 2400.  That means that when MultiWalk runs the project using FilterMethod 4 and 5 that don’t use HighThreshold, it is needlessly computing 2400 iterations when it only uses 600!

For this same reason, we use EntryMethods 1 and 3 that use the common optimized parameter BarsLookback and ExitMethods 1, 2 and 3 that use the common parameter StopLossDollars.

However, for every rule there is an exception.  ExitMethod 1 also uses the optimized parameter ProfitTargetDollars, whereas ExitMethod 2 and 3 do not.  Therefore I am breaking my own rule and wasting time on optimized iterations that will not apply to ExitMethods 2 and 3.  I decided that this was an acceptable waste for this project run, but may have reconsidered if it was going to take too long to run.  Adding ExitMethod 1 and ProfitTargetDollars changed the optimized iterations from 100 to 600, so that is quite an increase!  If after the run I found strategies that I wanted to further analyze that used ExitMethod 2 or 3, I would need to remove ProfitTargetDollars from that project since it is not used.

We then create the MultiWalk version of the strategy.  This is the strategy used to run the entire project:

Note that we gave it a unique name using “- Example 1”.  This is important because we are going to create other projects using this same base code of the strategy, but using different fixed input and optimized parameters.  Therefore each project needs its own MultiWalk version of the master strategy so that it includes the correct parameters for our project.

By giving the MultiWalk version of the strategy a unique name, this means that it will also create a completely separate project folder for all our results:

The project took just under 4 hours to run on my Intel i9-11900K:

I’m not sure the wasted iterations because of our use of the ExitMethod using ProfitTargetDollars was worth it.  But there are quite a few good looking potential strategies to explore from the run:

The building block methods (fixed input parameters) that generated the results are at the far right/last column of the report:

Algo Building Blocks Strategy #1 – Example 2

This example uses the exact same Building Block strategy, but with a different set of filters, entries and exits.

Since this uses the exact same strategy, we are going to give it a different sub-folder name “Example 2” so that we do not overwrite our other project results:

It uses the same a handful of symbols, but uses these parameters and ranges:

I’m going to use the same filter methods as the first project, but now use EntryMethod 2 and ExitMethods 4 and 5.  These use a new optimized parameter ATRMultiplierStopLossDollars and ProfitTargetDollars are not used, so we removed those from the project.

This reduced our fixed input projects to 6 and reduced optimized iterations to 125.

We then create the MultiWalk version of the strategy.  This is the strategy used to run the entire project:

But this time we are giving the project a unique name by using “- Example 2”.  We need to do this for two reasons:

  1. Because it is a completely new project from our first variation “Example 1”
  2. While we are using the same strategy base code as the “Example 1” project, we are using different fixed input and optimized parameters. Therefore each project needs its own MultiWalk version of the master strategy so that it includes the correct parameters for our project.

By giving the MultiWalk version of the strategy a unique name, this means that it will also create a completely separate project folder for all our results:

The project took just under 1 hour to run on my Intel i9-11900K:

Given the particular entry, exit and filters used, there are quite a few good looking potential strategies to explore from the run:

The building block methods (fixed input parameters) that generated the results are at the far right/last column of the report:

Table of Contents