Imagine a single bird in search of food, as it moves about over a landscape its nose will pick up the scent of food – the closer the food the stronger the scent. It knows where it registered the strongest scent so it will concentrate it’s search around that location i.e. slowing down and moving around more closely until it finds it. One bird on it’s own will take a long time to search a large area so now let’s imagine that two birds are searching and they can communicate with each other to notify where they have a strong scent – this will induce swarming as the other bird travels towards the stronger scent.

This is how the algorithm works, so the x and y coordinates in the landscape are the parameters to be optimised i.e. find the value that gives the strongest scent – the location of the food ! The birds change their velocities i.e. how quickly they move over those parameters to home in on stronger values so the birds will swarm around likely solutions. The ’scent’ is provided by a fitness function that basically takes the parameters (x, y) and returns a score.

module Main where

import System.Random
import Data.List (find, maximum)
import Data.Maybe

c1 = 2.0
c2 = 2.0
vMax = 5.0

-- infinite list of infinite random lists (TODO: Remove fixed seed 42)
rl :: [[Double]]
rl = [randomRs ((0.0), 1.0) g | g <- gl (mkStdGen 42)]
   where gl gen = gen:(gl (fst $ split gen)) 

-- Particle data type representing one particle
data Particle = Particle {
                  pbest :: [Double],           -- particle's best solution
                  pbestFitness :: Double,
                  velocities :: [Double],      -- particle's velocities
                  present :: [Double],         -- particle's present solution
                  fitness :: Double            -- current fitness
                  } deriving (Show)

cap :: Double -> Double
cap x | x < 0.0   = max x (-vMax)
      | otherwise = min x vMax    

-- Calculate the new velocities for a particle
calcVelocities :: Particle -> [Double] -> [Double] -> [Double]
calcVelocities p gbest rand = [ cap (v + c1 * r1 * (pb - pr) + c2 * r2 * (gb - pr))
                                    | v <- velocities p
                                    | pr <- present p
                                    | pb <- pbest p
                                    | gb <- gbest
                                    | r1 <- rand
                                    | r2 <- drop (length $ velocities p) rand]

-- Update a particle's present solution and velocities
updateParticle :: Particle -> [Double] -> [Double] -> Particle
updateParticle p gbest rands = p { present = [pr + v | pr <- present p
                                                     | v <- newVelocities ],
                                   velocities = newVelocities }
    where newVelocities = calcVelocities p gbest rands                                                                                                            

-- Find the best global solution in the population
getBest :: [Particle] -> [Double]
getBest p = if (isJust b) then pbest (fromJust b) else []
    where  b = find (\x -> pbestFitness x == m) p
           m = maximum [pbestFitness f | f <- p]

-- Return the next generation
psoEvolve :: [[Double]] -> [Particle] -> [Particle]
psoEvolve rands population = [updateParticle p gbest r | p <- pbests | r <- rands]
    where fitnesses = [p { fitness = fitnessFunction (present p) } | p <- population]
          pbests    = [if (fitness p > pbestFitness p) then
                          p { pbest = (present p), pbestFitness = fitness p }
                       else
                          p  | p <- fitnesses ]
          gbest     = getBest pbests         

-- Solve the problem using the ranges and fitness function
psoSolve :: [(Double, Double)] -> Int -> Int -> [Double]
psoSolve ranges numParticles numGenerations = getBest $ foldl (\a x -> psoEvolve (drop (2 + x) rl) a) pop [1..numGenerations]
    where pop = [Particle [] 0.0
                     (take l (head rl))
                     [(fst r) + x * ((snd r) - (fst r)) |r <- ranges |x <- (take l (rl !! 1))]
                     0.0 | n <- [1..numParticles]]
          l   = length ranges

