relative drawdawn and maximal drawdown in tester and optimizer are INCORRECTLY CALCULATED
relative drawdawn and maximal drawdown in tester and optimizer are INCORRECTLY CALCULATED.==false.
Ii is unbelievable to me how this bug has been around so long without anybody complaining? Yep, no one's complaining because there's no bug.
1) First of all, the proper way to calculate maximal drawdawn is the following:==false. If you're calculating that thing in de-init then you're calculating the Final_Profit/Losses and Ignoring the Floating_Profit/Losses. Here's how I calculated it and to my supprise it matched the Strategy-Tester Report [Relative_Drawdown] value.
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ void Get_EquityHigh(){if(AccountEquity()>EquityHigh){EquityHigh=AccountEquity();}} //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ void Get_Max_DDownX(){ if(OrdersTotal()>0){ double DrawDown$=EquityHigh-AccountEquity(); if(DrawDown$>0 && EquityHigh>0){ if((DrawDown$/EquityHigh)*100>Max_DDownX){ Max_DDownX=(DrawDown$/EquityHigh)*100; } } } } //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2) Also it is not clear to me what is the use of maximal drawdawn figure? I tried to explain Report Drawdown as best I understood it Here. And Here. I agree Absolute draw-down is not very important to me either. But sometime people just want to know how much down into their own money the losses dipped. Instead, I'd rather see the average draw-down.
3) If you will be correcting the calculation code, you might overlook also following situation. If you attempt to calculate equity-drawdown [not balance-drawdown] using History you'll run into allot of problems. The real-drawdown needs to be calculated on a tick-basis. Which means you'll have to cycle through every tick, sum the profit/loss of open and closed orders on every tick, and add that to a running total.
As a compromise, you could try using m1-OHLC & Open_Price for Null_Bar, but you'll lose some accuracy. Most people would just use Balance-Drawdown similar to what you've done.
Hi ubzen,
1) it seems that we have some misunderstanding in the concept of draw-dawn.
There is no such thing as "floating profit". That concept is completely missleading. You do not have a profit until you close the trade.
I cannot lose something i don't have. So the highest profit cannot be calculated based on "floating profit" but only on closed trades.
For loss it is also unsuitable to be calculated based on "floating loss", although there is a logic to calculate it in sense of a drawdawn.
When i enter a trade i take a risk. that risk is defined with SL and lot, and is calculated based on percentage of balance before entering the trade. It is not calculated based on "floating profit", but on balance.
When i am checking the drawdawn of a system i am using, I am not interested in what i might have in case that system was working differently, but what i get when i am letting the system run within its own rules.
2) In terms of money management and mathematical logic the absolute amount is completely irrelevant, and showing it and giving this value a importance, especially after increasing it in a manipulative ways by engaging non existing "floating profit" is not acceptable to me.
3) The problem is that within some systems you have to hedge the winning trade when an statistically important trend change probability happens. These entries have a low winning ratio but a great RRR, an thereby are generating a big drawdawn which should be treated differently as it is a hedge of a winning trade, but due to definitions in 1), it cannot be shown different but as a large drawback
4) After getting your response, i realize that my way of looking on things obviously differs from general perspective, so there is no need for discussing this further. Thanks for showing me the way things actually work.
Hello graziani,
4) I'm glad I could help. Only fair to respond to some of the points above. I'm not asking you to adopt my angle of looking at draw-down. I respect all opinions as they reflect the persons world-view.
1) When i enter a trade i take a risk. that risk is defined with SL and lot, and is calculated based on percentage of balance before entering the trade. Lets start here, that's a very bad idea. With all the noobs we have around here, gotta correct this statement. It's not about Balance but about Equity. Perhaps thats what you meant to say. One cannot calculate Equity correctly without considering Floating Profit/Losses.
Drawdown-In-Equity is the name of the game. Following your logic, someone with a No-Stop-Loss-System can claim that their system have No-Drawdown even when it's sitting 1-Tick away from 100% draw-down. These are the types of systems the scammers love promoting as 100% winning trades. Would you really call such a system a No-Draw-Down system?
2) ... especially after increasing it in a manipulative ways by engaging non existing "floating profit" is not acceptable to me... I'm not sure if you're referring to my example or meta-trader's use of Absolute Amounts. But in defense of both, I'll render Absolute Amount as Psychologically Logical for most Traders. Most people in the real-world want to know the maximum amount of money XYZ-system lost. While I care about Percentages, I can understand why someone else would wonder about absolute amounts [from a fixed point of view].
Lastly, you talk about money-management and mathematical as if your audience came crawling out-of noob-camp. It's starting to sound like one of those people who tells everyone else that unless their OrderStopLoss() is smaller then their OrderTakeProfit() they have no chance of winning Mathematically. <--All that have nothing to do with Money-Management. True Money-Management comes with Edge. And Edge is Not-Static in Trading because the Probabilities are Not-Static in Trading. Go-Figure.
hi ubzen,
i knew that this is not going to end easily :)
1) Regarding balance or equity .... the point is that you have to know what you are doing. I am using balance, as it is in harmony with the way i am looking at drawdawn and in harmony with the rest of my trading system: system itself, the winning %, maximum number of trades, risk, rrr etc.
I just checked out and verified, my main system is still working better when calculating risk in dependence of balance then equity. When i was designing it, i tested using equity, balance, free margin and balance reduced by risk already taken.
To put it simple, if in doubt, try and see what is working best for yourself.
2) well... i was not saying that, but nevermind. users have a choice.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hi to all,
as my last post lead to resolving the issue in later MT4 release, i will give another bug report & feature request.
Ii is unbelievable to me how this bug has been around so long without anybody complaining?
As stated in subject relative drawdawn and maximal drawdown in tester and optimizer are INCORRECTLY CALCULATED
1) First of all, the proper way to calculate maximal drawdawn is the following:
for (int i = 0; i<OrdersHistoryTotal(); i++)
{
.......
if (startBalance + profitBuy + profitSell > profitHigh)
profitHigh = startBalance+profitBuy+profitSell;
else
if ((1 - (startBalance+profitBuy+profitSell)/profitHigh) > relDrawDown)
relDrawDown = (1 - (startBalance+profitBuy+profitSell)/profitHigh);
}
This is the way i am calculating it in my deinit routine. i don't know how you get the number in reports, but they have nothing to do with real data.
2) Also it is not clear to me what is the use of maximal drawdawn figure? This figure in its absolute value gives no information as it has to be looked with respect to the maximum high wich happend prior to the drawdawn. Instead it would be MUCH BETTER to have the 2nd GREATEST DRAWDAWN!
3) If you will be correcting the calculation code, you might overlook also following situation: if EA is buying and selling simultaneously, the winning open trade (one which is not finished) should be added to the balance compared to avoid false drawdawn.