I'm trying to make some basic EA frameworks to fit FSB strategies in MT - MQL4 and MetaTrader 4

Vasiliy Smirnov 2009.03.29 21:04 #561

Miroslav_Popov >> :

And you can also add the drawdown as a percentage, so it's easier to see. >> Thank you.

Miroslav Popov 2009.04.13 08:11 #562

This can be the beginning of a FSB to MQL4 Converter.

Any help or feedback is highly appreciated.

//+------------------------------------------------------------------+
//|                   FSB__Bar_Opening - Bar_Closing.mq4 v0.0.1 Beta |
//|                                 Copyright © 2009, Miroslav Popov |
//|                                              http://forexsb.com/ |
//|                                                                  |
//| An exmple EA pattern:                                            |
//| * Enter the market at Bar Opening                                |
//| * Exit the market at Bar Closing                                 |
//+------------------------------------------------------------------+
#property copyright "Copyright © 2009, Miroslav Popov"
#property link      "http://forexsb.com/"

// The time span before bar closing time in seconds.
// It determines the time interval for position closing.
extern double ClosingTimeSpan = 10;


int start()
{
   // Check if there are open positions from the previous bar
   int iOrders = OrdersTotal();
   if( iOrders > 0)
      ClosePositionsAtBarClosing(true, true, ClosingTimeSpan);
 
 
   
   // Opening Logic Conditions
   bool bLongEntryAllowed  = false;
   bool bShortEntryAllowed = false;

   // Put the entry logic rules here ...
   
   if(iMA(NULL, 0, 13, 0, MODE_SMA, PRICE_CLOSE, 1) >
      iMA(NULL, 0, 13, 0, MODE_SMA, PRICE_CLOSE, 2))
      bLongEntryAllowed = true;
   else
      bShortEntryAllowed = true;


   // Entry at Bar Opening
   iOrders = OrdersTotal();
   if( iOrders == 0)
   {
      if( bLongEntryAllowed || bShortEntryAllowed)
         OpenPositionAtBarOpening( bLongEntryAllowed, bShortEntryAllowed);
         
      iOrders = OrdersTotal();
      if( iOrders > 0)
         return(0);
   }



   // Exit Logic Conditions
   bool bCloseLong  = true;
   bool bCloseShort = true;

   // Put the exit logic rules here ...
   
   // Exit
   if( bCloseLong || bCloseShort)
      ClosePositionsAtBarClosing( bCloseLong, bCloseShort, ClosingTimeSpan);
}

// Entry at a Bar Opening price.
//
// MetaTrader does not provide an onBarOpen event so we check the current tick volume.
// We open a position when the current tick volume is equal to 1.
void OpenPositionAtBarOpening(bool bLongEntryAllowed, bool bShortEntryAllowed)
{
   if(! bLongEntryAllowed && ! bShortEntryAllowed)
   { // An entry is not allowed.
      return(0);
   } 
   
   // Check for Bar Opening
   if(iVolume(NULL, 0, 0) > 1)
   {  // This is not the first tick.
      return(0);
   } 
   
   int iLots = 1;

   // Check the free margin.
   if(AccountFreeMargin() < (1000 * iLots))
   {
      Print("We do not have money enough! Free Margin = ", AccountFreeMargin());
      return(0);  
   }
      
   int ticket = 0;
   if( bLongEntryAllowed)
   {
      ticket = OrderSend(Symbol(), OP_BUY, iLots, Ask, 3, 0, 0, "Bar Opening", 0 ,0 , Green);
   }
   if( bShortEntryAllowed)
   {
      ticket = OrderSend(Symbol(), OP_SELL, iLots, Bid, 3, 0, 0, "Bar Opening", 0 ,0 , Red);
   }
   
   if( ticket > 0)
   {
      if(OrderSelect( ticket, SELECT_BY_TICKET, MODE_TRADES))
         Print("Position opened at: ", OrderOpenPrice());
   }
   else 
   {
      Print("Error opening a position: ", GetLastError());
   }
      
   return(0);
}


