Experts: Milestone - page 3
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Hi Trevor,
it seems to me that the "closeLargestLoss()" function is not doing that, instead it closes the smallest loss there is (by doing upward comparisons from minus a billion rather than downwards compare from 0). I do not know if that is intentional, and if so I would like to submit that while committing to a bigger loss with closing the largest loss trade, it would also free up margin and get the rest of the basket into profitability faster. I have not tested around this for mostly lack of time, but maybe you already did and therefore implemented it to work the way it does now?
Otherwise, btw., kudos!
Cheers,
Chris
Hi Trevor,
it seems to me that the "closeLargestLoss()" function is not doing that, instead it closes the smallest loss there is (by doing upward comparisons from minus a billion rather than downwards compare from 0). I do not know if that is intentional, and if so I would like to submit that while committing to a bigger loss with closing the largest loss trade, it would also free up margin and get the rest of the basket into profitability faster. I have not tested around this for mostly lack of time, but maybe you already did and therefore implemented it to work the way it does now?
Otherwise, btw., kudos!
Cheers,
Chris
Thanks Chris, my goodness you are absolutely right, please post your finds and I will implement. I appreciate the support thanks
void closeAll( string type = "none" ){
for( int i = 0; i < OrdersTotal(); i++ )
this closing of the trade does not work if U have more than 1 open trade. better use
for( cnt=OrdersTotal()-1;cnt>=0;cnt-- )
read this http://forum.mql4.com/29838 . or maybe U have another plan inside the AOS, and I can not see that.
in the other way is it interesing strategy, thanks for sharing. Im programmer and your code is really excelent for reading... :-)
if U can, we may discuss directly via skype, writte to me to junior@myweb.cz
Thanks very much, I will look into your solution you can pvt msg me here and through that I can share details. Regards
Thanks Chris, my goodness you are absolutely right, please post your finds and I will implement. I appreciate the support thanks
Trevor,
well, I did find a bit of time and turns out the problem is mostly academical, as I could not find a real-world circumstance in all of EURUSDs last three years where either implementations result is different from the other. The crux is that the function is called when account balance is already in the most direst of straights with the MinMarginLevel set to default, and since that boundary is usually reached when fast price changes occur with trend reversal quite a few pips away, I have found no instance when closing the largest loss would have made a difference except for prolonging the bust for a few ticks, maybe a bar. I have also checked where to set the MinMarginLevel to so this would make a difference and found two things: A static MinMarginLevel does not really lend itself well to fooling around with, as margin is dependent on number of open trades, and so it is hard to set meaningfully. A possible workaround to this could be a dynamic MinMarginLevel that protects a certain account balance. The second follows directly from the first: in order to have closeLargestLoss() make a difference, you'd have to set MinMarginLevel to something where it effectively prohibits trading. So in conclusion: academical, my finding was.
A dynamic MinMarginLevel could be implemented rather easily by calculating something like this:
MinMarginFactor would be the percentage of what you'd like to retain from you current balance, i.e. 0.5 for half of it etc. Other implementations that work kind of like a stoploss for your balance are easily conceivable as well. Here now closing the largest loss does indeed help, as it allows the underlying to peak a little further into the wrong direction (which is good obviously only if it ever does turn around) before further closing trades and therefore solidifying losses.
Cheers,
Chris
Thanks Chris, my goodness you are absolutely right, please post your finds and I will implement. I appreciate the support thanks
Trevor,
well, I did find a bit of time and turns out the problem is mostly academical, as I could not find a real-world circumstance in all of EURUSDs last three years where either implementations result is different from the other. The crux is that the function is called when account balance is already in the most direst of straights with the MinMarginLevel set to default, and since that boundary is usually reached when fast price changes occur with trend reversal quite a few pips away, I have found no instance when closing the largest loss would have made a difference except for prolonging the bust for a few ticks, maybe a bar. I have also checked where to set the MinMarginLevel to so this would make a difference and found two things: A static MinMarginLevel does not really lend itself well to fooling around with, as margin is dependent on number of open trades, and so it is hard to set meaningfully. A possible workaround to this could be a dynamic MinMarginLevel that protects a certain account balance. The second follows directly from the first: in order to have closeLargestLoss() make a difference, you'd have to set MinMarginLevel to something where it effectively prohibits trading. So in conclusion: academical, my finding was.
A dynamic MinMarginLevel could be implemented rather easily by calculating something like this:
MinMarginFactor would be the percentage of what you'd like to retain from you current balance, i.e. 0.5 for half of it etc. Other implementations that work kind of like a stoploss for your balance are easily conceivable as well. Here now closing the largest loss does indeed help, as it allows the underlying to peak a little further into the wrong direction (which is good obviously only if it ever does turn around) before further closing trades and therefore solidifying losses.
Cheers,
Chris
Chris, this is brilliant, basically what it entails is looking at the marginlevel in the negative space ( think of a black and white picture and the art teach says look at the negative space ). I like this, so instead of the EA using % of the margin it should reserve a % of the margin. yes?
Chris, this is brilliant, basically what it entails is looking at the marginlevel in the negative space ( think of a black and white picture and the art teach says look at the negative space ). I like this, so instead of the EA using % of the margin it should reserve a % of the margin. yes?
Again the idea in theory sounded better than any implementation I can so far come up with in real life. The EA will still primarily look at percentage of margin to use via the MarginUsage parameter, however it will allow existing open trades to dip only so far into the equity as to not forgo complete balance altogether.
As an example for the idea, look at these two graphs:
That is EURUSD at M5 from Jan 7 to Jan 10 this year. Each used the same parameters other than the MinMarginLevel, and used MarginUsage the way you wrote it to determine Lot Size. What you see is balance (green), MinMarginLevel, i.e. protected balance (red), current equity (black) and superimposed the current bid in bright red, all over time, here as number of bars. The first example behaved normally, came on the wrong side of a downward trend at around bar 442 and had opened so many buys by the time the EURUSD dipped below 1.30420 that it went bust when equity hit the account margin boundary, i.e. stopout occurred in the backtester. The second example behaved the same at first, and you can see the protected portion of assets following at half the account balance. Then, when the same situation occurs and the ea is caught wrong footed, equity reaches that protected boundary at around bar 484, which causes closing of the largest loss. That enables the EA to survive the trend until at bar 988 it can actually sell the basket with profit. A few bars later the whole account is already in profit again.
This situation however does still occur very rarely (as evidenced by the fact that I had to go back to January to find an occurrence). Most of the time, the boundary is reached time and again until, in effect, the account is bust as well. Against this you already have a mechanism, which is to reduce the MarginUsage parameter. I am hoping however that I can find an implementation that will enable greater reward by using higher MarginUsage parameter settings while protecting one's assets using this dynamic MinMarginLevel. I'll probably be tinkering around with this during the week, if results get better and you like I will share the code.
Sorry that so far the ideas I share are at best half assed.
Chris, this is brilliant, basically what it entails is looking at the marginlevel in the negative space ( think of a black and white picture and the art teach says look at the negative space ). I like this, so instead of the EA using % of the margin it should reserve a % of the margin. yes?
Again the idea in theory sounded better than any implementation I can so far come up with in real life. The EA will still primarily look at percentage of margin to use via the MarginUsage parameter, however it will allow existing open trades to dip only so far into the equity as to not forgo complete balance altogether.
As an example for the idea, look at these two graphs:
That is EURUSD at M5 from Jan 7 to Jan 10 this year. Each used the same parameters other than the MinMarginLevel, and used MarginUsage the way you wrote it to determine Lot Size. What you see is balance (green), MinMarginLevel, i.e. protected balance (red), current equity (black) and superimposed the current bid in bright red, all over time, here as number of bars. The first example behaved normally, came on the wrong side of a downward trend at around bar 442 and had opened so many buys by the time the EURUSD dipped below 1.30420 that it went bust when equity hit the account margin boundary, i.e. stopout occurred in the backtester. The second example behaved the same at first, and you can see the protected portion of assets following at half the account balance. Then, when the same situation occurs and the ea is caught wrong footed, equity reaches that protected boundary at around bar 484, which causes closing of the largest loss. That enables the EA to survive the trend until at bar 988 it can actually sell the basket with profit. A few bars later the whole account is already in profit again.
This situation however does still occur very rarely (as evidenced by the fact that I had to go back to January to find an occurrence). Most of the time, the boundary is reached time and again until, in effect, the account is bust as well. Against this you already have a mechanism, which is to reduce the MarginUsage parameter. I am hoping however that I can find an implementation that will enable greater reward by using higher MarginUsage parameter settings while protecting one's assets using this dynamic MinMarginLevel. I'll probably be tinkering around with this during the week, if results get better and you like I will share the code.
Sorry that so far the ideas I share are at best half assed.
Hi Chris, these are great studies, there are is so much to take into account when trying to protect margin. From my studies I believe the only way to successfully protect your margin is to open trades in the right direction. Not so easily done I know, the other alternative is to simply stop the trade and suffer the loss. I do believe that in suffering losses you too frequently through away valuable equity which could have been regained in that same trade of course this is the very reason why the account would go bust. Simply I do not know of a way to keep your margin level within reasonable limits apart from opening the correct trade so it is through this that I am on a mission to discover what makes a good opening trade. I have had some good results where determining the opening point by price alone and strictly no indicator to signal the entry point where a price signal will give you a precise entry and a indicator signal will always give you an averaged or lagging entry when most of the time you are seeking small profits the price entry is the only way. Thereafter you would need to stop the trade as soon as possible if it goes into loss. This is a great approach but then what happens when too many losses occur an your account ends up in loss overall? Well thats the next part I am working on, too take profits that are bigger than the losses when necessary you would need a better indicator signal and not price signal. Its all so paradoxy.
I get a really bad crash every time I do a back-test with default settings. I have uploaded my history files twice to make sure it is not bad data.
If there is a revision please send to colts4133 at gmail.com
I get a really bad crash every time I do a back-test with default settings. I have uploaded my history files twice to make sure it is not bad data.
If there is a revision please send to colts4133 at gmail.com
Hi,
Very nice EA, but could you please add a check so it will not add new positions at the same price? I do mean, if a Buy position exists at 1.6115 EA shoul not add new positions near it, it's margin wasting, nothing more.
Thanks.