-- Fitness function takes the particles 'present' solution and returns a score
fitnessFunction :: [Double] -> Double
fitnessFunction xs = (100.0 / sqrt (dx1 * dx1 + dy1 * dy1 + dz1 * dz1)) +
                     (50.0 / sqrt (dx2 * dx2 + dy2 * dy2 + dz2 * dz2))
    where dx1 = 53.4 - (xs !! 0)
          dy1 = 67.8 - (xs !! 1)
          dz1 = 32.6 - (xs !! 2)
          dx2 = 23.8 - (xs !! 0)
          dy2 = 18.0 - (xs !! 1)
          dz2 = 4.6 - (xs !! 2)

main = do
       print $ psoSolve [(0.0, 100.0), (0.0, 100.0), (0.0, 100.0)] 100 100 

The fitness function evaluates how close the particle (bird) is to two food sources in 3d space and returns the value. There is a large food source at (53.4, 67.8, 32.6) and a small food source at (23.8, 18.0, 4.6) so the optimum solution is the position of the large food source.

Here’s the result :-

[1 of 1] Compiling Main             ( /home/andrew/workspace/pso/src/Main.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
[53.422443402059535,67.83854324652401,32.637809690239244]
*Main>

Notice that it has found the large food source with an error rate of only around 0.03 on each axis i.e. 0.03 % this is with 100 particles and 100 generations so 10,000 evaluations of the fitness function. An exhaustive search would have had to to 1000 evaluations in each axis i.e. 0.1 increments = 1,000,000,000 evaluations ! Depending on the granularity of the exhaustive search, it could have easily misidentified the smaller food source as the optimum solution which PSO avoided.

As you can see PSO is a very efficient search algorithm that can be several orders of magnitude faster than an exhaustive search and, as can be seen, is relatively simple to implement and use over a very wide range of problem domains.

So how is it going to help me in my quest to produce profitable trading strategies ? Well there are several possibilities :-

• Use to optimise GP solutions, i.e. use GP to create the structure of the solutions but PSO to optimise the constants used in the structure,
• Use PSO to optimise the parameters used in the GP evolutions,
• Use PSO to optimise the parameters to hand coded strategies.

This seemed to offer an optimisation opportunity for my genetic programming library which currently evaluates both sides of a branch and then only passes forward the selected one since I haven’t implemented any kind of short circuit.

When I tried to implement lazy evaluation, I got a bit of a shock because not only did I get automatic short circuiting in any conditional branch but it also removed the need to allocate and deallocate transient constant nodes to store evaluated trees when doing strict evaluation. So it made the code simpler and the end was result was that evolution runs that were taking 4 days to run now take only 6 hours !

This was a lovely Christmas present, an order of magnitude efficiency increase that now makes more complex models possible to calculate. I never thought that learning Haskell would have such a direct positive influence on my C code.

I’ve been through the code looking to remove anything that is not essential and pre-compute as much data as possible so it doesn’t need doing in the main CPU intensive evolutionary generations. I’ve reduced the maximum syntax tree depth to 6 to limit the complexity of solutions and  therefore the processing time. I’ve filtered the training data set to exclude the quiet hours overnight when I don’t intend to trade but still it is taking far too long.

Then I discovered OpenMP – a standard for parallel processing in C that is supported by GCC. This means that by adding a simple pragma to my code in the main evaluation loop, the code will automatically run across all the CPU cores in my machine (only 2) giving an instant doubling of performance (almost) :-

 while (g < num_generations)

  {
     #pragma omp parallel for private(i, p)

     for (i=0; i<num_traders; i++)

     {

       p = evaluate_trader(&traders[i], 0);

       traders[i].profit = p;

     }

     sort_t(traders, 0, num_traders);

Notice the “#pragma omp parallel for”  ?  This splits the loop into two separate loops running in parallel in two separate threads on two cores. Since this loop has 256 iterations and no dependencies from one iteration to the next this is ideal for parallelism and could be split many more ways if I had more CPU’s / cores.

;; Candidate 1

  long entry  = (- (+ (* (min hour bar) -30) (vol (trunc bid))) (high (- (abs -40) (abs (* bar hour)))))
  long exit  = (- (close (min (abs (+ bar minute)) (* (abs (abs -2)) (if (< (trunc bid) (min -24 bar)) (trunc (low hour)) (+ (vol -7) hour))))) (min120 (min (* (vol (vol (vol 22))) (min (min bar (abs (* minute hour))) (trunc bid))) (- bar (trunc 0.137174)))))
  short entry  = (- (stoch (min (max (max (vol minute) (vol 15)) 37) 47)) (abs (max (trunc (stoch (max bar (vol 23)))) bar)))
  short exit  = (+ (abs (if (and (< 0.702188 bid) (> (+ (abs -39) (max 24 hour)) (trunc (ema60 (* -20 26))))) (+ (trunc 0.403593) (trunc (emalow5 hour))) (max minute (+ bar bar)))) (- (min (trunc ask) (if (and FALSE (= (- hour -32) minute)) 46 35)) (* 33 (if FALSE 0.482923 ask))))

;; Candidate 2
  long entry  = (double (max (vol (max minute 20)) bar))
  long exit  = (emahigh10 (max (trunc 0.859856) bar))
  short entry  = (stoch (+ (trunc (- (* 0.498268 (stoch minute)) (max bar (vol (+ hour 22))))) (if (< (* bar (- -30 minute)) (* (* (* 22 bar) (trunc 0.041836)) 48)) (* -17 54) (trunc (* bar (max120 (vol 32)))))))
  short exit  = (* (if (= (vol -27) hour) (max (max (if (> minute (vol 19)) 36 -6) (+ hour (min bar (- -9 hour)))) (max (vol 20) (trunc (ema20 (abs 16))))) bar) (sin 0.015177))

The profit is very modest for both at around 1000 pips for the year to the end of September.

Each algorithm (long entry, long exit, short entry and short exit) are used as signals to enter or exit long or short. If the algorithm returns a double value greater than zero it is used as a signal to proceed.

Looking at the 2nd candidate, it is essentially a shorting strategy based on the stochastic oscillator because long entry and long exit will always evaluate to a positive value meaning that any long trades entered (i.e. in the absence of a established short trade) will immediately be exited. This suggests that considerable improvement could be achieved by manually removing the long trading aspect.

It is fairly typical to get nonsense code in the results i.e. conditional code that always evaluates to one particular value because of the nature of the underlying data e.g. checking that a close value is greater than zero which clearly it always will be. I’ve been hand adjusting the winning algorithms before reusing them and I have an automated simplification stage in the processing that looks to remove pointless code where it can. Perhaps it could be reduced by reducing the maximum depth of algorithms. Currently maximum depth is set to 8 which means that you can have a maximum of 8 levels of nesting in the algorithm before shrink mutation is enforced. Perhaps reducing this to say 5 might reduce code bloat without compromising the solution quality – it would certainly speed up processing which is proving an issue again at the moment.

At first I suspected that my laptop had been hacked into and the hacker had killed my GP process because it was burning too much CPU and interfering with his spam mailing process. So I disconnected it from the internet and tried again but got the same results.

When I checked the /var/log/messages it turns out the process had been killed by ‘oom_killer’ which is a kernel process. It was killed for the simple reason that it had stolen all the system memory and was still demanding more i.e. it had a severe memory leak !

After doing some profiling with valgrind this turned out to be a missing free from the crossover function in my ast library. With this fixed, the runs continue.

Generation 511: Best = 4962.700000
  long entry  = (- (+ (* (min hour bar) -30) (vol (trunc bid))) (high (- (abs -40) (abs (* bar hour)))))
  long exit  = (- (close (min (abs (+ bar minute)) (* (abs (abs -2)) (if (< (trunc bid) (min -24 bar)) (trunc (low hour)) (+ (vol -7) hour))))) (min120 (min (* (vol (vol (vol 22))) (min (min bar (abs (* minute hour))) (trunc bid))) (- bar (trunc 0.137174)))))
  short entry  = (- (stoch (min (max (max (vol minute) (vol 15)) 37) 47)) (abs (max (trunc (stoch (max bar (vol 23)))) bar)))
  short exit  = (+ (abs (if (and (< 0.702188 bid) (> (+ (abs -39) (max 24 hour)) (trunc (ema60 (* -20 26))))) (+ (trunc 0.403593) (trunc (emalow5 hour))) (max minute (+ bar bar)))) (- (min (trunc ask) (if (and FALSE (= (- hour -32) minute)) 46 35)) (* 33 (if FALSE 0.482923 ask))))

Generation 389: Best = 3146.500000
  long entry  = (* (high (+ bar -17)) (/ (lower (min (trunc (/ minute (min120 -35))) (trunc (* (* 0.001833 (sin 0.789917)) 18)))) (/ (min (trunc (min120 (+ hour (+ hour 16)))) (vol 33)) (abs (trunc (- (max120 19) 0.677009))))))
  long exit  = (ema5 (trunc (emalow5 (max 20 30))))
  short entry  = (upper (if (< (min (abs (* hour bar)) (max hour bar)) (max minute (max -9 (+ (abs 17) bar)))) (if (and (> (emalow10 (* hour bar)) 0.000323) (< (double minute) (- 0.938433 0.677536))) (max (+ 25 -24) (abs minute)) bar) (abs (min (vol (- -25 39)) (max bar 6)))))
  short exit  = (emalow5 (if (and (> (min120 hour) 0.121671) (> (* (- 50 hour) (abs (+ 40 13))) (trunc ask))) (+ bar minute) bar))

As you can see, each solution has four algorithms long_entry, long_exit, short_entry and short_exit. Each of these returns a double which if greater than 0.0 is a signal to enter or exit the trade.

The ‘Best’ value is the number of pips profit over the training period which is three years so not massive. More disappointing when I tried each solution on two years data previously unseen, the first made a loss and the second made a very modest profit of around 1000 pips – a value that I would consider is not statistically significant and therefore not conclusive of success.

Uninspired by these results, I have modified the program to continue the mini-tournaments but after each it takes the winning algorithm and tests it on unseen data. If the algorithm shows a profit on the unseen validation data then it is carried forward otherwise it is discarded there and then. Hopefully this will ensure that all of the final competing algorithms have some potential to show repeatable profits.

At this stage my expectation of success is probably slightly less than 50%.

Even though I had reinstated the simplification process, the mutation scheme generally encourages increasing complexity over time because the mutation operators either keep the nodes the same size or increase them by replacing them with a more complex alternative. Unchecked this could lead to overfitting because the program will get more and more complex until it is ultimately a lookup table for the training data !

Another thing that I noticed was that the solutions weren’t particularly inspiring and relied pretty much on a buy and hold type strategy at the right levels – which would be pretty useless in any other data set since the levels would be different.

I took the decision to terminate the run early and make some changes :-

1. Introduce ’shrink’ mutation, this basically makes solutions smaller by replacing nodes with smaller alternatives. The method I used was ‘hoist’ mutation where you find a sub-node with the same type as the node you are replacing and hoist it up to replace the current node. This reduces the levels of nesting by one and also sheds all the adjacent branches. Additionally, I now monitor the overall depth of each program and, if it reaches a maximum threshold, growth mutation is prevented and only shrink or no change is permitted. Hopefully this restriction will encourage general solutions rather than over-complex and overfitted solutions. It also keeps the generational time down.
2. It occurred to me that perhaps I’m expecting too much to generate a decent strategy like trend following, retracements or breakouts by presenting such a huge mass of data. Maybe it’s not surprising that we end up with simple level based strategies that are naturally limited in their profit potential. To get around this I decided to slice the data into 100 separate slices of 1,000 rows each (around 4 days) and run an evolution on each slice. Then for the main evolution, I take the 100 separate winners and merge them with random programs to make up the  inital population for the complete data set. The theory here is that with less data, these individual evolutions should be able to come up with more specific strategies that might work on the data set as a whole i.e. learn small, try big.  Looking at the results from the individual slices, their average profitability was in the 400 – 600 pips range suggesting that on the complete data set an overall profitability of around 50,000 pips should be possible if any of the strategies can be translated onto the full data set.

So now I have a full run going that was seeded by the individual winners from the 100 slices and with maximum depth size limited to 8 levels.

I had previously disabled the simplification process as it contained a bug and thought maybe it was unnecessary. The process searches the syntax tree and removes any nodes that are a waste of time e.g. (+ 5.0 2.3) and replaces them with the result e.g. 7.3. During the mini run, I noticed that the generations were getting slower and slower because the syntax trees were getting more and more complex and often needlessly. Because of this, I reinstated the process which forced me to fix the bug.

So with this fixed and stop losses now implemented, the first serious run is now underway and should finish within 5 days. The terminal set now consists of :-

variable “bid” – current bid price
variable “ask” – current ask price
variable “bar” – current bar count
variable “hour” – current hour
variable “minute” – current minute
function “open” – candle open time series access e.g. (open 1) last open, (open 2) last but one etc.
function “close” – candle close time series access
function “low” – candle low time series access
function “high” – candle high time series access
function “vol” – volume time series access
function “sma5″ – 5 period simple moving average of close price
function “sma10″ – 10 period simple moving average
function “sma20″ – 20 period simple moving average
function “sma30″ – 30 period simple moving average
function “sma60″ – 60 period simple moving average
function “ema5″ – 5 period exponential moving average of close price
function “ema10″ – 10 period exponential moving average
function “ema20″ – 20 period exponential moving average
function “ema30″ – 30 period exponential moving average
function “ema60″ – 60 period exponential moving average
function “emahigh5″ – 5 period EMA of high price
function “emahigh10″ – 10 period EMA of high price
function “emalow5″ – 5 period EMA of low price
function “emalow10″ – 10 period EMA of low price
function “max60″ – highest price in last 60 periods (possible resistance level)
function “max120″ – highest price in last 120 periods (possible resistance level)
function “min60″- lowest price in last 60 periods (possible support level)
function “min120″ – lowest price in last 120 periods (possible support level)
function “upper” – upper Bollinger band
function “lower” – lower Bollinger band

I also enriched the terminal set to include a 20 period simple moving average (SMA) and upper and lower Bollinger Bands. I also spotted a feature where very risk averse algorithms i.e. those that never made any trades were doing rather well because their profit was £0 which is very good compared with the horrendous losses of the competitors which actually did trade. To discourage this risk averse behaviour, I changed the fitness function to penalise any algorithm that didn’t make any trades by giving it a profit of -£100,000.

With this I set a small run going over night with a small population of 128 and 128 generations to flush out any further errors.

The run was successful in that it flushed out a further error related to the type system – a mutation had created a function with the wrong type input. This should never happen so there is another bug in there somewhere. This error terminated the run.

The good news is that the run had completed 41 generations before the error occurred and produced a profitable algorithm ! It was a modest profit of only £10,000 (over two years and trading with 0.1 lots) but it was a very encouraging start. I would hope that with a larger population and longer runs that we should get a profit of around 10 times this.

The good news is that I’ve now implemented everything that I need in C to start my first run and performance is OK – I’ve estimated that each generation will take about 2 hours to process which isn’t bad for the estimated 2.4 billion invocations of the genetic programs per generation. So doing 100 generations will take around 4 days processing which is reasonable. Loading and pre-processing the large historic data file (600,000 rows) takes around 6 seconds compared with over 40 minutes for the Scheme code.

Now for the bad news – I’m getting random segmentation violations which is killing my program stone dead. I’ve been through the code many times over (albeit when I’m tired) checking and double checking everything but can’t see anything.  The first generation completes successfully so it looks like the memory corruption occurs during the mutation or simplification process.

Annoyingly, it doesn’t seg fault then as I’d be able to find this with the debugger, no it creates a problem that causes the seg fault later so the debuuger gives you no clues as to what caused the corruption.

Also annoyingly, it must be an extremely rare event because if I run with small populations and few generations there’s a good chance I won’t get a seg fault.

Now I long for Scheme and the pure functional approach to programming that makes this kind of problem impossible.