// Exit at a Bar Closing price (almost).
//
// MetaTrader does not provide an onBarClose event so we are not able to close a position
// exactly at Bar Closing. We workaround the problem by closing the position within a time span
// near to the bar closing time. In the cases when there is no any ticks within this period,
// we close the position att he next bar opening price.
void ClosePositionsAtBarClosing(bool bCloseLong, bool bCloseShort, datetime dtClosingTimeSpan)
{
   int  iOrders = OrdersTotal();
   bool bIsOpen = false;

   for(int iOrder = 0; iOrder < iOrders; iOrder++)
   {
      OrderSelect( iOrder, SELECT_BY_POS, MODE_TRADES);
      
      if((OrderType() == OP_BUY || OrderType() == OP_SELL) && OrderSymbol() == Symbol())
      {  // There is an open position for this symbol.

         datetime dtOpeningTime     = iTime(NULL, 0, 0) - TimeSeconds(iTime(NULL, 0, 0)); // The opening time of current bar
         datetime dtClosingTime     = dtOpeningTime + Period() * 60;                      // The closing time of current bars
         datetime dtCurrentTickTime = TimeCurrent() ;                                     // The time of current tick
         
         if(
            dtCurrentTickTime > dtClosingTime - dtClosingTimeSpan || // The current tick is within the closing time span.
            iVolume(NULL, 0, 0) == 1                                 // or this is the first tick of next bar
            )
         {
            if(OrderType() == OP_BUY && bCloseLong)
            {  // Close a long position
               bIsOpen = OrderClose(OrderTicket(), OrderLots(), Bid, 3, Violet);
               
               if( bIsOpen)
                  Print("Long position closed at: ", OrderClosePrice());
               else
                  Print("Error closing a position: ", GetLastError());
            }
            else if(OrderType() == OP_SELL && bCloseShort)
            {  // Close a short position
               bIsOpen = OrderClose(OrderTicket(), OrderLots(), Ask, 3, Violet);
               
               if( bIsOpen)
                  Print("Short position closed at: ", OrderClosePrice());
               else
                  Print("Error closing a position: ", GetLastError());
            }
         }
      }
   }
   
   return(0);
}

Files:

fsb__bar_opening_bar_closing.mq4 6 kb

maxim 2009.04.13 21:34 #563

It would be nice if FSB could generate a dll with the strategy and the function could look like this:

#define inp   100
//---

#import "FSB.dll"
int    bEntryAllowed(double close[ inp], double open[ inp], double high[ inp], double low[ inp], volume[ inp]);
#import

that is send a number of bars to the dll and get a response from the strategy

The dll itself is like this

#define WIN32_LEAN_AND_MEAN  // Exclude rarely-used stuff from Windows headers
#include <windows.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
//----
#define MT4_EXPFUNC __declspec(dllexport)
#define inp 100
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
  {
//----
   switch( ul_reason_for_call)
     {
      case DLL_PROCESS_ATTACH:
      case DLL_THREAD_ATTACH:
      case DLL_THREAD_DETACH:
      case DLL_PROCESS_DETACH:
         break;
     }
//----
   return(TRUE);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
MT4_EXPFUNC double __stdcall int    bEntryAllowed(double close[ inp], double open[ inp], double high[ inp], double low[ inp], volume[ inp])

  {
   int out;

   //--- strategy

   if ( close[1]> close[0]) out = 1;
   if ( close[1]< close[0]) out = -1;

   return( out);
  }

you have all your own indicators anyway and only need time series data

Multi Timeframe Indicators Useful features from KimIV mql4 equivalent of Amibroker

Miroslav Popov 2009.04.13 22:13 #564

I'll provide complete FSB <-> MT4 bridge later.

So FSB will take quotation and account info from MT and will send back trading orders. In that way it will be able to trade the FSB strategies in MT.

Now I'm trying to make some basic EA frameworks to fit the FSB strategies in MT as EA without any interop.

I need several simple patterns like:

* Enter (add, reduce, close) at Bar Opening (or Indicator value) when:

- condition1 == true; and

- condition2 == true; and

- condition3 == true; and

- condition4 == true

* Exit at Bar Closing when:

- condition1 == true; or

- condition2 == true;

or

* Exit at Indicator value.

or

* Exit at Permanent Stop Loss

or

* Reverse by following the entry rules.

Most of the indicators are standard and the other are pretty simple and can be easily rewritten in MQL4. Once we have the base EA pattern there will be no problem to translate the indicators.

The things I'm testing now are:

Open position at "Bar Opening" and close at "Bar closing".

So I hope to develop two new products:

1. FSB - MT data feed and execution bridge

2. strategy exporter to MQL4

Probably both programs will be open source.

Executing function only once Wma 5/20 - Ema Understanding chart High/Low vs

Denis Karavayev 2009.04.14 19:12 #565

(oh, I thought the topic was quiet now... let's liven it up :)?! (I will write a lot ... I will try to be logical ;), and not to overload the topic - I will divide it into several messages)

Gentlemen, welcome!

Miroslav - firstly, a couple of words "about the weather" (the lyrical part)... (I sincerely hope your understanding of Russian is up to par :))).

