![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Yes the mail is correct.
I sent you a Private Message a minute ago.
Oh, I'd forgotten all about the private line :))))))
It's already piled up there :). Guys - sorry if I didn't answer in time, I just usually turn off Personal Messages on forums and didn't even pay attention here out of habit :)...
Miroslav - then now I will prepare a message (answer) and send by mail ...
**Remember, the Bar Opening and Bar Closing - Point of the Position problem is not limited to, the values of common indicators may well be used there. And so a position can be opened "in the middle" of a bar (easy!). (so to speak, about calculation of indicator values ONLY at intersection of bars... as I said - this condition is "not always" feasible ;))**
If understand correctly, you think that we have to recalculate an Indicator on every tick if the Entry point is in the middle of the bar (Let say at a MA). I'll afford to not agree with you.
For a reliable back test (using MT, FSB or other tester), all the indicators including Entry / Exit points have to be fixed. That doesn't limit an EA to use market entry during the bar.
Examples:
1. Entry at Moving Average (21, close):
In this case we cannot use the current MA since it is moving up / down until bar closing price is fixed. So we have to use MA from the previous bar. Doing this it's not necessary to recalculate it on every tick.
2 Entry at Moving Average (21, open):
Here we can use the current MA. It is fixed because the MA base price - Bar Opening is already fixed. We also don't need to recalculate it on every tick.
--------
Edit:
Of course this is my personal opinion.
I don't intend to force you backtesting in that way.
Regards!
Edit2:
In case I'm missing something, please show me an example of a strategy prepared with FSB when you have to recalculate an indicator on every tick.
Mmm, Miroslav, I get the idea (a long time ago, moreover)!
I was just confused by the constructions in indicator code, which I gave above:
namely: component[0].PosPriceDependence = PositionPriceDependence.BuyHigherSellLower;
That's just not the case, is it? It's important to understand that I'm not talking about the calculation of the indicator, as such. The value of which, yes, is stationary within a bar. But about the fact that in this case (which I cited above) we have to compare the last price value with it? In order to make a decision to open a position. At FSB, this is done by internal procedures (if I understand it correctly). But because they "are not known to us" (and, actually, what for?) - I suggested to recalculate the indicator on every tick, in such cases, to receive an unambiguous YES/NO on the logical condition. In other words, let the indicator itself make this conclusion, not the code that is external to it. I meant it!
I mean, um, once again - I agree with the thesis that the indicator should be calculated once on "crossing" bars. But in cases where the indicator gives signals about position opening, in application to the work of future EA(s) in MT - we should rely only on these values (YES/NO), and not on comparing current prices with indicator prices (which are static). Let the indicator itself compare this for us. And we will only take into account its YES/NO. That's it... :)
Or am I missing something somewhere? :D? ("got a little bit of a mammy...")
Hence the implication that I need to make one more revision of such calculations (I'm thinking now) to compare Close[iBar] with current or previous indicator's value (which of them is static) correctly (iPrvs should be considered). But in the idea I think I'm not wrong...?!
(what are we even discussing :))?! Indicators will still account for work with IndicatorCounted() ANYWHERE!!! I just won't do it any other way :). They can be used not only by EA writers, but also by users who will need visual part (and real-time values). The original code doesn't change a bit! Usually, you just add a bit at the beginning, which initializes the "original" values of the self referenced variables. No more than that... Sometimes this is given "little blood". Sometimes not so much (as in Hourly High Low example). But in any case, minimal bodily effort (yet?) :))
Or is it a global aspect? Then there's nothing to discuss - iPrvs is awesome!:) Full stop! But no one argues with it :)!
(I sent an email... I'll try to answer it here in person)
Miroslav - 'got it'! Not in the sense of finally understanding something :) (the idea of manipulating FSB with indicator logic,
I have understood it a long time ago (I don't take into account Stop Limit and other stuff, I haven't looked them yet).
I'm finally remembering something, let's just say :)
WE're just talking in the same context about different applications (meaning both the applications themselves (FSB and MT) and "in application to").
The key point is the calculation of FSBindicators once, before the back-testing procedure itself.
FSB simply cannot calculate unambiguously 1/0 for such conditions ("Position opens above / below ...") before the test itself!
Therefore, it uses exactly the right logic:
(off: I'm trying to insert the code again, as a separate comment - "the stone flower doesn't come out" :), then an empty comment, then it just goes to the first page... Maybe there are some elements in the text - "not digestible"... in general - so read (as above) :))
Gentlemen, Miroslav updated FSB to version 2.8.3.6 Beta yesterday:
http://forexsb.com/forum/post/2446/#p2446
The signal logic has been unified. The changes affected the vast majority of indicators. The code of the indicators calculation was not changed!
The logic signals became a little less susceptible to "noise". In the config file we have added two parameters:
Parameters set the "threshold" of signals triggering from the price change level (for indicators on the window with the chart and for indicators with their own windows).
Correspondence of MODE values are given here:
http://forexsb.com/library/source/Sigma.html
We believe that the "default" values are EXACTLY adequate (in most cases). But... feel free to experiment :).
I purposely waited for this release, so as not to do double work. I am putting my own works too. I have 20 indicators at the moment (I would not consider 2 of them as "useful" (Bar Closing / Bar Opening) - they will be useful in the future ;)):
Calculation algorithms and signal logic are fully FSB compliant (well... should :D)...
INCLUDING INDICATOR VALUES!!! (FSB (application) = -FSB- (conversion) = MT (internal) ) (up to any sign).
The exception is "-FSB- Accumulation Distribution.ex4" - Miroslav has a tricky code there, haven't got around to it yet (doesn't match MT exactly, haven't checked with FSB).
I'm continuing in alphabetical order (well almost). If anyone needs something higher priority, write... (person with Hourly High Low disappeared somewhere, I haven't understood - did it help or not :D?!)
At the same time we begin to develop EA, which will be able to operate with these versions of indicators. At the end there should be a kind of a sheaf:
FSB -> Exported strategy file -> EA, based on converted indicators and internal trading logic, compatible with FSB...
Good luck! And happy holidays to all!!!
I'll show up closer to the start of the work week... stay tuned...
Gentlemen, Miroslav updated FSB to version 2.8.3.6 Beta yesterday:
http://forexsb.com/forum/post/2446/#p2446
I'm downloading something and the archive is broken... :