Discussion of article "Custom symbols: Practical basics" - page 4

New comment
 
afsmerinostra:

Good afternoon, Stanislav!

Thank you very much for the article and the work done, I found a lot of new things!

Can you tell me where in the code to look for the logic of the formation of reversal bars in RENCO, I've been struggling with this for a month in the tester, I thought I would find a way to simply bypass them with signals, but not so.... ) I am a beginner in programming, so if you can poke your finger specifically, I would be grateful.

Why couldn't we just leave OPEN as it is, why move it on reversals? It would be much easier with a tester, and in general. Is it historically so with renko? And is there any practical use in it, except for "correctness"?

All bars in RenkoTicks (if we are talking about it) are built according to the same algorithm - they are marked with "up box" and "down box" comments in the comments (reversals are not marked in a special way, but they can be seen by the direction of the boxes). It is more logical to build signals in the indicator, imho, I don't see the point of getting into the custom symbol generator.

I don't understand about open movement. Classical renko boxes are equal in size by definition and the reversal is marked by a gap of the box size. There are other varieties of renko (including those without gaps), but they are not in the article.

 
Hi, maybe I missed a part but, how can wicks of renko blocks be bigger than the boddies ?
 
Adren6:
Hi, maybe I missed a part but, how can wicks of renko blocks be bigger than the boddies ?

Wicks displays price movements between the moment when previous box completed and the next box completed. For example, if we have upside box finished, price may go up some points and not form next box, if the distance is less than required box size. Then price begins move down, go side by side with the last upside box, covers all the box in down direction (still not new box), then covers more points and finally hits box size. At this moment new down box is formed, and upsied wick shows all the distance, that is the previous upside box and previous non-finished upside movement which was not sufficient to form next upside box.

Size of a wick is always less than 2 box sizes, because this is the distance which would lead to a reverse. Until the reverse is not occured, a wick is collecting all volatility.

 
Stanislav, I was looking for operate with Renko charts, your development covers all my doubts about. Thanks by aggregate great value to traders. The expert advisor only needs a start an end time to trade.   
 

I also came across "HistoryCache: container header read error [0]" followed by "HistoryBase: invalid container (1970.01.01) found".

At the same time, the history for January 2022 is removed from the history of the custom tool, getting a gap from 31 December to today.

It occurs only on 2 computers, resources are enough.

@Slava, what details do you need for reproduction?

 
Andrey Khatimlianskii #:

Also came across "HistoryCache: container header read error [0]" followed by "HistoryBase: invalid container (1970.01.01) found".

This removes the history for January 2022 from the history of the custom tool, getting a gap from 31 December to today.

It occurs only on 2 computers, resources are enough.

@Slava, what details do you need for reproduction?

IMHO, you could have built an auto-reporter into the beta version of the terminal a long time ago, similar to the way Android sends hangs and exepts to Google Play.

Then there would be no need to dance with tambourine about reproducing the situation and providing evidence - all the necessary information in the form of a dump would be sent to MQ by user's consent.

But apparently this is not suitable for MQ, because they even closed the SD. And if there was an auto-reporter, they would be inundated with bug reports.

 
Stanislav Korotky #:

IMHO, a long time ago you could have built an auto-reporter into the beta version of the terminal along the lines of how Android sends hangs and exepts to Google Play.

Then there would be no need to dance with tambourine about reproducing the situation and providing evidence - all the necessary information in the form of a dump would be sent to MQ by the user's consent.

But apparently this is not suitable for MQ, because they even closed the SD. And if there was an auto-reporter, they would be inundated with bug reports.

I agree, after the closure of service-desk it became very difficult to fix errors found by users.

Only fxsaber somehow manages to bring some of his thoughts to MQ.

Apparently, we are already at the stage when we should work with what we have and not wait for anything at all.

 

When using custom symbols is there some kind of scaling applied to the spread?

I have imported some Dukascopy tick data for EURUSD (which I have called EURUSD_TDS).  Comparing the prices on the "Ticks" tab of the custom symbol with the prices shown for the same period using the following code shows the Bid prices to be pretty much the same, but the Ask prices are different such that the spread is significantly lower than on the "Ticks" tab - Ie the EA is seeing a lower spread than the raw data.  Also the timing of the ticks differs which surprised me a little, but it is the spread issue which is of greatest concern.