The product, of course, is awesome! I speak from my experience, both as a former programmer and as an abstract user (abstract software). You can feel the love for it (because everything is done very carefully) and there is hope that the development of the program will not "suddenly" stop (not die). Yes, most likely there are some logical errors (an illustrative example was with Data Horizon), there are small bugs in the interface ... But on the whole - THIS IS THE SONG! It's just a song!!!

I ask the public to pay attention to another revealing fact. The attitude towards criticism and the style of discussion on problems/flaws/new features/etc. This is me in the context of the beginning of the thread, where the development of the alternative product started, and how the author of the SSB reacted to comments made to his address. I don't think that Miroslav also has a "wagon" of time to develop a FREE program (and that he is such a programmer). But he finds time for us (to communicate), to finalize our comments and requests for his product, fixes bugs and offers something new (see his latest posts). And everything is calm, measured, without hysteria, as in the aforementioned SSB case. That deserves (extra) respect. My regards, Miroslav...

To finish the lyrical part (distractedly now) - that I personally am a supporter of the theory of "random price movement". I.e. in this question I completely share the opinion of a certain circle of people (including creators of sites like http://www.bigmany.ru), who are convinced that working in the market (I mean Forex and "everything close to it") where there is no way to recognize the second of (just) two main market indicators (I mean Volume). - it is simply useless and meaningless (devoid of any reasonable sense) to rely on any information from technical and, to a lesser extent, fundamental analysis...

We could have finished here in general :), but as you know - Russia is notorious for fools and roads, and using the first point of this statement - I still do not leave the idea "to make millions" :D, in fact - I am just curious. It's interesting to listen to "analysts' opinions" (like astrologers with their horoscopes - "many specialists", not much use), it's interesting just to look at charts (you agree - it's amazing), it's interesting to mess around with codes (you start to really understand what people try to express with given indicators), ... It's just interesting... It's interesting to cheat (or better yet - NOT to cheat) the "system" one day... That's why I'm here (in the market, conditionally). And I hope to benefit not only myself, but also the public. Because like Miroslav - some altruist by life.

My current opinion is that the technical analysis systems currently being used around the world (and the clear majority) are indeed, INVOLVED in the market. That is, the crowd of people, looking at their monitors and guided by the values of their indicators, amicably expects movement in a certain direction, makes deals... and moves that very price. Even if on a small scale, even if not always (there are still owners of "factories, newspapers, steamships" that do not give a damn about TA, they just need to buy or sell a certain volume at a certain time). But it happens! In other words - being "in the loop" (of the same TA), you can try to shift the probability of your positive random movements in the market towards (slightly?) more than 50%. It's not easy... BUT possible! As soon as I'm disappointed in this postulate - I'll leave the market... (and it won't be about the size of profits/losses, it's just, well, really frustrating and pointless to work within a completely random system... well, see above)

Service Work: Towards re-shaping The programmer gave me Asynchronous loading of charts

Denis Karavayev 2009.04.14 19:17 #566

So, now to business.

1. While there's been a lull here - I've been thinking. Yes, we can wait for Miroslav (when he makes either bridge between MT and FSB, or here, strategy compiler). But, in the end - he who at least does something himself gets the result :). I started from the assumption, that I have (guaranteed) a given tool (FSB), I have MT, let's assume, that besides these two entities there will be nothing else - therefore we operate within their framework, namely: FSB (at the moment) is a closed system; we will need MT anyway; the code of advisor (trading robot) will be needed in any case - yes, there should be a universal template, that (roughly) gives values of indicators and all, then according to "approved scheme"; so we will need indicators themselves.

