Flying Slope auto-trading EA

[SteveHopwood]

dear Steve,

FS just failed on me :[
As you can see from the screenshot lot size specified is 0.01. At 16.00 5 trades opened, 4 as specified at 0.01 and CHF/JPY at 4.60 Lot! I had MPTM set at 75$ loss which has closed all the trades next second.

Any ideas where 4.60 lot come from? :/
thank you,

Not a clue. What was your approx balance at the time?

[spymez]

Version 1h is in post 1.

Trundling around the code looking for possible causes of the cpu thingy, I noticed a few bloops in the stack trading function. They will not solve the cpu thingy, but might help the stack thingy. Anyone had any stack trades yet? I haven't and cannot work out what is wrong in the code.

After trades have been opened(see att.pic),before 10%.Making exchange v1d v1h.
Thanks.
P.No improvement with CPU after exchange..

No improvement with v1h.

2 positions open with 25% CPU usage.

dumbfounded.

Regards

Spy

[monkeh]

Not a clue. What was your approx balance at the time?

=3500,
risk percent was set to 0.

all the trades before were ok, though these were the first related to JPY, on the other hand E/J opened correctly.
sigh

[KingOfCoolville]

Steve,

Just to let you know I am experiencing the same CPU load issue as others.

I am running version 1g.

As a previous poster pointed out the EA is fine until it takes a trade, at which point the CPU jumps to >95% usage.

[garyfritz]

Steve, I've only glanced through the code so I'm just guessing, but... the only part that I see that's different when trades are open, is that you call LookForStackTradingOpps(). There's not much in there, just set a few flags, then you call CalculateLotSize() (which is pretty minor) and you delete/create some objects.

I don't know how expensive it is to create/delete objects. Is it possible all that CPU time is getting eaten up by creating/deleting those objects on every tick??

Both of those steps are based on the value of price, which should change very seldom. How about you save the previous value of price, and only calculate lot size & delete/recreate the object if price CHANGES?

[SteveHopwood]

Steve, I've only glanced through the code so I'm just guessing, but... the only part that I see that's different when trades are open, is that you call LookForStackTradingOpps(). There's not much in there, just set a few flags, then you call CalculateLotSize() (which is pretty minor) and you delete/create some objects.

I don't know how expensive it is to create/delete objects. Is it possible all that CPU time is getting eaten up by creating/deleting those objects on every tick??

Both of those steps are based on the value of price, which should change very seldom. How about you save the previous value of price, and only calculate lot size & delete/recreate the object if price CHANGES?

Not a clue Gary. Also, I am not experiencing a problem here but I have a modern machine with lots of memory. Not that that should matter because, as you say there is not much in the stack trade function.

Also, I am running this live along with 5 other demo accounts running other ea's including BJS, which takes the occasional snatch at the memory - and then I will run Firefox to read contributions here because my new machine is miles faster than my coding machine and then will do a bit of coding in situe. I am not having a problem with cpu thingies.

Of course, just because I am not having a problem does not mean it does not exist. Fact is, I am not too bothered. Too many times before now, I have been down the line of chasing faults only to find that that it is something on the other individual's setup that is causing the problem; I am not spending any more time on this. There are some pretty fantastic coders here - and we are talking not only pro guys like you but guys who also understand the lethal mix of Empty4 and CrapMql4. If they cannot see what is wrong, and it isn't a problem for me, then it is hard to see what I can do.

Sorry guys. I am a tad helpless here. As I often repeat, it is quite hard to correct a fault that does not appear on one of my demos.

One tiny idea; make sure you compile the ea under the auspices of your version of Empty4. Sometimes this makes a difference. If you do not know how to do this, then I am sorry but you fail to meet one of the preconditions I set out in every one of my EA thread post 1's. I leave you to work out for yourselves which one that is.

[SteveHopwood]

Another thought guys, and no idea if it makes any difference to the cpu thingy - cannot see how it would.

In light of monkeh's earlier post about the aberrant lot size, and bearing in mind that I am now trading this ea on my live account, I rushed through and instantly deleted all reference to risk-based lot sizing, just in case some strange leakage led to the strange behaviour.

Risk-based lot sizing will be removed from all future releases of FS and my shell code. I have never understood this strange obsession that some traders have with risk-based lot sizing unless the reward thingy also reflects this, and it hardly ever even gains a mention. Insane.

So, anyone else want the updated FS sans RiskPercent? Bear in mind that there will be no going back once you have the updated bot.

[garyfritz]

If risk-based sizing means "calculate the lot size that, given my current SL, would risk X% of my account," then that's the way I **ALWAYS** trade with real money. That's how you implement basic position-sizing strategies like fixed-fractional sizing. If it wasn't supported in an EA, I'd try to fake it with manually-specified lotsizes, but that only works if you know the SL ahead of time.

Not a clue Gary. Also, I am not experiencing a problem here but I have a modern machine with lots of memory.

OK, then I wouldn't see it either.

If anybody who's hitting this CPU issue wants to try an experiment: try the attached. I changed it to only delete/recreate the objects if the price changes. I also completely removed the SendLots calculation, since it's a local variable and it never gets accessed after it's calculated. (Steve, am I missing something there??)

No promises since I can't test it, but see if it helps... (and if it works!!)

[fxshadow]

Gary,
Could you take a quick look at the balance and swap filters to see if you see any cpu hogs. I know they've never been an issue before.

[garyfritz]

I don't see anything there. I think those only apply when you're looking to enter a position, not when you're in a position. They wouldn't be different when you've got an open positions.

The only thing I see that's different when you're IN a position is the code in LookForStackTradingOpps(). I really don't think that's it either -- I'm not convinced that object-creation code gets called every tick but I'm not sure -- but it's the only candidate I see. If it DOES get called every tick, drawing and erasing that line on every tick could easily eat up some CPU.