void OnTick()
{
   double Ask = SymbolInfoDouble(_Symbol,SYMBOL_ASK);
   double Bid = SymbolInfoDouble(_Symbol,SYMBOL_BID);
   datetime now = TimeCurrent();
   
   if ((now >= StartDate) && (now < EndDate))
   {
      double spread = (Ask - Bid) / _Point;
      writeToLog(StringFormat("%s, %.5f, %.5f, %.i", (string)now, Bid, Ask, (int)spread));
   }
}


Raw data, spread between 11 pts and 67 pts... What the EA is seeing, spread 9 or 26 pts...

       

 
Mr David Frederick Roberts #:

When using custom symbols is there some kind of scaling applied to the spread?

I have imported some Dukascopy tick data for EURUSD (which I have called EURUSD_TDS).  Comparing the prices on the "Ticks" tab of the custom symbol with the prices shown for the same period using the following code shows the Bid prices to be pretty much the same, but the Ask prices are different such that the spread is significantly lower than on the "Ticks" tab - Ie the EA is seeing a lower spread than the raw data.  Also the timing of the ticks differs which surprised me a little, but it is the spread issue which is of greatest concern.


Raw data, spread between 11 pts and 67 pts... What the EA is seeing, spread 9 or 26 pts...

       

Hi, there is no "scaling" of the spread, but there probably can be other nuances to interfere. For example, make sure you're testing in real ticks mode and do not have an option with fixed spread enabled (according to the right-side log it looks like the same spread during every bar).

It would be nice to see exact tick sequences for both UI table and your EA log (including msecs) - your current screenshot does not seem showing the same tick sequence.

 
Stanislav Korotky #:

Hi, there is no "scaling" of the spread, but there probably can be other nuances to interfere. For example, make sure you're testing in real ticks mode and do not have an option with fixed spread enabled (according to the right-side log it looks like the same spread during every bar).

It would be nice to see exact tick sequences for both UI table and your EA log (including msecs) - your current screenshot does not seem showing the same tick sequence.

Thanks for the response.  This is very odd, I am indeed using real ticks mode and I wasn't aware that there is a fixed spread option in MT5 so I'm sure that I'm not (I'm more familiar with MT4).  I hadn't spotted that the spreads were the same for each bar, in fact looking through the full file it seems that they only change on 1 minute boundaries.  I assume I am correct in thinking that the calls to SymbolInfoDouble() should return the prices for the tick being processed as a result of the OnTick() event call - not some kind of M1 value?

I tried printing what I expected to be the actual tick time with milliseconds using the code below, but the milliseconds value is always zero...

void OnTick()
{
   double Ask = SymbolInfoDouble(_Symbol, SYMBOL_ASK);
   double Bid = SymbolInfoDouble(_Symbol, SYMBOL_BID);
   long timeMillis = SymbolInfoInteger(_Symbol, SYMBOL_TIME_MSC);
   datetime now = TimeCurrent();
   
   datetime time = (datetime)(timeMillis / 1000);
   long millis = timeMillis % 1000;
   
   if ((now >= StartDate) && (now < EndDate))
   {
      double spread = (Ask - Bid) / _Point;
      writeToLog(StringFormat("%s.%i, %.5f, %.5f, %.2f", (string)time, millis, Bid, Ask, spread));
   }
}

EDIT:  As I said I'm relatively new to MQL5 - I've just found SymbolInfoTick(), maybe I should be using that instead of what I'm doing!  I'll try that and see what happens...


Ok, that made no difference, exactly the same results, but neither of them tying up with the "Symbol Ticks" dialog in the terminal.  I was wrong in saying that the milliseconds value was always zero - it is non-zero for exactly one minute, namely the one minute before midnight!

This seems to me to be a pretty important issue.  My trading EA is expecting to receive ticks with prices which match the source imported tick-data (as would anyone else's!).  I dare say there is something that I'm doing wrong, but if so I would like to know what it is.  If not then there is a very serious problem here.  I have attached a zip file with the test EA, a spreadsheet of results for the hour either side of midnight, and some screenshots of settings and ticks.

Files:
Tests_on_Custom_Symbol_.zip  152 kb
1234567
New comment