2. I will stop right away at the Expert Advisor code. I do not share the optimism of creators of simple Expert Advisors - well, it is impossible to imagine the number of abnormal situations in the terminal and market. And we are talking about money, no jokes are appropriate (they haven't checked the error code - they have calculated some default action... and that's it, -$1000 is gone (conditionally)). That is, I'm convinced that any expert that really deals with money (or, better, real money) must be "ironclad" in terms of reactions to external events. The code must provide for a maximum number of variations in the terminal, server, or the market itself. In short - it's quite serious, and cannot be solved (written) with a jump. I'd be glad to participate in the creation of such patterns. But...

3. I've decided to go all the way from the bottom. I had a thought - if there is nothing to operate with for an Expert Advisor (indicators) - what for do we need an Expert Advisor at all then :)! So I took the indicators.

The premise was as follows. First of all, no one will guarantee that values of the indicators in FSB are equivalent to values of standard or additional indicators in MT. And in order to get "comparable" results in both programs - the values should be the same. Secondly, the number of indicators themselves (standard) is ALWAYS different. And to use (and search for) external ones... somehow I like either standard or my own (in life)... (Third - I have an impression that "conversion" of indicator code from FSB is not such a mega task, as Miroslav mentioned - the algorithms themselves are quite simple, the indicators itself are very "organized" in terms of code (the code is unified), i.e. roughly speaking - they create a set of errors.Roughly speaking, we create a template once and "fill" it with some indices one by one (this is the ideal image of the world :))). There's more in the fourth - I was wondering :).

Anyway, that's what the weekend was all about. Before I start something, I usually "take a long time to harness" (in this case - think). I have no time to modify the template itself (I understand that). Especially when the number of indicators exceeds a certain figure. So the key points should be designed at once. As a result, I made the following assumptions:

- These should be indicators (and not just functions for the future code of the Expert Advisor). After all, visual perception of information plays not the least role for a human (and for me, in particular), and the call of an indicator from the Expert Advisor code is not such a big problem (the iCustom has already caused a lot of troubles on the forum - when there are so many opinions, I usually prefer to check everything myself, the results of my "field tests" will do, there is probably a small overhead, but is NOT a great (this I declare with full responsibility) and I think it can be neglected in terms of universality). But for the "special connoisseurs" :) (just in case) in case the calculations in indicators are made in a separate function of the same type (see below).

- Indicators must output the same values as in the original FSB (separately negotiated item below). I.e. the code from FSB is taken as a basis and, if possible, modified as little as possible.

- The code should be optimized to work correctly with IndicatorCounted (i.e. by speed)

- Indicator parameters, as well as their values must be uniform and homogeneous. I am not talking about data types, as such. If you look at the code of indicators by Miroslav, you may see a good homogeneity of input parameters and output buffers. The task is to keep the initial picture to help users to be easily guided when indicating parameters or taking indicator values.

- The implication of the previous point is ... mm (attention - this is important). The key point about using all indicators is not that they generate any values of their own. It is that they produce SIGNALS! Really, for me as a person - what difference does it make what is the value of an index now or later(?!) It's still "incomprehensible figures". Understandable is when it's either 'Buy' or 'Sell' :). Everything else is "unclear"! Miroslav used this idea very elegantly by creating two buffers in each indicator (for long and short positions) that, depending on how the indicator is used (as a Point of the Position or Logic Condition), get values of either opening/closing a position or of the Yes/No filter (if all "Yes" in opening logic - open, if at least one "No" in closing logic - close (in general RTFM). Genius! ;) I followed this way and simulated this behaviour. At the moment, the first two buffers of the indicator (whose values can be seen in the Data Window) are the corresponding buffers with filters (1/0) or price values to open positions to the long or short side, respectively. I.e. Later on, when using the indicators in the Expert Advisor's code, it doesn't really care what, where or what values a particular indicator generates - it will just analyze the values of the first two buffers for a very simple subject (Yes/No (conditionally) or direct take of the price from there) ... And that's it! There is a nuance - almost 100% "stumble" on Ishimoku (there, the quantity of indicator's own buffers is close to the limit of MT itself (8)) - I do not want to refuse a nice idea (with the first two buffers), but I cannot combine them in one (I was thinking... there might be not only 1/0 (which could be turned into a bitmask), but also price tags). Most likely I'll have to do something with indicator values themselves... We'll see... As we go...

Client terminal global variables Error fixing and debugging Articles on the development

Denis Karavayev 2009.04.14 19:20 #567

In general, in short (abstracts): quality (FSB compatibility, bug-free, etc.), ease of further use, speed, code readability. In this order.

Well, and (actually) - what happened ... (brief history)

