Errors, bugs, questions - page 681

[x572intraday]

Renat:
You don't seem to be thinking clearly.

You are afraid to spend your own time on calculation of additional bar characteristics for very rare (close to zero %) cases, but you happily demand that we should be the ones to prepare lots of data in 100% cases, slowing down and consuming memory many times over.

Some people methodically give such nice pieces of advice to kill themselves against the wall that it is time to speak of pests.

Strategists of this kind are immediately visible.

If you carefully analyze all my posts on this and several previous ones, and then play with multitemporal indicator of graphical TA markup on fractals, you will no longer want to argue with me on this topic, as after a bucket of ice water. But the problem is that the indicator is not completely optimized (it does not concern this topic) and it is not functionally complete. That's why I waste my resources on nonsense, not on completing and putting release.

There are a lot of graphical objects. And you still have to clean them up... There are enough problems.

[Renat Fatkhullin]

This is a special case in point.

[x572intraday]

Renat:
This is a particular case in point.

The live autotracking is wanted by slightly less than everyone who trades by hand. Who write MTS/ATS on oscillators, sliders and the like, let them do it, I would use this indicator for autotrading "from that line over there", but MQL cannot see any lines by itself. Then you can say goodbye to resources at all, even 16 GiG will seem a mockery.

[Andrey F. Zelinsky]

Yedelkin:

I have a feeling there will be a vote :)

Or kill someone against the wall :)

[x572intraday]

Everything was once private, the first idea in the mind of the inventor-pioneer also nested in him alone as something private. Then it became popular and spread... and even became embedded by default as a system tool. Familiar, isn't it?

Otherwise, nothing would ever have developed into anything...

[[Deleted]]

abolk:
Or killing someone against the wall :)

That's the more likely outcome.

And I have a feeling my question will never be answered and I'll have to write to the BOD... :(

[Renat Fatkhullin]

MetaDriver:

2. I've 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.

My experience clearly indicates that filling in the blanks is nonsense and self-delusion, which will immediately unravel once you get that filled in story.

This issue has been raised many times over the last 10 years.

[Renat Fatkhullin]

x100intraday:
Live autoplotting is wanted by slightly less than everyone who trades hands. Who write MTS/ATS on oscillators, sliders and the like - let them do it, I would use this indicator for autotrading "from that line over there", but MQL itself does not see any lines, so I have to go into planimetry, look for roots of hypotenuse, fill in the Gann Scale square matrix and apply an EA to that indicator. Then you can say goodbye to resources at all. 16 gig will be a mockery here.

That is, you want to shift the heavy pre-calculation of states for your solution onto us, thinking that happiness will ensue.

That is, you don't even appreciate the consequences of the fact that as a result we will ruin the performance of the terminal 100% of the time and waste a lot more memory. That's the malicious advice.

If you are developing a complex solution, use algorithmic methods of reducing the amount of calculations in each case , rather than trying to solve the problem directly. Use background preparation of caches with needed data.

[x572intraday]

Renat:

That is, you want to shift the heavy pre-calculation of states for your solution onto us, thinking that happiness will ensue.

That is, you don't even appreciate the consequences of the fact that as a result we will ruin the performance of the terminal 100% of the time and waste a lot more memory. This is malicious advice.

If you create a complex solution, use algorithmic methods of reducing the amount of calculations in each particular case, rather than trying to solve the problem head-on. Use background preparation of caches with needed data.

Caches should be located on disk, of course, and not somewhere... in RAM? You mean file read/write operations? But, firstly, it's no more convenient than if you're stacking up exact_times[] values in the database at the expense of the terminal. A good development environment should provide all its users with ready-to-use tools, which each user can invent on his own, but straining every user with the same task in isolation is ruthless. It's about specifics. There is no such thing as special and you can't expect it, it's an illusion. I'm on the forum myself rather because of suggestions and bringing new ideas, and then only for asking questions about already built in features (you can study the help if you want). And secondly, I'm reminded of the absurdity of analysis by MQL-coders - it reminds of pulling the entire archive for one particular file, and not pulling a single precisely selected file. If you do a precalculation of the exact times of extrema, it will undoubtedly take time and machine resources, but no less resources will be spent on our own analysis. Something tells me that C works a bit faster than MQL... Speculation or fact? And the worst thing is that we have to periodically check the current state of displayed objects, i.e. partial recalculations. To avoid them, it's necessary to take previously calculated data from cache, but it's from previous "first".

[x572intraday]

After all, this is built into the terminal as a feature so that one can choose optionally whether the terminal calculates accurate bar times or not. This is standard practice, let the user choose between accuracy and timing. However, the possibility that MQL programmers believe that terminal developers should pre-calculate additional attributes of bars is both strange and unserious. Of course, we can also do a lot, but we need to clearly see and distribute the roles between the terminal developers and MQL programmers trying to be objective.