Servicedesk: laziness, autism or unwillingness to admit mistakes? Supplementing the charts with non-native candles. - page 7
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
On what grounds are you making a statement? Are you a developer? If not, please sign "imho".
it's not an imho, it's information from the developers.
what is your question?
It's hard to debate with someone who doesn't know the issue, it all comes down to trolling.
OK, so if it's 2 minutes between bars then what?
And if it's 3 minutes then what?
And if it's a weekend break then what?
If it's a weekday but it's a holiday then what?
Again, do not look at the history of MQ, let's be realistic, the history of dealing is not as deep and not as high quality (although MQ is not ideal, but as a model for other dealing will do).
If on a minute timeframe there is > 1 minute between bars, this is a bar of another timeframe, so move to the next bar, as soon as you get the first bar with the condition == 1 min. all found bar from which you can start calculation.
Booms, error, sparks from the computer,
If it is more than a minute between bars, it means that there was no tick on some bar and we have a missed bar.
I cannot see it as a starting point of the M1.
I've been programming in MQL5 for more than a year. The algorithm for finding the first bar on the timeframe is quite complex and inefficient, it's easier for MQ to save information about glue points in the history file itself and output it on request within 14 microseconds, than to search through a million bars to find the glue point at 978 853 bars.
Booms, error, sparks from the computer,
If it is more than a minute between bars, it means that there was no tick on some bar and we have a missed bar.
I cannot see it as a starting point of the M1.
I've been programming in MQL5 for more than a year. If you believe me, the algorithm for finding the first bar in the timeframe is quite complex and inefficient, it's easier for MQ to save information about glue points in the history file itself and output it upon request within 14 microseconds, than to search through a million bars to find the glue point at 978 853 bars.
How was this problem solved before, it's not even a year old?
I solved this problem 2 years ago and now I don't remember the details, but I managed to do it by comparing times between bars.
How was this problem solved before, it's not even a year old?
I solved this problem 2 years ago and do not remember the details, but I managed to do it comparing time between bars.
I'm just putting the start of the calculation from the date in the parameters, and the user can screw himself by figuring out what date he will set.
Everyone decides on their own, but no one has a normal solution, because MQ created a situation that could not be solved normally.
I tried to handle it with a sticky note when I was working with an indicator and it did not look like a real indicator, I tried to create a fake buffer to store the number of bars that were actually calculated and send it to another indicator.
it's not an opinion, it's information from the developers.
What is your question anyway?
or like this:
There is no problem, especially since each broker decides which story to use. If it wants - let it broadcast a slightly shorter, but clean M1. You don't have to use our story older than 1999.
Only practice will tell....
Renat, you understand that your MT4 was a fully open environment for both the programmer and the user - I mean access to .hst files and export/import of history data from the terminal, and now we have MT5, which lacks the description of .hcc and will not import any history data. Definitely, with this approach, the user may have "something else".
Give us a mechanism to control the quality of history
and how it will be further or so:
Or like this:
only practice will tell....
Renat you understand that your MT4 was a fully open environment for both programmer and user - I mean access to .hst files and export/import of historical data from the terminal, and now we have MT5 with no description of .hcc and no import of historical data. Definitely, with this approach, the user may have "something else".
Give us a mechanism for quality control of the history
It's not about the detail of quotes for some pre-war year. No one is asking for pre-war ticks.
It is about the implementation of the chart display and the operation of the relevant time-series functions.
Komposter, work with minutes within the last 10-12 years and don't pretend that minutes older than 1999 are important for you.
There's no problem, and having days older than 1999 allows you to see a deeper history.
There is no problem, especially since each broker decides what kind of history to use. If he wants - let him broadcast a bit shorter, but pure M1. It is not necessary to use our story older than 1999.
The ability to read and understand what is written has never been your strong point. A man is not a reader, a man is a writer.
I'll self-liquidate.
- No one is going to add functions to MQL to analyse what is a minute and what is a day. It is not clear how to do it.
unclear?
Option 1) Add to the history file the additional parameter Basef - if the bar is really a minute one, then 0 if there is no minute one, but for example an hour one, then the parameter = 60 if the daytime one, then the parameter = 1440.
a) when loading a chart, check it and respectively prohibit displaying of non-native bars, etc., up to the date for the seriesinfointeger...
b) check once and record all stitch points separately (the history will not go anywhere)
variant 2) store only info about stitching points (to save space, although I think variant 1 will not take up hard drive these days)
variant 3) add missing minute bars (after starting a minute history - that is weekends and simple holes) and for example, give them a negative value, and then just work with multiplicity and if for example i bar time and i+1 is more than one minute, then the merge point is found. But this is the most stupid variant because we should rewrite the algorithms of all indicators and the charts will get ugly like Zhanna Aguzarova
IMHO variant 1 is the most acceptable. Nothing has been changed, just a little added