Any explanation for a single missed execution of a condition?
-
Hello fxdreema community,
I have one missed execution of a “close condition” which worked well in all the other occasions. The arrow in the snapshots attached (one panoramic and the other detailed) shows were the close condition should have been met but was not executed. Can anybody explain to me why?
http://www.screencast.com/t/kMXvwRONgNGe
http://www.screencast.com/t/lv8Rf4ruhttps://fxdreema.com/shared/Bwm1LhEVd
......
TMA.mq4
SolarWind.mq4 -
Put the SolarWind indicator into "Indicator tester" (Trace) and look how it works on Visual Mode (also add the indicator to the chart while testing). You will see that green/red bars are changing their height when they move from candle 0 to candle 1. I think this is the reason, maybe something specific happened and no crossover was detected, but then the bars look like there must be crossover there.
If setting Candle ID to 1 doesn't work for you, maybe setting Cross Width to 2?
Do you test this on "Every tick" mode?
-
FxDreema - You are THE man!
Just for the record: Using Trace did not help. Actually the numbers that you see on the bars in the 2nd snapshot are the output of the Solarwind buffer. And yes, I did test it with "every tick" and the problem persisted...
But your suggestion to change the cross width from 1 to 2 resolved the problem. Somehow the width of 1 was "too narrow" for the condition to catch the cross, even with "every tick".
As I said before - you are great: this is the 2nd time that your suggestion helped me very much. I will sign up for the yearly subscription after the Labor Day holiday end here. You've earned it. Thank you very much.
-
Finally, this "cross width" parameter is useful for someone
I think I remember seeing problem like this before, but I don't remember what was the reason exactly. I also don't remember whether it was a bug or just a fact. If you understand why this happens like that, tell me. -
SolarWind is indicator from group "most repaint", is based on calculation on ehler formula and not best coded. You can look for non repaint one: "ehlers fisher nrp" or "fisher transform nrp" from user "mladen" - I think he made it non repaint ...
because repainting make for you this issue ...
or you can try my old solution for this repaint issue (but has not removed issue completly) and it is smoothing values with MA ( it slowed indicator) and take values from this MA buffer, smoothing MA value can be set ... is attached ... -
__If you understand why this happens like that, tell me[/quote:375pqco4]
FxDreema,
The good news – I’m now a yearly subscriber.
The bad news - I have no idea and can’t even make sense why the tick that crossed above the 0 from below was not captured by the EA. Miro’s comment gives a plausible explanation, but as I discuss it next, it may not be the case.__miro1360
because repainting make for you this issue ...[/quote:375pqco4]
Hi miro,
Thank you so much for your explanation and the file attached. The reason I’m not 100% convinced that the problem lies with repainting is that from what I have read and learned about it, everything that happens in bar0 is actually really happening, but by the time that the bar closes - whatever happened there may have disappeared. Actually, most people would not consider it a "repainting" but rather a normal behavior of Bar0. What is considered as a true repainting is that during the recurrent recalculation of bar1, bar2...., they are "repainted". So, I would expect Bar0 to be the only "normal" bar in a repainting indicator. This bar should provide the output of the formulas as they were originally designed by the indicator creator. Correct me if I’m wrong, but IMHO based on the “tracer” values that I see here, regardless of the "repainting" of Bar0, one of the ticks that formed bar0 did cross over the 0 and this should have triggered the condition, but it did not.In addition to “SloarWind”, a good example for a “worst repainter” indicator is another one that I use here – “TMA” (as opposed to the “True TMA” that supposedly is a non-repainter). Yet if you are familiar with the lengthy thread of “The Extreme TMA System” on ForexFactory, the group led by Alorente made loads of pips by intentionally using the TMA rather than the True TMA.
I am going though to explore usage of the indicators you have suggested and the MA solution that you have provided here so graciously, to see whether they add reliability and profitability and whether they conform with the rules of the system as I have envisioned them. In its first edition the EA is designed for longer TFs (4H and daily) and so far it has demonstrated to make tons of pips, so repainting is an issue I can live with as long as it doesn’t compromise reliability.
Thanks again Ron -
Try visualy strategy tester with this indicator (not with EA tracer, normally indicator tester in MT4).
But finally I found for you that one what is not repaint, you can try it instead. Calculation is made with decreasing counting bars in buffers, what is ok for eliminating repaint issue.
......
fisher_org_v11.2.mq4 -
____If you understand why this happens like that, tell me[/quote:bzitg6fd]
I have no idea and can’t even make sense why the tick that crossed above the 0 from below was not captured by the EA. [/quote:bzitg6fd]
Because ticks are not captured. When you use the crossover in "Condition", the values of 2 candles are compared. Here are more details: https://fxdreema.com/demo/mt4-crossover-indicators Well, you have 0 on the right side, so the conditions are:SolarWind[0] > 0 AND SolarWind[1] < 0
(where [0] means the indicator's value from candle 0 and [1] is the indicator's value from the previous candle)
But because the indicator repaints for candle [1], the moment is skipped.
Here is another kind of crossover - https://fxdreema.com/demo/mt4-price-vs-indicator - this one compares the current value with the value of the previous tick
-
Thank you FxDreema for your insightful explanation.
I did act on miros’ advice and searched non-repainting replacement for SolarWind.
Of all the mladen’s Ehlers’ Fisher transform indicators that I have found on ForexTSD the only one that may be beneficial to me, based on visual inspection of the output, is “Ehlers fisher transform histogram 2.5”. To test the output of this indicator I imported it to fxdreema . All the input parameters and the buffers were imported well. Also, the indicator itself was compiled well (see snapshot) and ran well on a chart. However, when I wanted to trace a buffer output, the tracer EA would not run. Compiling this EA showed several errors in the way fxDreema interprets the input parameters of this indicator (see snapshot). Can you check whether it’s a bug in fxdreema?
http://www.screencast.com/t/ggvaMJWWh
http://www.screencast.com/t/ZDiib1KmxB8 -
This enPrices enumeration is available only in the scope of the indicator, the EA is not aware of it. But you can use "int" instead with values such as 0, 1, 2... For example, pr_close is 0, pr_open is 1 and so on.
-
Thanks for the reply. So FxDreema doesn't handle enumerations. The solution you are suggesting makes sense to me but I don't know how to do it. Can you please point me to a link showing how to practically convert enum types to their corresponding integers in mlq4?
-
No need to be converted, just use "int" as a data type and values such as 0, 1, 2.... It's not very practical, but it should work. To be honest, I don't even know how to "see" the custom enumerations used in custom indicators from Expert Advisors. Yes, we can define enumerations in our Expert Advisors or work with the predefined, but I don't really know how to read the enumerations used in external custom indicator
-
No problems. Instead of playing with this indicator I found that the indicator provided by miro (Fisher_org-v11.2) is useful in FxDreema and that it is actually a pretty good non-repainting replacement (for my purpose) to SolarWind (thank you so much miro!!).
This current topic is now resolved. However, since there is no formal manual to FxDreema I need to ask you a general question which deserves a new topic for everybody's education. It relates to the general approach in FxDreema to 2 conditions or more that have to be met before a market order is placed but they span over several bars. See you there.