- All indicators have the value "fsb" in the file name prefix (example: "fsbBlaBlaBla.mq4").

- I took the indicators themselves in a pseudo-random order, so don't blame me. So far, there is, that is. For further discussion/analysis etc. - I think that's enough.

- Miroslav uses three external functions (which are located in the sources (at the very bottom of the page)) to calculate the Moving Average and the values of logical buffers. I had to start with them. All functions are wrapped in one file (" fsbCommon.mq4 "), arranged as library functions (" fsbCommon.mqh "). There is another file from this opera (" fsbConstants.mq4 "), which, respectively, contains constants for convenience in code. There were no special problems with the functions themselves (I somewhat complicated the initial logic of the "logic oscillators", for additional checks (out of bounds arrays, guaranteed correct initial values (the first in history) (Miroslav, there is a logical error in the code on this topic).. .and tried for a long time to "emulate" the behavior of iShift in MovingAverage so that the function correctly fills in the values of the resulting buffer for any sane value of this parameter (and not only for those restrictions that are given in the original original code) ... as a result, I abandoned this matter for now , putting a "stub" at the beginning (with iShift other than "0" the function does not work yet, which, however, has not yet been needed)). MovingAverage turned out to be cumbersome, but it kills several birds with one stone. Since returning the buffer from the function as a value in MT it is not possible (yes, maybe not necessary) - an additional parameter appeared at the end ( afTarget ) Also, considering IndicatorCounted (), one more step The parameter is responsible for the value of the first bar for processing. Well, the last additional parameter sets the "price constant" in terms of MT, by the value of which the values of the MovingAverage itself are calculated based on the existing arrays of series, or (if the value iAppliedPrice outside the values of "price constants" MT) - based on afSource . (hence the overloading of the code) I will immediately specify the nuance of programming - where there are cycles interspersed with selections by case - the cycles are inserted inside the selections, and not (which is usually more logical) vice versa. Done not because I don't know how to do it right - but because I know how fast :)! (well, in the future, I won’t dwell on this, whoever wants to analyze the code - you are welcome, but before asking the question "on the stupidity of the code" think a little about what (potentially) could cause such programming).

Another nuance is connected with MovingAverage (it may be informative for someone) - because. Moving Average values in Exponential smoothing modes (including Smoothed) directly depend on their own previous values - the choice of the "starting point" becomes very important (what value to take as a basis for further calculations). There are usually several approaches to this. Someone takes the closing price of the previous period. Someone averaged the price for the previous period N... Miroslav went the second way. MT clearly comes first. Hence the significant discrepancies in these two smoothing modes at the beginning of the chart (I added one blank for testing MovingAverage and everything else (" fsbTest.mq4 "))! And the restrictions imposed by me inside the function on the availability of data of the MovingAverage itself BEFORE iFirstBar, or a similar amount of calculated values AFTER iFirst Bar. Because the indicators themselves use a constant for the minimum value of bars on the chart (now 2000) - this should be enough for any situation (because I have not yet seen parameters with periods greater than 200). Unless, of course, more than one MA is used at a time ;).

- By analogy with the previous paragraph, files were created for external subfunctions that I already use in my work with this project (prefix "st": " stCommon.mq4 ", " stCommon.mqh ", " stConstants.mq4 ")

