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.