Metrics for the week ending on 4/01/11

These are the metrics for the end of this week.  As you can see, results are mixed.  MAFR 1/5/15 is the only one in the positive, although it ended the week basically flat.  I should mention that DMA 1/5/15 did improve by 79 pips over the week, although it still ended in negative territory.

On the hardware front, I should mention that I got all the new hardware I ordered, assembled it over the weekend, and put it to work this week.  Windows 7 did show some bizarre behavior with sporadically moving windows off the edge of the screen.  This made broadcasting somewhat tricky and annoying.  Notwithstanding that, however, the cycle time was severely reduced.  We no longer have the 800 second cycle times as before, as this i7 machine seems to handle everything I can throw at it easily.  Now that we no longer have that bottleneck, I was able to identify a new issue.  I noticed that on occasion the EAs would cease to run with a division by zero error.  This happened when the histogram chart, which shows the stats for the current state, was blank.  This means that there was no historical data collected for that specific state and caused the division by zero error.  I’ll be addressing this over the weekend, as well as making some additional improvements.

Advertisements

Metrics for the week

performance for the week of 11-03-25

This is the breakdown for the week for each EA tested.  Each trade was placed with 0.1 lots on the EURUSD, so $1=1pip and the gain/loss is shown on the y axis.  We ran with a back-history of 200,000 bars and each projection was 2,000 samples.  It appears that the clear winner for the week is MAFR 1/5/15, with DMA 1/30/60 in second place after a late week surge, but I should mention that we were plagued by technical problems all week.

The computer that was running these EAs this week simply cannot keep up with the workload.  The cycle time for the MAFR series was seen to be over 800 seconds at times, and seeing as we would like an update well within 60 seconds, this is simply unacceptable.  My old 4 GB RAM, 2.2 GHz Phenom X4 9550 is really starting to show its age, and we had frequent lockups and crashes.  The broadcasting software was especially troublesome, perhaps because all cores were at 100% utilization and there was no spare capacity to process the web stream.

I received most of the components for my new build, a 3.4 GHz Intel i7 2600 with 16GB of DDR3 RAM, but I’m still waiting on the aftermarket heatsink for the CPU, since I don’t trust the stock Intel cooler that came with the chip.  This machine can run 8 threads at once, so 4 simultaneous EAs and additional software should not pose a problem.  In addition, the faster RAM should increase the data retrieval rate significantly, and the larger RAM capacity should decrease paging to disk to a minimum, so i’m expecting some of the problems to go away.  If the cycle time is still excessive, though, i might have to cut back on the amount of history fed to the EAs and the number of samples.  I actually would like to increase both, since i don’t think enough data is being processed for really good stats as it is, but i may have to make some concessions.  Perhaps if I have time I may try to optimize the code some and see if there’s anything to gain there.

Quad test

Over the next few days I wanted to test the DMA against the MAFR versions.  You can see them streaming live by clicking the preview on the right.  There are two DMA versions on the left and two MAFR versions on the right.  The EAs on the top row are running on the 1 minute charts with 5 and 15 minute higher order timeframe references.  The bottom rows are also running on the 1 minute charts, but with 30m and 1h higher order timeframe references.

I’m also using the upper standard deviation as the TP, and the entry trigger is PN=0.2 (see mathematics).  I expect this setup to place many more trades, which should make it easier to gather data and calculate metrics.

Live streaming

This week we started broadcasting the live stream video feed of MCNP_EA V.dma.3.91. Version
3.91 is basically the same as 3.89, the only changes being cosmetic. We tried setting up a dedicated page on this blog, but wordpress does not like livestream embedded code for some reason. I had to post my livestream channel on vodpod, and used vodpod as a proxy. The video feed is available on the right above the twitter play-by-play.

You can now see three curves projecting out from the zero bar. The white curve corresponds to the mean opening price of all histories run during the latest projection. The blue and red curves correspond to +/- one standard deviation respectively. The EA is currently set up to enter a trade when the spread between the current open and the maximum (or minumum) mean is at least 40% of the spread between said mean and the minimum (or maximum) value of the standard deviation. In addition, the mean and standard deviation values are used to set the SL and TP, but if the mean curve ceases to point in the direction of the open trades, all open trades are closed. While variable position sizing was coded into the EA, we’re using a flat 0.1 lot size for the time being in order to get a simple assesment of accumulated pips.

The rationale for these settings as well as other mathematical observations will be discussed in a separate page at a later time.

Slow trading…

With the exception of one trade in December 2010, MCNP_EA V.mafr.3.64 has been very quiet. It appears that it is using extremely conservative settings and it’s proving to be as exciting as staring at the wall. I’m giving 3.64 a new roomate (MCNP_EA V.dma.3.89). This new variant is much more trigger-happy, and runs on the 1M scale as opposed to the 5M scale as 3.64. On the other hand, it runs close to real-time, so there’s no practical way to backtest it — especially since MT4 is not multithreaded so there is no simple way to make use of multi-core parallelization.

I removed some of the limitations that make 3.64 behave in a more prudent manner. At the same time, however, working on a smaller timescale should allow it to react to changing market conditions more swiftly. In addition, the two higher order reference timeframes used for statistical quantification are the 5m and 15m timeframes as setup. I’m also allowing it to cancel all open transactions the moment the bias turns the other way, as opposed to forcing either an SL or TP as was the case with 3.64.

All in all, I would expect this version to trade a lot more often. We will evaluate this for some time as a forward test and see how it goes.

First trade!

Well, it looks like after 2 weeks, MCNP_EA placed its first trade. It was a winning trade with a profit of $3,345 (or 0.6%). I know it doesn’t sound very impressive, but hopefully it’s starting to enter a more active period.

I should note that this is just an experiment at this point. Please do not use these signals to trade.

here we go

The last round of backtesting is complete and I’m starting the forward test with MCNP_EA V.mafr3.64. Everything has been set up, and we should start to see a feed at the right of this page. We’re starting the forward test on the EURUSD (5M). I should say, though, that based on the backtest, this EA could go days without trading. This might turn out to be about as exciting as watching paint dry…

almost there

Ok, we’re almost ready to start forward testing. I think the rest of my backtests should be done baking by thanksgiving. We’re tentatively setting the go live date for 12/1/2010. This should give me enough time to analyze the data, choose what I’m going forward with, and start the twitter broadcast.

Stay tuned…

[in the meantime, please take a look at]
Motivation behind the experiment
MCNP EA

%d bloggers like this: