Errors, bugs, questions - page 673

[Vladimir Gomonov]

Renat, zero - thank you very much for your attention to the topic and your constructive response!

Next.

1. about x64

Renat:

The more correct option is to upgrade to x64.

...

Of course, if someone will call hundreds of indicators in the mode of market scanning without their unloading, they should go straight to the 64-bit version + install additional memory.

It's strange to be doing massive tests sitting on x32 at the moment. Any decent x64 computer with 16GB of memory (without graphics cards and monitors fanaticism) can be bought for 15 000 rubles.

Switching to x64 is by all means the right course of action. But. One does not rule out the other. Even my 16gigs (I have them) I don't want to squander them on some unnecessary data. I have other things to work on in parallel - MSVS, Matlab, etc., on which I also want to calculate voluminous tasks. I am glad that you understand this and are willing to look for ways to save money.

2. about a fixed start of history:

Renat:

We ourselves want to reduce resource consumption. Perhaps the solution could be some function IndicatorMaxDepth(uint len), which will act only on indicators created in this EA.

But the problem is that during testing the buffers of indicators in accumulation mode will grow together with history and there will be no saving.

Completely (almost) agree. Disclaimer: In many cases optimization is done on a small chunk of the last story. In this case the savings may be quite substantial. Still, I consider the option as relatively working - especially if you have a good work or estimates on implementation. To me, for example, the option seems not quite full-fledged - a lot of labor, and the result is not radical. A half solution.

3. here's the yaz! :

Renat:

Trimming theindicator's history in rltime, while maintaining the set depth , is fraught with beautiful glitches and will directly knock out the programmers who calculate/used to the synchronism of bars of the chart and indicator buffer.

No ! , not fraught - if the chart bars behave the same way - synchronously. In other words - if the ring buffers (even if different in size) always (forcibly) use AsSeries flag - no massive trouble is expected for the user.

// In this case, it would be convenient to make all history buffers presented to the user - indicator (i.e. circular, with AsSeries=true).

In this variant:

(1) there is an internal representation of indicator and price arrays (on your side) : indexing from left to right (AsSeries==false), the sizes do not concern the user, and indeed"entry is forbidden".

And (2) there is a user's side - all buffers are circular (in the implementation. the user sees a virtual linear array), indexing is from right to left (AsSeries==true) and the size is set by the user.

What's the user's roof here? None. When out of range - standard response Array out of range.

Only you have difficulties (not small, to be honest). But! Considering universality of the scheme - you have to strain only once. And to nip all "nice glitches" in the bud, at beta debugging. After that - universal happiness and very economical construction.

We will perform revision of indicator cache, which now uses the principle of maximum efficiency against the principle of memory saving. Indicators that were rejected will be unloaded immediately, instead of keeping them in memory for some time, as it is done now. This will make it possible to call hundreds of indicators in a row with a direct unloading via IndicatorRelease.

Good idea, I am for it. But it does not cancel the implementation of the ring scheme, but simply complements it nicely.

[Renat Fatkhullin]

MetaDriver:

3. Here comes the yazel! :

No ! It will not - if chart bars behave the same way - synchronously. In other words - if ring buffers (even if different in size) always (forcibly) use AsSeries flag - massive trouble is not expected for the user.

// In this case, it would be convenient to make all historical buffers provided to the user - indicative (i.e. circular, with AsSeries=true).

In this variant:

(1) there is an internal representation of indicator and price arrays (on your side) : indexing from left to right (AsSeries==false), the sizes do not concern the user, and indeed"entry is forbidden".

And (2) there is a user's side - all buffers are circular (in implementation. the user sees a virtual linear array), indexing is from right to left (AsSeries==true) and size is set by the user.

What's the user's roof here? None. When user goes out of range - standard reaction Array out of range.

Only you have difficulties (not small, to be honest). But! Considering universality of the scheme - you have to strain only once. And all "nice glitches" have to be nipped in the bud during beta debugging. After that everybody is happy and the construction is very economic .

Good idea, I'm all for it. But it doesn't cancel the implementation of the ring scheme, it just complements it nicely.

Let me describe the test conditions:

• Bar history goes from 2000.01.01 to 2012.01.01 on M1 as ordered
• The Expert Advisor works with short indicators of 10 000 bars, the history of indicators is trimmed to not go beyond 10 000 - 15 000 bars
  

As a result of automatic undercutting of the indicator we

• spoil cumulativity (this can be tolerated, although there will be jitter of results, which will lead to the inevitable - "yes in MT5 even the induks glitch!")
• we lose speed on the inevitable shift of the indicator history (memcopy is expensive, though the memory capacity is even more expensive)
  
• really blow the programmers' minds, who will manage to use memorized counters (this can be treated with personal care)
  

[Vladimir Gomonov]

Renat:

I will describe the conditions of the test:

• Bar history goes as ordered from 2000.01.01 to 2012.01.01 on M1
• the Expert Advisor works with short indicators of 10 000 bars, the history of indicators is trimmed in order not to go beyond 10 000 - 15 000 bars
  

As a result of automatic undercutting of the indicator we:

1.

• we spoil cumulativity (it can be tolerated, though there will be jitter of results, which will lead to the inevitable - "in MT5 even inductors glitch!")

Yes, it is tolerable. It will hardly cause mass discontent, on the contrary, the economy will be very attractive. No one forbids wasting the memory by installing a huge MaxBar.

// But indicators glitch due to skipping of bars! That is where the discontent is justified!

// So you tolerate even that... :) Well, we have to... :(

2.

• we lose speed on inevitable shift of indicator history (memcopy is expensive, but memory capacity is even more expensive)

That's exactly no and no! The circular scheme is exactly what leads to huge savings on copying on history shifts. Actually, when shifting by one bar (N bars), we have to copy exactly one value (N values). The(user) costs of index virtualization are negligible. In fact, they are even difficult to detect in stress tests(the remainder of division is calculated by the processor during one clock cycle + shifting of the virtual buffer start at every shift through history takes another couple of clock cycles). So, there's almost no speed loss. It's impossible to detect this slowdown, it's so small. And on the background of huge memory saving these losses are incommensurable with the gain.

3.

• We really blow the minds of programmers who manage to use memorized counters (this can be treated with personal caution)

I do not even understand what we are talking about here. Maybe it is just healthy in this place.

[x572intraday]

Ehhh, a face...

For some reason, there's so much dancing and shouting about indicators choking on unlimited bars, but not a word about dancing graphical objects. Try to build, for example, super big Andrews' Pitchfork on Unlimited (on MN1, for example), then limit the number of bars in the terminal settings, go to low timeframes and rewind to the anchor points. Some of them will be in a tremendous time lag from the extrema (this is while the pitchforks of all three points lie exclusively in the area of real M1-bars, without going beyond the boundary of fake ones from higher timeframes!) And why is that? Apparently, because we did not have enough historical data on M1 to calculate the exact M1-value of some autobinding points. But what do historical data have to do with it? Well, maybe they were enough, but the bars displayed in the window were not, hence the shifts. That is, some points "do not really know where they are".

I wish somebody would check it for themselves, or maybe I'm the only one who has such a mess...

[pusheax]

I have noticed an oddity!

At the moment of forming a new bar if you read Open and Close values of previous bars (for example 10 previous bars) and then 5 seconds later get them again, then some of these values are different and then if you get them while a new bar is forming then everything is ok, but in the first few seconds for some reason these values are different.

I hope I explained it clearly.

Can you tell me if before reading the values of Open and Close bars from the beginning of a new bar there should be a delay of more than 5 seconds?

Here is an example of operation:

Above is correctly triggered after a delay, below just after a new bar with an error, and on the right the benchmark for the 6th line.

[Aleksey Lebedev]

pusheax:

Perhaps the problem is unsynchronised, a new bar should preferably be tracked across all the instruments in use.

[pusheax]

Swan 2012.03.19 13:34 #

Perhaps the problem is unsynchronised, it's advisable to track the new bar across all the tools in use.

Yes, you turned out to be right, thank you!

[Andrey F. Zelinsky]

I don't understand. Either I have a problem or I don't. When I clicked on "reply" in the editor window that appeared, the relevant post was duplicated as a quote. Now a couple of days ago, that feature is gone. Opens an empty window. Tried in Opera and IE.

[[Deleted]]

Similarly, opera.

[Vladimir Gomonov]

220Volt:
Similarly, opera.

I'm fine in FF.