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

New comment
 
Stellarator >> :

have there ever been discrepancies in the original values and "subsequently deployed"? still double...)

not yet.... all problems come from sloppiness :)

Forced to dissuade! The key nuance - "the limit of one iteration of the EA". Well, within these limits the indicator is calculated ONE time (at its first call)! I declare this with 100% confidence. All subsequent calls don't start() it at all, but only take the necessary values from the necessary buffers. The condition is 100% if the input parameters remain unchanged (except for the buffer and offset). The rule is valid for calculations within the limits of one tool. But I think the principle holds even when iCustom refers to other TFs and tools.

One would have to be "forced"..... all at once. Thanks for another undocumented feature :)


 

FSB__Bar_Opening_Bar_Closing.mql4 v0 .0.2 Beta


Market entry at Bar Opening;

Exit at Bar Closing (10 sec. till close or at the next opening)


** This is only demo for testing Entry / Exit points. **


Code fragments:


bool bIsFirstTick;// It is used to catch the Bar Opening.
datetime dtCurrentBarOpeningTime;

int init()
{
   bIsFirstTick = false;
   dtCurrentBarOpeningTime = Time[0];
   return(0);
}

int start()
{
   // Is this the first tick for the bar
   bIsFirstTick = ( dtCurrentBarOpeningTime != Time[0]);
   if( bIsFirstTick)
   {
      dtCurrentBarOpeningTime = Time[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.
///
int 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     = Time[0] - TimeSeconds(Time[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 ||  bIsFirstTick)
         {  // The current tick is within the closing time span or this is the first tick of the bar.

            // Code

         }
       }
    }
}
 

1. Regarding the performance:

Mostly we don't need to recalculate an indicator for every tick. (Reference - "Use previous bar value".) An indicator has to be calculated either at "Bar Opening" or at "Bar Closing".


2. fMicron:

I use fMicron = Point/2 when compare prices for trading decisions. But this is not applicable for the indicators. Eg. for USDJPY point = 0.01; fMicron = 0.005.

0.000075 is a result of many tests through the years. I started working on FSB in 2001 :) Of course it doesn't mean anything. I have changed my mind many times about it.

**edit: MT gives this to the hands of the users. Probably the EA gurus can say what they use in their EAs.

**edit2: I'll put this parameter in the config file for experiments.


3. I'll start providing the original source code for download for each FSB version. I'll not need to update the website for every small change in such a case.


I started changing float to double. I'll publish this version soon tonight or tomorrow. After that we have to test it thoroughly. We have to pass per each indicator to fix some problems / features before writing them in MQL.

 

1. Yes, in most cases (given FSB's general approach to opening/closing positions (at Bar Opening/at Bar Closing)) - This is not necessary. But, let's say - the rules of good manners - are obligatory. Calculation of the indicator "from zero" every time (even once at Bar) - in general (I agree) not critical within the limits of large periods... But what if the period is minutes? And what if the indicator still needs (or wants) to be calculated every bar? (Some sophisticated Point of the Position, which cannot (or cannot, due to the opening price being lower than the level of stops) be caught by an order?)

The conversion is not complicated by much, in fact - yes, there is some code "in the wrapper" and the principle of bar walking is reversed. Actually, that is all, by and large. The main thing is to keep the algorithm (so it can be easily read and identified inside the source code) and to keep parametric compatibility with FSB. Create a convenient mechanism for signal extraction. And to make it usable for pure visual designers (who don't care about EA). In my opinion.


2. Well, I didn't suggest to use Point/2 variant to compare (equally) indicator values :). - I was just suggesting a constant. The question is in its value and dimension (0.000075 - not bad, I didn't say that - I don't understand why exactly 75 and not "usually" 50:)? The experience "since 2001" is quite revealing (argument!) and I am quite willing to accept this value. But as a last remark - for quotes with a dimension of 0.12345 this will not be enough (I mean - a lot :))). The number should be shifted by at least one frame to the right (0.0000075). In my brokerage company, for example, such quotes are already common practice... I would suggest to adjust it for the instrument and use "10", not "75" :):

fMicron = Point * 0.1f

In short, yes - I propose to make it parametrically - set (I think after some friendly experimentation everything will fall into place (though... if the point has changed many times ;)...). And wait for more people's opinions...


3. I managed to download the posted sources :-P. So there will be "something to compare" (in terms of resulting code). And as much as I don't want to bother you any more - good luck with float to double conversion!


(how's the test with RSI? ;), if you managed to do it?)

 

I found out that the best is 100 > Micron > 50. That is why I took 75. It was for my broker: Point = 0.0001.

But you are right that brokers started quoting at 0.00001.

Let make it: Micron = Math.Min(Point * 0.75, 0.000075)

I hope I'll finish with conversion in 3 hours from now. I'll put here the program for testing.

I'll upload the converted indicators source codes too.

 

All indicators and parameters are double numbers.

Micron = 0.000075


Put the exe in the folder together with the last FSB v2.8.3.3 Beta. Both programs will share same data and strategies. It's convenient for comparing. Be careful about the indicators values. Practically all the indicators and the half of other files have been changed.

To see full precision press F12 in the chart or use Command Console (ind ####).


Please report any issues. Now is the moment to request changes about the indicators. We have to fixed them before to continue the work on MT integration.



 

Good morning!

Miroslav, very limited time now... so it's quick:

1. Thanks for the prompt translation (float to double)! Great!

2. So far everything seems to work (as far as I've managed to check), you can see the differences (on the fly), both in indicator values and strategy results :)

3. BUT - the differences were not what we previously expected! (I ran an internal experiment last night, and my "fears" were confirmed - conversion will increase calculation accuracy - but not catastrophically change the result! Something from the area of differences in the fourth-fifth digit... but we have divergences as early as the second digit! (the same RSI, for example))


THE REASON IS SOMETHING ELSE!!!


What I managed to check:

1. At first I thought about whether there were any hard links on the subject of Digits (I have instruments with 5 digits, mind you)... Forced specifying 4 digits in the tool properties - didn't help (by the way - but it works!)

2. The code of the indicators themselves ... hmm... ... well, there's nothing to complain about! It's double everywhere now, the code itself (as I see it) hasn't changed... The code is simple enough (very often operating only with addition and subtraction) - such an error may NOT have accumulated there!!! (I'm not so sure about it ... but ... ;))

3. My last thought (which I will not be able to check) - THIS IS WHAT :)!:



Bar Closing/Opening Values (???) (and other, potentially?)


Where do these numbers come from??? :))) (what kind of "additives" are they :D?)

