Bob and Shelley Again

[fxozgirl]

Just a heads up for anyone following my demo's, Jeremy has posted here
http://www.stevehopwoodforex.com/phpBB3 ... 468#p76468

that the new Global Prime servers are ready and will be rolled out ready for trading next Monday. This means all current demo's will be turned off over the weekend, so I will be setting up new BASA demo's over the next few days.

Given this server change also incorporates a GMT change, I strongly recommend anyone trading BASA on a live GP account, remove it and demo test on the new platform until you are satisfied it works as expected.

[SteveHopwood]

After last weeks awesome run, we are now in a retrace which has cost us a few trades...
If you are trading with the protection of MA stack turned on, this should have kept you safe from BASA taking some trades where the retrace is still not completed.
If you have MA stack turned off...then you've probably given back some of last weeks gains!

On demo, got it turned on for stacking and off for main trades. Given back a bit but not so much that I care.

Live, always had it turned on for stacking and off for main trades. I have a couple of open trades that are not going far.

Not that it matters. When a pair goes off on one, this EA makes those who worry about intervening tiny losses look silly.

You have created a jem here, Shelley.

[fxozgirl]

After last weeks awesome run, we are now in a retrace which has cost us a few trades...
If you are trading with the protection of MA stack turned on, this should have kept you safe from BASA taking some trades where the retrace is still not completed.
If you have MA stack turned off...then you've probably given back some of last weeks gains!

On demo, got it turned on for stacking and off for main trades. Given back a bit but not so much that I care.

Live, always had it turned on for stacking and off for main trades. I have a couple of open trades that are not going far.

Not that it matters. When a pair goes off on one, this EA makes those who worry about intervening tiny losses look silly.

You have created a jem here, Shelley.

My results are pretty similar to yours Steve...looks like there's a few setups coming tonight

[SteveHopwood]

Time to put your thinking caps on guys. There is something wrong with the stack basket trailing stop.

Over in the Different Sort of BASA thread, Tom reported the position closing soon after the first stack trade being sent. I saw why tonight. On my live Cowboy IBFX play account, GCad saw a stack trade. The basket trailing stop was so tight that it was bound to be hit quickly, and it was - 10 minutes after sending the stack trade.

I need help here guys. To put it baldly, any tit can code Crapql4. It is what to code that causes the bother (AKA 'the algorithm'). Anyone with any helpful ideas feel free to dig into the code and see if you can come up with something better. My version works fine with a basket of four or five trades; it is rubbish with two.

[fxozgirl]

Time to put your thinking caps on guys. There is something wrong with the stack basket trailing stop.

Over in the Different Sort of BASA thread, Tom reported the position closing soon after the first stack trade being sent. I saw why tonight. On my live Cowboy Cowboy IBFX play account, GCad saw a stack trade. The basket trailing stop was so tight that it was bound to be hit quickly, and it was - 10 minutes after sending the stack trade.

I need help here guys. To put it baldly, any tit can code Crapql4. It is what to code that causes the bother (AKA 'the algorithm'). Anyone with any helpful ideas feel free to dig into the code and see if you can come up with something better. My version works fine with a basket of four or five trades; it is rubbish with two.

Hmmm...I haven't had any stack trades this week yet (I have slope turned on & it kept the stack trades out for gbpcad), but I will watch & see if I can come up with anything helpful.

[kwanann]

Time to put your thinking caps on guys. There is something wrong with the stack basket trailing stop.

Over in the Different Sort of BASA thread, Tom reported the position closing soon after the first stack trade being sent. I saw why tonight. On my live Cowboy Cowboy IBFX play account, GCad saw a stack trade. The basket trailing stop was so tight that it was bound to be hit quickly, and it was - 10 minutes after sending the stack trade.

I need help here guys. To put it baldly, any tit can code Crapql4. It is what to code that causes the bother (AKA 'the algorithm'). Anyone with any helpful ideas feel free to dig into the code and see if you can come up with something better. My version works fine with a basket of four or five trades; it is rubbish with two.

Hmm possible to show a picture or the trade history?

[SteveHopwood]

I just received this pm from Tommaso:

Hi Steve,

should it not be if (Bid - LinePrice > ((StackTrailingStop * OpenTrades) / factor))
just a suggestion

Tommaso

Great one Tommaso and I think you are correct. Thanks. It needs to be:
if (Bid - LinePrice > ((StackTrailingStop * (OpenTrades - 1)) / factor)) but I am not turning my coding machine on again tonight - had a couple of drinkies and these never mix with coding.

I will post a fix in my morning. In the meantime, those of you who can (and if you cannot, then learn how to) go to void StackTrailingStop()

Find the six instances of:
StackTrailingStop / OpenTrades) / factor

Change them all to:
StackTrailingStop * OpenTrades) / factor

and recompile. Also do this with the Different BASA if you are testing it. Leave the brackets alone.

If you are feeling adventurous, change them to:
StackTrailingStop * (OpenTrades - 1)) / factor

I will post the full fix tomorrow.

[SteveHopwood]

V 1x is in post 1, with the full fix I described last night.

[SteveHopwood]

I noticed something when loading 1x onto my trading machine.

I have the variable StackTrailingStop and the function void StackTrailingStop(). It does not appear to make any difference but it is a bad practice to have a variable and a function with the same name. I have added a quick change to this in the version in post 1.

[fxozgirl]

V 1x is in post 1, with the full fix I described last night.

Thanks Steve

Just looking at this weeks retrace, and with some trades hitting the full stop loss, it reminded me of a PM Dave (spotdespot) sent me a few weeks with a suggestion to try and minimise the losses incurred by trades taken that pretty much go immediately in the wrong direction.

See below a partial quote from Dave's PM:

For the "Main" trades the entries are pretty good imo but there are obviously times when the timing isn't so great and the trend stops and either changes or we enter a ranging phase for a while e.g.
08.09.2013 04:00 AUDJPY,
08.09.2013 00:00 GBPNZD,
08.08.2013 08:00 AUDCHF

I believe you should save significant pips if you introduce a rule whereby the trade should close if (for a sell) the H4 entry candle closes higher than the entry (open) price AND the following candle also closes higher than its open price (and vice-verse for buys).

If you take a look at the trades taken you would have saved a significant number of pips on the "Main" trades where price just went the wrong way and I do not believe it would have cost you any winners. It doesn't catch every "bad" trade and I am sure there will be circumstances where it will stop a would be winner but running through the trade history available it looks like a simple and very easy way to reduce average loss size fairly dramatically

Looking back at this weeks trades that went straight to SL (ie. neither of the first 2 candles once the trade was taken closed in the direction of the trade) we would have saved 312 pips:

CadJpy -100 / -29
GbpAud -100 / -32
AudUsd -100 / -33
NzdJpy -100 / -66
GbpJpy -100 / -28

So with that in mind, is Dave's suggestion able to be incorporated into the EA for both main & re-entry trades as some extra protection without affecting the existing money management features?