Moving Averages for balances - New Variables and Actions

I'm sure I'm not alone in the way I use MFP to develop systems.
i.e. Run the system in Test mode, load the resulting Test statements into excel and analyse the results.  i.e. Build a system model.
I often run several systems simultaneously, using the amount bet to differentiate the systems and then filter the results in excel to extract the system being analysed.
When a system shows promise I'll run another instance of MFP in real mode using the new system (using small bets initially).
I'm a firm believer that a system has to be profitable using level stakes.
I might deploy a staking plan in practice because it should boost profits, but in my analysis it has to work using level stakes.

I've often wanted the ability to let my system run unattended, switching between test mode and real mode depending on whether the system is in a purple patch or not.
The concept can be modelled in excel from the MFP statements.  i.e. Plot the balance of the system and then calculate some moving averages (SMA - simple moving average and/or EMA - exponential moving average).  One outcome could be to monitor the Moving Average variables such that when these averages cross the balance or each other ("Crossover"), then switch the mode accordingly.

There is an excellent seven part tutorial of the moving averages used by stock market traders and how they can be used at: http://www.investopedia.com/university/movingaverage
"Other tutorials are available" as they would say on the BBC!

So.........to my suggestion for a new feature, Moving Average variables!
But not for the price movement in an in-play market, but for the Test and Real balances.  Although for in-play markets could be yet another suggestion.
MFP already implements this idea on the price charts in Full and Engineer mode, but as far as I'm aware the variables/data that MFP calculates for the Trend line that can be displayed on the chart isn't available to us to use in Triggers.  The obvious question is why not?  It might be because those MFP users who are of the "trader type" use the traded_avg_price, lt_ma, b_leap, b_growth,
pdif and tdif etc. type selection variables to achieve a similar result but I have to confess I have never used them because I'm not an in-play trader type.  I'd certainly be interested in those that are of the trader type if they offered a way or example of how to use those variables.  Someone must be using them in anger!
Anyway, back to my suggestion of Moving Average variables for balances.

The executive summary of the below is to provide a smaller set of functions similar to traded_avg_price, lt_ma, b_leap, b_growth type, pdif and tdif etc. but for a new balance variable based on the Real & Test balances.

In order to achieve this, to my simplistic mind, we need a new balance; let's call it "model_balance".  The model_balance must be updated irrespective of the mode (real/test) MFP is running in.
We now need some moving average variables, a means of calculating them, and like the "model_balance", they must be updated irrespective of the mode when a market is settled.