I take it from somewhere here (Bar Closing.cs):

            // Saving the components
            component = new IndicatorComp[1];

            component[0] = new IndicatorComp();
            component[0]. CompName  = "Closing price of the bar";
            component[0]. DataType  = ( parameters. SlotType == SlotTypes.Open) ? IndComponentType. OpenPrice : IndComponentType. ClosePrice;
            component[0]. ChartType = IndChartType. NoChart;
            component[0]. FirstBar  = 2;
            component[0].Value     = Data.Close;

As a result, my first working assumption is that (maybe) it's about this? ("wrong" (or "right", but why exactly like that?) giving away the quote values in the function?)

Partially, apparently, to the question of the values obtained (to fill the operated buffers while calculating the indicator) from the sought function protected static float[] Price(BasePrice price)


In general, Miroslav - "the ball is in your court" :). For now I have noticed the new code of YOUR indicators, that is perfectly compatible with MT indicators (I am persistent :D, and I will "finish" the RSI subject):



Same bar, first indicator - conversion, second - native from MT.


Any thoughts, suggestions? (I will be there in 6 hours)

 

Частично, видимо, заодно к вопросу получаемых значений (для заполнения оперируемых буферов при расчете индикатора) из искомой функции protected static float[] Price(BasePrice price)

All base classes, methods and properties return double values now as well as all trading functions (I changed the last 6 months ago).

It seams there is a difference in the formula of RSI. It can't be in the second sign "but we already have a difference in the second sign! :) I'll try to adopt the existing MT RSI formula in FSB.



**Edit:

Fixed already:

Default params: RSI(close, 14, smoothed) == MT RSI

            for (int iBar = 1; iBar < Bars; iBar++)
            {
                if ( adBasePrice[ iBar] > adBasePrice[ iBar - 1]) adPos[ iBar] = adBasePrice[ iBar] - adBasePrice[ iBar - 1];
                if ( adBasePrice[ iBar] < adBasePrice[ iBar - 1]) adNeg[ iBar] = adBasePrice[ iBar - 1] - adBasePrice[ iBar];
            }

            double[] adPosMA = MovingAverage( iPeriod, 0, maMethod, adPos);
            double[] adNegMA = MovingAverage( iPeriod, 0, maMethod, adNeg);

            for (int iBar = iFirstBar; iBar < Bars; iBar++)
            {
                if ( adNegMA[ iBar] == 0)
                    adRSI[ iBar] = 100;
                else
                    adRSI[ iBar] = 100 - (100 / (1 + adPosMA[ iBar] / adNegMA[ iBar]));
            }


Program for download soon.


 

Miroslav - there are no differences in the formulas. As I said in the beginning of RSI discussion - you just have an OTHER averaging loop (which forcibly makes Smoothed from any result of correctly working MovingAverage functions) :), EXCEPT the first value (which remains from MovingAverage execution :).

Anyway, judging by the last cited code - everything has fallen into place (and RSI will now read other averaging modes normally) :)! Yahoo!


(indicator code, which I saved before, already contains this change ;) - just call fsbRSI with following parameters to make sure of it:

indLogic = not important

maMethod = 2 (! important MODE_SMMA in MT terms)

basePrice = 0 (PRICE_CLOSE in MT terms)

iPeriod = 14

fLevel = not important

iPrvs = not important

And get an exact match of results with the native Relative Strength Index (which comes with MT)

Except that both fsbRSI and iRSI are NOT the same as FSB :(


So let's get back to the main problem:


"All base classes, methods and properties return double values now as well as all trading functions (I changed the last 6 months ago)".


Well, that's great! I just don't understand how this thesis should affect

Opening price of the bar and Closing price of the bar? In the above example.


To repeat the question: Why are the prices sought DIFFERENT from the quotes??? (I mean 6,7,8, ... digits)


double has absolutely nothing to do with it! Values in quotes are normalized and should be preserved (be completely identical) when simply copied between variables.

If similar values begin to appear in the calculation of indicators (when the buffers for calculation are filled on the basis of quote values, the protected static float[] Price(BasePrice price)), then we are BETTER (strange as it may seem), i.e. it is like another source (besides the former float) of "slightly" denormalized data :)

 

I changed slightly some of the indicators to look like the MT's standard ones.


Changed FSB indicators:

RSI

Oscillator of RSI

RSI MA Oscillator

Bollinger Bands

Standard Deviation

Stochastics


There are differences in the following indicators:

Momentum

Market Facilitation Index


Other:

MT Moving Average Oscillator == FSB MACD Histogram

MT Momentum == FSB Rate of Change

Relative Vigor Index - not included in FSB


Now FSB and MT indicators should be more or less equal.


TODO:

Stochastics - revision of the signals;

Market Facilitation Index - formula revision;

A Momentum like the MT's one to be included in FSB - named "Momentum MT"

Including "Relative Vigor Index" in FSB.

1...525354555657585960616263646566
New comment