- Well, actually - the indicators themselves. In very short terms (let's take " Bar Range " as an example):

 //extern int slotType = SLOT_TYPE_LC;

external int indLogic = INDICATOR_RISES ;    // (INDICATOR_RISES <= indLogic <= INDICATOR_LOWER_LL)

external int nBars = 1 ;                  // 1 <= nBars <= 200

external int fLevel = 0 ;                  // 0 <= fLevel <= 500

external bool iPrvs = True ;                // True / False

slotType sets type slots in FSB (Point of the Position or Logic Condition) terms . Those indicators that can be not only entry/exit filters, but also set the opening/closing price - this parameter determines exactly what the indicator will generate in its logic buffers. See all constants in fsbConstants.mq4 (everything is quite clear there)

indLogic - in fact, a logical condition for the indicator (carries a different semantic load, depending on the value slotType )

Well, the parameters go further, in the order they appear in the indicator sources on forexsb.com, and how they are displayed in the FSB itself. Parameter bounds are specified in the comments and are controlled when calling init() by calling the PCheck() subfunction.

 double LPIndBuffer [];            // Long positions #1

double SPIndBuffer [];            // Short positions #2



doubleIndBuffer [ ];              // Indicator's values #3



doubleIndBufferDD [ ];            // Additional buffer for drawing #4

doubleIndBufferDU [ ];            // Additional buffer for drawing #5

With buffers, everything at the global level is used as indicator buffers (attached to the indicator itself). Just the required logical ones (LPIndBuffer[], SPIndBuffer[]) (always and always in this order (#0 - long positions, #1 - short positions)), IndBuffer[] - data of the indicator itself. But in this case, since a color histogram is used, this buffer carries only the values themselves, and two additional buffers are used for color rendering (to be honest, MT started programming just by transferring indicators :), and how can you simulate the behavior of color histograms within MT otherwise - I never came up with it (who can tell? If this is even possible)). They are not displayed in DataWindow in any way.

AT init() everything is as usual (parameter values are checked, the names of the indicator itself and indices are set, buffers are attached, etc.)

In deinit(), I'm thinking of inserting logic in cases of NOT closing the indicator (additional convenience, so that the parameters, there, are not reset, etc.), at my leisure (not a priority yet).

start() very primitive. Its task is to check that there are enough bars on the chart (to calculate any MA and in general) and call the function for calculating the indicator itself, upon successful call of which, custom drawing of the indicator is called (if it needs to be drawn somehow in a special way, as in this case as -once)

Calculate() - actual calculations. The code, in general, is similar to Miroslav's code, exceptions are made for optimizations related to IndicatorCounted(). If additional indicator buffers are required to calculate the indicator, they are set inside the function itself (static) (so as not to waste the indexes of the indicator itself), and are serviced by the BufferSync() function. Here is a separate joke - initially there was an attempt to limit the calculations by one more constant parameter (iMaxBars). "Field tests" (part 2) of the behavior of arrays of series in the presence of history, absence, movement into the future (the arrival of quotes, increase in arrays to the RIGHT (I'm now visually, about the graphical representation)), ... movement into the past (when the history is missing (we move to the left on the chart) and the terminal loads it from the server... and the arrays expand to the LEFT)... So... Broke off. I did it beautifully (tried to do it) - depending on the direction of the expansion BufferSync () and expands the array resp. left or right, filling in the empty EMPTY_VALUE values. Here only itself MT normally does not expand index arrays to the LEFT. He ALWAYS expands them to the right (from the side of [0] Bar). I hope it’s clear what I’m talking about - that during the next jump back in history, when the value of the bars on the chart exceeds iMaxBars (by jumping, again) - situations are quite possible when the indicator will not draw its values to the left of iMaxBars, but here is "strange data" from it, to the left of iMaxBars can be easily. Maybe no one will watch them ... But "not beautiful" (not our method). And all that is needed is for MT itself to supplement the buffers with empty values in the right direction ... It is potentially possible to catch such a situation, but ... In general, we draw from the very beginning of the chart ... _always_. (Well, as far as it is possible for this particular indicator)

Another nuance is associated with IndicatorCounted() - it would seem - a divine function. Return the values of the calculated bars and there will be no claims against you... WILL BE! I think it's not the IndicatorCounted() itself that is to blame (as well as the programmers from MQ), but a bunch of custom indicator programmers, who have not reached the divine purpose of this function. Therefore, it is forced to always return a small number of potential values. Either we recalculate the entire chart (IndicatorCounted() == 0), or the first one ((IndicatorCounted() == Bars - 1) or two (IndicatorCounted() == Bars - 2) bars. What I mean is that, for example, if the connection is broken and the chart "ran" more than one bar ahead - that's all ... "trees died standing" (IndicatorCounted() == 0) - we count the whole chart on a new Why? It was not possible to return the number of skipped bars (3, 4, ... 5... 10...)? (which is what this function was originally intended for, as I understand it) In general, like this...

... I "stumbled" on the RSI. And in every sense. Firstly, I did not understand Miroslav's code (questions to him will go below). Secondly, while testing the indicator, I saw discrepancies in the values obtained within MT and FSB! No, it's not at all what you thought ("crookedly endured" - well, admit it, you thought ;)). The point, unfortunately, seems to be in these declarations:

 float [] afPos = new float [ bars ];

...

floatsum ; _

...

