Errors, bugs, questions - page 680
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
Wow, how gentle you are. Sorry, I forgot it was your weekend. What about us? Maybe it would be better to release the builds on Mondays so that there would be no such misunderstandings? We do not have days off. We (traders, not programmers) care about the quality of the platform. And what are you rooting for?
Do not worry - we will check and fix it.
For now, you can use the tiki mode, as before - it is the only reliable option for testing. Use the other methods only for rough evaluation of the strategy (regardless of what the author of the strategy thinks).
It's up to the programmer to analyze the data. The above query was purely private and had nothing to do with us or the terminal.
"I am not me and the horse is not mine". Classic.
This is, oddly enough, about Thomas, not Yeroma: not about our analysis, but about your synthesis of senior TFs while retaining some - namely temporal - precise attributes of the object called a bar. That's all. There's nothing else you need to be happy as a programmer.
Just think how many inefficient routines are happening: you, developers of the terminal, took responsibility for creation of the TF senior from M1, but the good idea was dead, and after your synthesis we should do the reverse operation - data analysis! What's the game of "archiving-unarchiving"?! What's the fun in that? If you have already invented synthesis, make it as efficient as possible: provide its results with more informative data. So, let's do it...
1. it is up to the programmer to analyse the data. The above query was purely private and has nothing to do with us or the terminal.
2. your questions about missing bars from your ignorance of the market situation. Look at stock or futures charts to broaden your horizons and questions about "there should be no holes" will instantly disappear.
3. these are general words. Especially about the strategy.
Renat, you are grossly mistaken about the exceptional particularity of this query. Do you want a forum vote on this "exceptionally private" query? It will instantly dispel your illusions.
2. I have seen it. So? Lots of missed bars? I have no illusions about that either. I have a query. Not at all original and by no means "exclusively private". Namely: the mode of access (and display!) to quotes (including, yes, yes!, low-liquid ones) automatically (!!) supported by the terminal manufacturer, in which all the intra-session holes in quotes are filled with dodges with the parameters {Volume=0, Open=High=Low=Close=[ previous barclose price ]}. Do you think this mode is in demand? Or am I a big original? Just be honest, Renat. Putting your right hand on your left heart.
3. OK. Let's drop the strategy. It's just my speculation.
I invite a bit of wiggle room.
Somewhere in the depths of history there is a D1-bar- theoretically it is 60*24=1440 minute bars. Using CopyTime(), we bite at its edges a segment in the M1-history expression and look for hi- and low extrema with ArrayMinimum() and ArrayMaximum() in the most accurate and most voluminous form. To find the exact time of an extremum of one bar, it's a blink of an eye but what if we need to calculate hundreds? But you do need to! After all, no one has the right to say "hey, stop, don't want that!" and even to reproach us for a wrong approach within the limits of the tools we are provided with. And the further the specified bar is in history, the slowerCopyTime() copes with it. Then there is this demonic conversion between the time of bar and its index! No, I'm not in favor of displaying missed bars, I rather agree with MetaQuotes ideology, but I can't help noting that such conversion is also resource-intensive, confusing and bloats the code. If there were always exactly 60 minute bars in a terminal hour (24 hour bars in a day, etc.), you could immediately select the required index bar by simple arithmetic operations of multiplication, addition and subtraction - you wouldn't miss it for sure... and no double-sided conversion.
So to the question of scouring through 1440 bars in search of an extremum... I'll tell you, it's a no-nonsense activity. And speaking of cleverness... - is there an alternative?
Only one thing came to my mind (and it's been like a year ago already, so it wasn't even an alternative, but a basic solution, which I asked here, but no one ever answered): is interpolation method suitable for pulling the exact time value? Namely: sequential substitution manipulations with increasingly lower timeframes up to M1? That is, we have to makeCopyTime()'s with subperiods of interest, which is not a sample of performance, and then substitute them in a matrix. In idea, it's done tens of times faster than full single-reading of 1440 bars: in D1 we have 6xH4, in H4 - 4xH1, in H1 - 2xM30, in M30 - 2XM15, in M15 - 15XM1. At maximum in each period we get the total number of passes:
in D1: 6 H4-bars, found one +
in H4: 4 H1-bars, found one +
in H1: 2 M30-bars, found one +
M30: 2 M15-bars, found one +
in M15: 15 M1-bars, found one = 29 iterations max vs 1440!!!
It would seem: the advantage is obvious. And now think, wouldn't crystal and RAM choke on all those matryoshka BDSM-CopyTime()'s in a loop for several periods... I personally shudder to even think about it... Then there are all those checks for simultaneous availability of data from different timeframes, which may never happen, synchronization, so on and so forth... And all the flirting with selecting multiples of lower TFs for non-standard higher ones - I'm done talking quietly. It looks like my codecraft has taken root in the wrong direction...
Anyway, I don't know about you, but I no longer have any enthusiasm for wasting my time exchanging a shill for a shill.
Of course, I know the sheriff doesn't care about Indian problems. Then who's the terminal for?
I invite you to do a bit of thinking.
............
..........Of course, I understand: the sheriff doesn't care about Indian problems. Then who's the terminal for?
It's all painfully familiar. And annoying year after year. x100intraday, let's do a ballot, see how many more people get sick of it.
It's all painfully familiar, and it gets annoying year after year. x100intraday, go ahead and do the poll, let's see how many more people are getting off on it.
If it's important in principle that I do it, instruct me (right here or you can do it in private), but if not, you'd better do it yourself, I'm all for it.
P.S.: And I do not believe in ballot boxes. Look at myself: as an active member of various forums and blogs, however bypasses something that does not concern me or that simply do not have time to read, even if it's mine. And not everyone gets to vote, regardless of the relevance of the problem to them. And if the problem is totally alien, then why all this extra work? Maybe it is not worthy of reasoning like that, but I am not the only one with the problem. Voting is quasiobjective. You always have to rely on the objectivity, discretion and prudence of the professional collective, which claims to know better than us, the users, what we need and what is bad for us. ...Not to mention such mishaps as throwing in enthusiastic votes not on the principle of "Putin is the best politician today!" but "he is the most beautiful!"
It is utopian policy to make a product convenient (= somehow appealing?) to a statistical majority of users and assume that this majority will automatically consume the product en masse. The herd has a hierarchical structure and always follows the leaders of sub-groups. Until this becomes an axiom of your usability strategy, you will continue to make gross miscalculations in assessing the potential appeal of your services.
In the context of the above, there are tremendous resources for increasing the attractiveness of the terminal for the masses - for example, to finally implement "hole-free" minute history, the possibility to test on other quotes, CCA orders, and many other "statistically unclaimed" services that are of real interest to intellectual leaders in your own forums (not just written out of thin air).
In MT4, it worked like this: #import "TrendLine\\\MemoryDLL.dll".
The funny thing is, I've tried a bunch of options, including this one.
The result is the same - the required file is not found (I need to reach *.ex5).
Before it worked like this
#import "\DirName\FileName.ex5"Now it doesn't work, neither do other variants.You are afraid to spend time to calculate additional bar characteristics for very rare (close to zero %) cases, but happily demand that we should be the ones to prepare a lot of data in 100% cases, slowing down and consuming memory many times more.
Some methodically give such beautiful advice to kill themselves against the wall, that it is time to talk about pests.
Strategists of this kind are immediately visible.
You don't seem to be thinking very far ahead.
Are you afraid to spend time yourself to calculate additional bar characteristics for very rare(close to zero %) cases
I have a feeling there will be a vote :)