Errors, bugs, questions - page 1805
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
@Slawa, please clarify, are there any restrictions on writing the indicator buffers outside the OnCalculate() function? In case of writing buffers in OnTimer(), OnBookEvent(), OnChartEvent() functions, will everything always be written correctly?
But you can run into buffers redistribution at the moment of adding a new bar (redistribution is performed with a reserve, so not on each new bar).
PS though no. all processing is in one thread, so there should be no collisions. Try
There are no obvious limitations. Try it.
But you can run into buffer redistribution at the moment of adding new bar (redistribution is performed with some reserve, so not on every new bar)
Here, more details, please. What is the allocation, how to deal with it?
Just wrote the question because I notice "hiccups" on a new bar. And these hiccups reset buffer values = 0 (with the empty value I explicitly set - EMPTY_VALUE). So far I haven't managed to catch this moment. Sometimes the indicator just "jumps" and immediately restores to normal, sometimes it just "freezes". When stuck the values are not written to the file and buffers are not drawn. The buffers are written to OnBookEvent().
The same code works fine in OnCalculate(), but OnCalculate() does not allow to collect all values of Open Interest and other exchange parameters.
It can be solved only by TF switching. Yes, 5-7 same indicators running at the same time, writing different data.
Added:
Yeah, also noticed the exact same thing today when turning on the terminal. Everything just hung, all buffers, all values have zeros on them, no history (written to file) was given out by the indicator. In other words, everything just hung up. The market was still closed. I changed TF - the history came back, but again, to the question about the need of a time stamp to the values of SESSION: the last known value at the time of terminal closing was recorded! Synchronization of the history was successful, no errors. But TimeCurrent() returned an erroneous value (about 21:03). The real time of this value is 23:49:59. All in all, some kind of sadness.
Here, more details, please. What is the allocation, how should it be handled?
Just wrote the question because I notice "hiccups" on a new bar. And these hiccups null buffer values = 0 (with the empty value set explicitly by me - EMPTY_VALUE). So far I haven't managed to catch this moment. Sometimes the indicator just "jumps" and immediately restores to normal, sometimes it just "freezes". When stuck the values are not written to the file and buffers are not drawn. The buffers are written to OnBookEvent().
The same code works fine in OnCalculate(), but OnCalculate() does not allow to collect all values of Open Interest and other exchange parameters.
It can be solved only by TF switching. Yes, 5-7 same indicators are running simultaneously, writing different data.
We reallocate the buffer to 1250 bars and copy 1000 bars from the previous buffer to the new buffer. Put the new buffer in place of the old buffer, delete the old buffer. We add the 1001st bar.
What do you mean by "what to do with it"?
Keep in mind that all indicators of one symbol are counted sequentially one after another in one thread. If one indicator slows down, the entire thread of symbol processing will also slow down
Easy. The first tick of the new bar arrives. The buffer is allocated for 1000 bars and is completely full.
We reallocate the buffer to 1250 bars and copy 1000 bars from the old buffer to the new buffer. Put the new buffer in place of the old buffer, delete the old buffer. We add the 1001st bar.
What do you mean by "what to do with it"?
Keep in mind that all indicators of one symbol are counted sequentially one after another in one thread. If an indicator slows down, the entire thread of symbol processing will also slow down
I'm aware of the single thread thing. And redistribution, as I understand it, affects OnBookEvent() more than OnCalculate()?
But, until the indicator (any indicator on this symbol!) finishes its calculations (OnCalculate, OnTimer, OnChartEvent, OnBookEvent), the new tick won't arrive to the processing.
Redistribution is performed at a new tick arrival. Immediately after a new tick arrives out of the queue , OnCalculate is called. And only after that the processing of events, received by the indicator, is continued
However, until the indicator (any indicator on this symbol!) finishes its calculations (OnCalculate, OnTimer, OnChartEvent, OnBookEvent), a new tick won't arrive to be processed.
Also, as far as I understand, indicators on one symbol are calculated sequentially, i.e. if I have thrown i1, i2, i3 indicator in a row, then they will be calculated in the same order?
I have now added a standard MAKD for testing; it is the last one in the list. I will see if it slows down when a new bar is formed.
Also, as far as I understand, indicators on one symbol are calculated sequentially, i.e. if I have thrown i1, i2, i3 indicator in a row, then they will be calculated in the same order?
Now I added a standard MAKD for testing, it is the last one in the list. I will see if it hangs on it when a new bar is formed.
But if you will delete-add different indicators, the sequence of recalculation may surprise you. Therefore, do not rely on the sequence
At first, yes, the calculation will be in the same sequence.
But if you delete-add different indicators, the sequence of recalculation may surprise you. So don't rely on the sequence.
This is what I was talking about:
A new bar was formed on GOLD-3.17, all my indicators calculated in OnBookEvent() by this symbol all current values were zeroed. According to the logic of the indicator, at the time of forming a new bar, the buffers are not zeroed, and the current value is written to them immediately. MACD is not zeroed. The log is empty, it means that there was no unsynchronization, all values should be correct. In this case the glitch lasted for about 5 seconds. Yesterday I was catching glitches for several minutes at a time.
All other characters were fine. Again, the logic of the indicator does not reset the values to 0! So the question is: when redistributing new items, in theory, should contain rubbish. But here 0.0 and hangs...
Yes, one more thing: if one indicator hung, the others should have kept their values! But all of them, all at once, zeroed out. Are there any situations where this could happen?A similar hang-up has occurred on BR-3.17:
@Slawa any idea which way to dig? Maybe there is a better way to collect exchange data and display it?