- This topic has 169 replies, 16 voices, and was last updated 9 years, 9 months ago by
.
- Posts
Adding Commission distort the whole TRAILING process in MT4, since it is not included in the trailing calculation (besides the fact that the logic isn’t finished yet). To simulate commission you should add it to the spread and multiply it by the lot size. G.
Thanks for commission information G
Hi Brother, zero divide should involving division operation, while in your code example this is multiplication operation, so the result could be zero but not zero divide error. From my noob perspective, before that line of code you could make sure by ‘if’ condition like;
if ( (High - Low) != 0.0 )to protect zero result condition Hope it help and best regards MTHThanks brother. I just think like this :
MathPow(High – Low, -1)
does it means same as :
1 / (High – Low)
So, it is actually a division operation … if i am not wrong …
but i could be wrong though …Yep, this is obviously true:
From my noob perspective, before that line of code you could make sure by ‘if’ condition like if ( (High – Low) != 0.0 ) to protect zero result condition
IMO, the really interesting question is: how does the else if branch look like? You can exclude division by zero easily by some standard code, but you’ll have to make an individual decision what should be done after the case happened.
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
Hi. My first post here. This development seems promising. But the backtest, 35 trades over 5.5 years. Are you sure? Here is backtest on the latest v1.3 ———————————————– – Default settings – Start account $10.000 – 99% Dukascopy tickdata from 2010-01-01 – Real spread – $7 commission – Backtest made with TickDataSuite ———————————————–
Welcome mate. I haven’t tested v 1.3 yet (will test it soon), but as you know some other features are not implemented yet in this version . But looking at your result (although it is still getting some loss), yes it is promissing. I am sure after all requirements are fullfill (peak trough, osc, trend, etc), we will see a much better result. Try to give your ideas, cide snippets, or other thing you feel should be usefull in this development. One question: Did you test it on big TF like D1 or W1?
Hi. My backtests was on H4. I can post D1 and W1 if they are of interest. I will remove the added commission as gg53 recommended. It is the real spread of Ducascopy in the backtests so if you are on a good ecn broker you already have a bit lower spread than with Ducascopy.
Hi. My first post here. This development seems promising. But the backtest, 35 trades over 5.5 years. Are you sure? Here is backtest on the latest v1.3 ———————————————– – Default settings – Start account $10.000 – 99% Dukascopy tickdata from 2010-01-01 – Real spread – $7 commission – Backtest made with TickDataSuite ———————————————–
Welcome mate. I haven’t tested v 1.3 yet (will test it soon), but as you know some other features are not implemented yet in this version . But looking at your result (although it is still getting some loss), yes it is promissing. I am sure after all requirements are fullfill (peak trough, osc, trend, etc), we will see a much better result. Try to give your ideas, cide snippets, or other thing you feel should be usefull in this development. One question: Did you test it on big TF like D1 or W1?
Hi. My backtests was on H4. I can post D1 and W1 if they are of interest. I will remove the added commission as gg53 recommended. It is the real spread of Ducascopy in the backtests so if you are on a good ecn broker you already have a bit lower spread than with Ducascopy.
What’s the purpose of this ?!?!
The logic is not completed yet, as well as the pre-trading conditions…
How was the initial version?
How often do you clear “long-ago” pending trades?
I really don’t understand this “test”… or its purpose…
G.
Yep, this is obviously true:
IMO, the really interesting question is: how does the else if branch look like? You can exclude division by zero easily by some standard code, but you’ll have to make an individual decision what should be done after the case happened. s.
Yes, you are right simplex. So, if High==Low, it means there is no Volume, right ? So, we just don’t care about this candle …. or we take the previous one ? Any idea ?
Yep, this is obviously true: IMO, the really interesting question is: how does the else if branch look like? You can exclude division by zero easily by some standard code, but you’ll have to make an individual decision what should be done after the case happened. s.
Yes, you are right simplex. So, if High==Low, it means there is no Volume, right ? So, we just don’t care about this candle …. or we take the previous one ? Any idea ?
Maybe,
else V = EMPTY_VALUE;at first second of every candles in every TFs mostly, Open = Close = High = Low with Volume = 0, So, ‘V’ should be ‘Empty’ first, before the loop change ‘her’ value later.. if High-Low != 0.0.
Just my noob cent.. lol
MTH
Intuition, Experiences and Common sense..
http://www.binaryoptionsedge.com/Ok, let’s talk about News Calendar Integration a bit. Since I haven’t seen the code Emonts mentioned in his latest post yet, I continued to work through Derk Wehlers FFCal solution to get a grip on that one. I found one interesting comment in his code which I’d like to discuss here:
Set AllowWebUpdates to false when using in another EA or Chart, so that the multiple instances of the indicator don’t fight with each other!
When we load more than one EA and / or indicator using our calendar solution (whichever it will be) these different instances will possibly ‘fight’ for exclusive access to file resources. This can possibly lead to runtime errors or text files being jammed. @emonts: is your solution safe against this? Since I don’t like the idea of running several instances and having to exclude such errors by manually setting a certain input parameter, I’m considering technical measures to exclude this case automatically:
- using text file naming conventions that ensure each instance to download its own calendar resource file (might lead to an inflationary number of downloaded files)
- implementing file read / write algorithms that are robust against file sharing conflicts (didn’t check the code for that yet)
- ensure that only one calendar instance can be started at the same time
- ensure that several calendar instances can be started, but only the first one will be granted write access to the text files. All following ones will check that a ‘master’ instance is already active updating the calendar files, switching automatically to ‘slave’ mode, only reading those files.
- considering a different architecture of our solution: load only one news indicator which has access to the internet resources and updates calendar files. AFAIK, each new iCustom() call would load a new and possibly concurring instance, so this might be error prone, too. Hence it might make sense to think about a different way to pass information from that calendar indicator to our EA. Global variables of terminal-wide scope are limited to the double type, so we can’t pass the text information using those. A number of minutes as well as impact strength could be passed. The EA then would only read those globals, without touching the text files or attaching the calendar web resources.
Derk Wehler’s approach was to partially implement solution 1 (error prone). I think solution 4 is the most promising one. What’s your opinion about this? Alternate approaches? Pro’s and Con’s? s.
1. Each instance act as a stand-alone and try to fetch the CAL file. If file already exist, the instance returns. File fetching is done on Daily basis.
2. Daily RELEVANT CAL file (only EUR & USD events loaded in case of EURUSD EA) is loaded into memory with unique name (i.e. EURUSD_CAL_DDMMYY).
3. EA instance access that memory file.
That’s my implementation, after much CPU and Memory problems with other solutions.
G.
Hi
Could someone create a MTF version of ClearMethod indi? (I had tried but fail, the MT4 just hang.. )
I don’t know it is useful or not.. need @gg53 comment on this..
IMHO.. this indi give ‘better information’ on higher time frame..
Regards
tankhang
I have it:
Could someone create a MTF version of ClearMethod indi?
Will post it later after some code cleaning.
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
Here you are:
Could someone create a MTF version of ClearMethod indi?
Place mqh file in the include folder.
Have fun testing, and any feedback welcome!
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
Adaptive Take Profit
I’m referring to @gg53 proposal posted here and here. At the moment, I won’t present the final solution as demanded in his 2nd post, rather take a step back and post an experimental indicator that shows 3 different implementations of his basic Adaptive TP proposal for further conceptual discussion.
The implementations are coded as functions, yet for EA use these will have to be modified slightly, then working related to a given entry price and modifying the actual TP.
Note that the indicator by default does not show the absolute price delta to determine a TP. It shows the factor the ATR will be multiplied with. If you prefer price deltas to be shown, just change code line 19 to
#define AD_TP_OUTPUT_ATR trueand recompile.- Light grey line: this one is simply switching between 3 given factors, depending on the slope of the ADX Main and a given threshold.
- Blue line: we’re considering a base factor of 1.5 when slope of ADX main is flat. For a slope greater than zero, the factor will increase, for slope smaller than zero, it will decrease.
- Red line: essentially the same as blue, during a phase of continuous rising or falling of ADX Main, a once achieved maximum / minimum value will be held.
Discussion:
IMO, grey is too coarse. Red is too slow while returning back from a high level back to normal, especially after a reversal. Blue seems to work nicely, but tends to be a bit sloppy when a certain trend / swing has some major pullbacks.
The red approach was meant to overcome this sloppiness.
Another idea to overcome this issue might be to recode the ADX, replacing the EMA that defines the Main Line by a more modern approach like a modified Ehlers Supersmoother.
Basically, G.’s default suggestion of ADX period = 108 seems to be too high to react effectively after reversals. On the other hand, reducing it will enhance sloppiness.
Any feedback, ideas, and mods of my approach much appreciated!
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
The main idea is to push the TP forward as we are getting close to it, or reduce the TP if we approch trendiness end signal.
G.
The main idea is to push the TP forward
This is what my ‘red’ and ‘blue’ approach are doing, based on default setting according to your proposal.
reduce the TP if we approch trendiness end signal
IMO, this would require a trigger coming from outside (the EA) telling our TP function that a trend /swing is ending. Otherwise the Adaptive TP function might interfere with trend / swing definition made by the EA.
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
The main idea is to push the TP forward
This is what my ‘red’ and ‘blue’ approach are doing, based on default setting according to your proposal.
reduce the TP if we approch trendiness end signal
IMO, this would require a trigger coming from outside (the EA) telling our TP function that a trend /swing is ending. Otherwise the Adaptive TP function might interfere with trend / swing definition made by the EA. s.
My idea of implementing this is the same way as the TrailingStop is implemented.
Both deal with the same functionality of OrderModify(…).
G.
A useful little tool to view MT4 logfiles
When debugging my Dynamic TP prototype (which seems to be working now
) I had to study the MT4 Tester logfiles very intensely at a very detailed level. Most of you will know the problem that the logfiles are ‘presented’ by MT4 in a horrible way (1st pic). So it is not surprising that some of us are getting more and more trouble with their eyes.That’s why I prefer to look at those logfiles with my preferred text editor (I also use it for coding). It’s Notepad ++. Even in plain view, NPP is an improvement as compared to MT4 view (2nd pic).
But like all good coding editors, NPP can be user configured easily to match display requirements for any programming language. So I quickly (about 10 minutes) defined a ‘language definition’ that matches the output of MT4 tester output, with a special modification to meet the needs of our Penguin EA (3rd pic). I think in this view, you can really dig in the details of a logfile for debugging and enhancing your strategies.
And if you need a certain additional keyword (like IsPeakTroughChange) just temporarily: this was added in 5 seconds (4th pic) and removed again in 3 seconds.
If anybody is interested, I’d happily share how it’s done.
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
Hi Simplex,
I reply to your post here, as I think this one point is more of technical nature than trading logic.
“…In case you wanted a BE logic, but no partial close, you would have to call the partial close function anyway…”
MoveStopLossToBreakEven() is a separate function, so you can call it without calling PartialClose function.
But I understand your point, ‘moving sl to be’ and ‘partial closing’ are separate actions and one shouldn’t call the other one and they both should be called from OnTick(). That was my intention in the beginning also but then my coding ability hit reality :)
I couldn’t figure out an elegant solution for closing part of an order just once. As long as the order was in required profit, on the next tick, another part of the position was closed and so on until there was no position left. Another factor that complicates things when using OrderClose() to close just a part of the lots of the entire position, is the mt4 will close the actual position ticket(number) as whole, and create another position ticket(number) with the remaining lots. So the ticket number of the ‘same’ position changes.
Putting it together with the MoveSlToBe event ensured that each order is partial closed only once. So I made it one event. And since this kind of implementation didn’t interfere with requested trading logic, I decided to go this way.
If you have came across this problem before and/or have a nice solution, feel free to post it.
Regarding WIP, I added commission to be taken into account inside trailing function and when setting BE.
The last point from GG53 pre-conditions is the News filter. With this one I’m waiting on Emonts to send me the final code of the NewsInc library.V.
Hi @VlanFx,
Thanks for your answer! Ok, got your thoughts about partial close and changing ticket number. Until now, I didn’t bother about partial close too much, so I don’t have a solution right on my desk.
So just let me think: how many trades of one pair do we allow to be open at a time? One or more? And do we allow hedging?
If we’re considering the most simple answer (max. one trade per pair) we just have to store (in a global or static variable) that partial close has occured and reset this variable once the trade has been totally closed.
If we allow more than one trade (pyramiding or hedging) we have to carefully monitor our trades: defining a custom structure as a global array might be a good choice. So after every partial close, we would have to check all open trades and compare with already stored trades, if there’s a new ticket number, and then add this one to our trade inventory and mark it as ‘already partially closed’. The old ticket number is no longer active and has to be deactivated in our inventory. Similar logic would be applied to all other trading actions.
I can’t say that I like this solution, but when done properly, it should work.
A different approach may be to answer the question ‘How many lots of one pair do we allow to be opened at the same time in active trades?’ If we allow more than one trade per pair, and their total lots are smaller than the maximum value (defined as an input or determined by market conditions), then we would not close partially. Why should we care about partial close of a single trade if we’re having more than one trade of a symbol open? I think in this case we should look at those trades as an entity and consider what to do with this one-pair-basket as a whole.
To start with, I would prefer the ‘one trade per pair’ approach to keep things simple. Once this version is working, we can consider to refine our strategy regarding trade management.
When should a partial close be done? I would only consider this when a 50 % partial close will cash in my risk, that means if my initial stop loss (in ATR multiples) is reached as a profit. Your partial close jumps in much earlier, just one point above / below BE. So it gives away a good part of potential profit without cashing in my total risk.
I would consider Dynamic TP and Trailing Stop incl. BE logic the top priority. If this works, I would put a partial close logic on top.
And it’s important to take care of pending trades once one of them has been triggered.
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
I thought a bit more about your statement:
But I understand your point, ‘moving sl to be’ and ‘partial closing’ are separate actions and one shouldn’t call the other one and they both should be called from OnTick().
It’s not that bad to combine ‘moving sl to be’ and ‘partial closing’ in one function. In the end, both functions are two faces of one coin: trying to take all nominal risk from a certain trade once a specific level of profit is reached.
The following rule was a major problem when backtesting my DynTP:
input double PartialTP = 5; //Partial TP in pips. Must be smaller than TrailingStop
This leads to BE function getting active much too early. So I had to disable your partial TP function.
It does not make sense to develop BE, partial close, trailing stop, and dynamic TP apart from each other. They should follow a consolidated design. So I coded my DynTP very closely to your TS function. Now BE and partial close have to be modified to make the whole thing work properly.
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
Hi @simplex
Yes, there are several ways to do this, but can not say I really like either of them:
– keeping track of partially closed orders in some kind of list as you suggested. Here I would suggest using out-of-ea storage place so the ea can continue to work even after ea/mt4/windows restart.
– using order comment to store order’s initial lots and then compare it to OrderLots() to see if they match. This would allow for only one partial close per order (do we need more?). Also, some borkers replace order comment fields so it may not work for everybody.
– instead of partial closing, we can do ‘partial opening’. Place two or more orders at the same time and direction with different lots and different TPs.
The 5 pips that I used as default value for partial TP was taken from @GG53 post here. I know he said “If our tests confirms”… So maybe he didn’t mean to use exactly those numbers, but rather he meant it as a suggestion for us to find what TP has very high probability to be reached and use that to cover part of a position.
I think now we should decide on the PartialTP logic and implement it. Then, together with your DynamicTP function and @Emonts news library the skeleton EA should be ready for trading logic.
V.
Hi @VlanFx
As I wrote in this post I believe that the greatest problem to get DynTP working together with partial close is the rule that variable PartialTP must be smaller than TrailingStop. I don’t understand why you implemented the logic in a way that both variables depend on each other. IMO, they should be independent. Then we could easily key in a higher input for PartialTP, and DynTP could get active.
keeping track of partially closed orders in some kind of list as you suggested. Here I would suggest using out-of-ea storage place so the ea can continue to work even after ea/mt4/windows restart.
Could easily be done in a text file.
using order comment to store order’s initial lots and then compare it to OrderLots() to see if they match. This would allow for only one partial close per order (do we need more?). Also, some borkers replace order comment fields so it may not work for everybody.
Regardless of the broker involved, I wouldn’t feel comfortable using an algorithm that can directly be influenced by brokers’ actions.
instead of partial closing, we can do ‘partial opening’.
Yes, but in this case we would have to decide upfront about the percentage. With partial close, the percentage could be dynamic, if our trading logic requires that.
I think now we should decide on the PartialTP logic and implement it.
I would opt for a solution that is as simple as possible. One partial close is enough, IMO. If needed, more can be added later.
I think it’s essential to uncouple partial close and trailing stop.
As I wrote earlier, I think that partial close only makes sense if I can cash in ALL my risk from that particular trade and leave some volume to run further at no nominal risk. So if my initial SL was at +/- 1.5 ATR, I would opt for a partial close at ENTRY -/+ 1.5 ATR. So the remaining trade volume has enough space for further development, and trailing as well as Dynamic TP can work effectively. If trailing the SL is applied at the same time, the threshold can be modified. But we should not move the SL to say 5 pips below current price. If we do that we have a high probability that price action will hit our new SL.
Certainly SL can be tightened, but if SL is too tight, DynTP can hardly become effective. So if we want to be sure that DynTP has enough space left for price action, we could even consider to bind TS and DynTP together in one order modify command.
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
That rule is there just to make the partial closing logic work: PartialClose is applied when setting SL to BE. SL can be set to BE only if SL is negative. This could not be done if PartialTP was bigger than TrailingStop.
Once we have new the partial orders management function, we won’t need this rule anymore.
V.
Maybe,
else V = EMPTY_VALUE;at first second of every candles in every TFs mostly, Open = Close = High = Low with Volume = 0, So, ‘V’ should be ‘Empty’ first, before the loop change ‘her’ value later.. if High-Low != 0.0. Just my noob cent.. lol MTHThis is a very nice information bro … Thanks a lot
Hi All
I’ve been working on the news indicator / function today and I reckon I should take an extra day or so to tidy up.
A big thanks to Emonts putting it together. I take days and days to research and to plan it out to this point.
There’s been a lot of work done by different people on this FFcal and Simplex is right that there is an overuse of global variables.
I’ve changed the name of the main calling function as follows (if no-one objects) as I think I’d like to add some more features to FFcal.
its use in the indicator is as follows
int newsValue = getNewsImpactLevel(Symbol(), minutesBeforeNews, minutesAfterNews);
Hi @fuzzy!
This really sounds good, I’m looking forward to implement and test your version.
It’s great that you joined the team.
s.
A good trader is a realist who wants to grab a chunk from the body of a trend, leaving top- and bottom-fishing to people on an ego trip. (Dr. Alexander Elder)
Hi Simplex and all
Well I’ve been busier than I’ve been in weeks. I’ve been delayed by other peoples problems
I hope to be ready for inspection sometime over the weekend, I’ve entirely rewritten the file parsing and calling function, – now going to look at tidying up the xml file download. (slowly removing all the globals etc
)I don’t think there is a lot of need for the indicator to use a timer, I am unsure how the EventSetTimer in an indicator affects the calling EA. This indicator need only be called once a minute or so I’m inclined to use the OnCalculate event and do my own one minute timer.
but i could be wrong though …
) I had to study the MT4 Tester logfiles very intensely at a very detailed level. Most of you will know the problem that the logfiles are ‘presented’ by MT4 in a horrible way (1st pic). So it is not surprising that some of us are getting more and more trouble with their eyes.
- You must be logged in to reply to this topic.