Briefly speaking - float ! After a little thought, I slowed down for the time being. the very first thesis (accuracy and quality) has become questionable (and it is a priority).

The following reasoning is possible here: On the one hand, float is not bad, it is, as it were, a "roughening" of the indicator values, which should make the trading strategy even less susceptible to random spikes in the market. On the other hand, for example, when crossing some fLevel (1.0, for example) - you will agree: 0.99998 and 1.00001 are two big differences :). And there are such discrepancies. And if the pose opens at such and such a moment, but in fact the FSB level still does not reach 1.0 and goes down, then who is to blame? (the one who transferred the indicators :D?!)

There are actually two solutions (given that float MT is not supported!):

- emulate a float in the MT itself (with some heartbreaking constructions like NormalizeDouble(X, Digits + 2) ) - well, not everywhere, but consider that each multiplication / division by any

- change float in FSB to double. Here you need to understand the scope of changes, obviously finite, but you need to carefully walk everywhere. And that the potential result of the generated strategies in humans can "float". And in general, does Miroslav need it? (my humble opinion is that the FSB itself needs this, because extra precision has never harmed anyone, but at the speed of calculations (if this goal was pursued (?), because I don’t see any more reasons) in this time section of reality - this should not have any significant effect). I agree with the guys from MQ on this issue - because. if we do not operate with integer mathematics (some Decimal), then at least we will try with the maximum possible accuracy. In general, here is such a ... not an easy question ...

Questions from Beginners MQL5 Basic questions from a Learning and writing together

Denis Karavayev 2009.04.14 19:23 #568

Sorry for being verbose (I won't say any more, just the essence).

I would like to hear an opinion - should this subject be continued (and then "gone" further, the rest of indicators to dig through)? I can even in some order (since all the same the original mess :)), who, maybe, what needs to go forward. Time, unfortunately, in the general case is deprived (deputy general director in his office - "the day flies by unnoticed" :D). I find the time usually in the evening. But one or two indicators per day, I think I can provide...

So, questions for Miroslav on the subject...

1. What is the value of fMicron? (I set it (on reflection) to 0.000001, it seems, or is it even smaller?

2. What is the parameter bIsDescreteValues (in the oscillator logic). I get the meaning of it - but what is its default value? And what conditions does the change depend on? (or shall we say - what is it related to (in the FSB interface or wherever))

3. Actually about RSI, what is this design?

for (int iBar = iFirstBar; iBar < Bars; iBar++)

{
 afPosMA[iBar] = (afPosMA[iBar - 1] * (iPeriod - 1) + afPos[iBar]) / iPeriod;
 afNegMA[iBar] = (afNegMA[iBar - 1] * (iPeriod - 1) + afNeg[iBar]) / iPeriod

}

:)? The motivation for the question is as follows: If my vision is correct - it is a smoothed MA. In the context of the whole code - it is applied to the already calculated MA and generates a smoothed MA, where only the first value remains "alive" :). Kind of a logical question - what is superfluous here? This construction, which among other things makes REALIZED(!) choice of RSI smoothing modes in the indicator itself (it always turns out smoothed), and in its dependent ones. Or previous MA calculations (with correct mode from parameters) for afPos, afNeg?

Clearly, the classic RSI is based on the smoothed average. But there is at least a variant with Simple MA and it would be logical to remove the above code making maMethod parameter behavior operational. Or we remove MA calculation before this cycle and remove MA RSI parameters in all indicators (since they do not affect anything anyway!).

I would remove this code (above) :). (In the converted indicator this part is commented, who needs the original functionality - remove the comment tags! The RSI code is for reference only... Until we decide here, I would use it "at my own risk" :))

4. As already said there is a non-critical logic error in the oscillators logic in the behaviour on the initial bars. I can't make it out now, I will write it down tomorrow (where and how to correct it).

5. What shall we do with float in FSB? (or with lack of it in MT) :)?

The archive contains required files, unpacked to the MT root (the archive will be in the next post)

Good luck everyone... write :)

Everything about RSI Experiments ... Moving Average RSI

Denis Karavayev 2009.04.14 19:29 #569

Current indicator archive (2009-04-15)

Files:

experts.rar 101 kb

Vasiliy Smirnov 2009.04.14 19:54 #570

I agree float is not beaten - you need to look for a way out. We need to write the correspondence. Then create a library of indicators. If I can help, I will be glad.

Who wants a strategy? Lots and for free) - page 57