As we all know moving averages are calculated on historical data (you should know this after reading the tutorial at http://www.investopedia.com/university/movingaverage!)
So let's create a text file (easily done from excel) with one value per line.  In my example below I'm using a 200 point SMA and a 50 point SMA..
In this example, let's say the text file contains 1000 values.  So the first 200 point SMA value will be calculated after line 200 has been read (ie. 1 - 200).
The next 200 point SMA value (SMA(200)) will be calculated from 2 - 201, the next from 3 - 202, etc.  i.e. A sliding 200 point window.
(I appreciate that if the file contains more lines than the number points in the SMA then only the last 200 values need to be processed in this particular example)
When the last line of the text file is read, SMA(200) will be updated for the last time from the text file.
Repeat for a 50 point SMA value - SMA(50) using the last 50 values from the text file.

So I now have a model_balance value (last value from the text file), a 200 point and a 50 point SMA value.
Now MFP can make decisions about what mode to be in based on the model_balance and these moving averages as the model_balance and moving average variables move after each race bet on.
This is directly analogous to traders using Moving averages to generate "buy" or "sell" signals.

e.g. If model_balance > SMA(200) use Real Mode.  If model_balance < SMA(200) use Test Mode.  If SMA(50) > SMA(200) switch to real mode, etc.

I might want to use 2 SMA values or even three, all using a different number of data points.  High value ones (e.g. 200 points) obviously move slowly around the balance, lower ones (e.g. 50 points) will move quicker.  EMA variables respond quicker to recent values.

As MFP runs, it is essential that the model_balance and any Moving Average variables are updated when the real or test statement is updated.

I have also been experimenting with a mixture of SMAs and EMAs.  So I would like to see both these types being made available (pleeeeease!).
This means we need some new trigger Actions (which would be at the start of the trigger file) along the lines of:

Create Model <filename.txt>               -- The last value will give us "model_balance"
                     -- Other values will be used to calculate any Moving Average variables
Create Moving Average <Name> <Points> <Type>      -- Name is the Variable name
                     -- Points is the size of the moving average window (e.g. 2 to 1000)
                     -- Type is either SMA or EMA
                     
Create Smooth Moving Average <Name> <Points> <Damping>   -- Damping is the damping factor (as per the charting tool option).


The method of calculating an EMA type moving average using an automatically calculated multiplier (damping factor) given in the tutorial using an N point SMA where N=10 is:

SMA:             Sum of last 10 values / 10
Automatic Weighting multiplier :    (2/(10+1) = 0.1818  (Clearly this changes as N changes)
EMA:             model_balance - EMA(N-1) x multiplier + EMA(N-1)

I don't know the maths behind the charting tool trend line ("Smooth Moving Average") other than it uses a user provided Damping factor (e.g. 0.9) and moving average "window" (e.g. 20 refreshes).
But I would like to know!

If this suggestion is implemented, then it opens up other ideas such as having a means to determine the slope (positive or negative) of a moving average to predict a reversal.

Having read the tutorial I'm now going to update my excel model with a moving average envelope to see what that does for me - no stopping me having a good time!

regards

Wez

PS: Apologies for the length of the post.

Hi Wez,
I'm slowly taking in your post and will comment more on it later, but just so you know we have two trend variables: vol_trend and lt_trend. The first one returns the trend value (from -0.9999 to 0.9999) of the volume percentage growth for each selection, and the other one is the last traded trend figure, having the same range. The negative value indicates that the parameter is dropping in value, and vice versa. I realise this is not exactly what you were asking, but I thought I'd throw in this bit of information just in case.

Hi Wez,


Congrats on a great post!

I will have to re-read it a few times, but it already has given me some ideas. If I have anything useful to contribute, then I will surely throw it in the "stewing pot"

larp

To try and illustrate my earlier post regarding Moving averages for balances I have generated a series of plots.
Apologies for the "5 year old" scrawl on some of them - "writing" with a mouse isn't easy!
A decription of what each plot is trying to illustrate is at the end of this post.

I have attached the spreadsheet I used to create the plots in case it is of interest..zzzzzzzz.  Hit F9 and the RND() values and the plot will update - hours of fun!  The chart is in Col S.
If interested...zzzzzz...the values produced in column F are "noisy" because of the SIN() function so I smoothed this using an "SMA(25)" formula (col G) to simulate the balance my System X trial might have produced.  Select all of the values in Col F and insert a 2D line chart and you'll see what I mean.  Plot #1 used this noisy balance.  It was seeing this plot that prompted me to smooth it using an SMA(25) formula for the plots that followed.

A couple of points to note:

Model_balance is the new variable MFP needs to provide (Blue trace).  I have "simulated" 1000 bets.  The first 200 bets ("Trial") are me monitoring the System under test with MFP always in Test

mode.  At bet 201 onwards, I've gone "live".

As the mode of MFP is switched between Real and Test, the model_balance gets updated with the P/L result of the most recent settled bet irrespective of the mode.

The Model_balance in the plots was generated using the RND() function and Sin(x) function.  Hence the oscillation at the start of the plot.  I wouldn't use data such as that to make a decision to go

live with a system!!  This is purely for illustration purposes only.  If I had more time I could address it but I don't ATM - I need my bed.

Some of the plots show a SMA(150) trace.  This is a labelling mistake on my part - it is really SMA(200) as is clearly evidence from the fact the green trace doesn't start until 200th bet.

So the scenario is this:

I trial a system using MFP to gather data on a particular system I want to test.
After 250 bets, I decide to go "live" with it.  These bets might have been produced over a period of a week or a couple of months - it depends on the system you are testing.
So, I produce a text file (System X.txt) which has the balance from my excel model.  This text file has 250 values in it.
MFP reads the 250 values to produce SMA(50) and SMA(200) - Simple Moving Average over 50 points, Simple Moving Average over 200 points using the "Create Model" and "Create SMA(50)" and

"SMA(200)" triggers I have proposed.  The value in the parethesis can be any value you want as a moving average window.  I've chosen 50 & 200 purely for illustration purposes.

I have supplied the first 250 values in the "System X.txt" file as an example.
If you paste these values into excel from A1 to A250, and then type "sum(a1:a50)/50" into B50 and drag the formula down to B250, you have created SMA(50).
If you type "sum(a1:a:200)/200" into C200 and drag the formula down to C250, you have SMA(200).
To visulise these data, select a1:c250, then "insert 2D line chart".  You will see that from bet 66 onwards the trend is upwards.  This also clearly shows the two cycles of oscillation due to the formula

I used to create the data in the first place!  SMA(50) starts at bet 50 and,you've guessed it, SMA(200) starts at bet 200 onwards.

So MFP now has model balance = 237, SMA(50) as 225 and SMA(200) as 169.

So, now after trialling a system for 250 bets with MFP in test mode, I have decided to go live.  The plots from bet 250 onwards are a simulation of what might have happened.  i.e. It is looking into the

future.  So, with the triggers below, I set the system live and after another 750 bets, the plots show what might have happened.


Triggers:

Create Model "System X,txt"            -- This produces new variable "model_balance"
Create Moving Average "SMA(50)", 50, SMA      -- This produces a new variable called SMA(50)
Create Moving Average "SMA (200)", 200, SMA      -- This produces a new variable called SMA(200)
Switch Test Mode On if Model_balance > SMA(200)
Switch Test Mode Off if Model_balance <=SMA(200)

System X bet placement triggers go here.
-----------------------------------------------------------------------------
Model_balance gets updated with the P/L result of every settled bet irrespective of the Mode (Real/Test).
SMA(50) and SMA(200) also get updated with the result of every settled bet irrespective of the Mode (Real/Test).

The objective is that when System X is in a purple patch (model_balance trend is upwards) you are reaping the benefit because MFP will be in real mode = real money.
When the trend is downwards, MFP is in test mode, but still tracking System X's performance and you aren't losing real money.
When (if?) the trend reverses, you will switch back to Real mode.

Great in theory.......

Plot #1   - my first plot using the "noisy" model_balance.  Assumed a trigger that switched to Real Mode when the model_balance was > than SMA(200).
Plot #2    - assumes triggers which switch to Real Mode when Model_balance is > SMA(150) (really SMA(200)) and Test Mode otherwise
Plot #3    - assumes triggers which switch to Real Mode when SMA(50) is > SMA(150) (really SMA(200)) and Test Mode otherwise
Plot #4    - assumes triggers which switch to Real Mode when SMA(50) is > SMA(150) (really SMA(200)) and Test Mode otherwise
Plot #5    - assumes triggers which switch to Real Mode when Model_balance is > SMA(200) and Test Mode otherwise
   - in this particlular plot it would have been better to let the system run, but, hey, if only I had a crystal ball!
Plot #6   - assumes triggers which switch to Real Mode when model_balance > SMA(150) (really SMA(200)) and Test Mode otherwise
Plot #7   - Model_balance < SMA(200) = Test Mode, Real otherwise.  Also shows noise which could be taken out by introducing "hysterisis" in the trigger.
   - e.g. Switch to Test Mode if Model Balance < SMA(200).  Switch to Test Mode if Model_balance + 25 (or whatever) >= SMA(200).

FYI - Hysteresis - your central heating thermostat has hystersis.  The setting is an average.  It switches about the value =+/- 2C (or thereabouts) . Set to 20C, it will turn the heating on at 18C. 

When it reaches 22C, it turns off.  If it didn't do this, the thermostat would "chatter" in a small space.  So the hysteresis eliminates the chatter (noise).

Apologies again.

regards

Wez

I might start with adding the variables for the current balance and available funds, regardless of the mode, and the moving average for the balance. I will add this to our wish list.