Errors, bugs, questions - page 1335

 

In the source code of the Fractals.mq5 indicator, there are such entries for calculation of fractals (lines 74 and 79):

//---- Upper Fractal
if(high[i]>high[i+1] && high[i]>high[i+2] && high[i]>= high[i-1] && high[i]>= high[i-2])

//---- Lower Fractal
if(low[i]<low[i+1] && low[i]<low[i+2] && low[i]<= low[i-1] && low[i]<= low[i-2])

In these calculations, I am confused by equal signs in >= and <= (in red).

I always thought that an upward fractal is formed when, in a combination of at least five bars, the average bar has the highest maximum, i.e. is always higher (not higher or equal) to the two neighbouring highs on the left and right sides. With the fractal downwards respectively. In the above part of the code you can see that equality is allowed. Please check if there is an error in the Fractals.mq5 code.

 

I have a signal, the monitoring shows a 100 per cent dump, the account is fine, I have been knocking on the phone for three days, both to Service Desk and to the company's staff. No answer...

How to solve the problem....?

 
Stanislav Olhovsky:

I have a signal, the monitoring shows a 100 per cent dump, the account is fine, I have been knocking on the phone for the third day, both to Service Desk and to the company's staff. No answer...

How to solve the problem....?

You should not withdraw more than you earned, then the balance curve will not go to zero.
 

I've written to "Innovations in favourites" and there is silence. I'll write here:

Windows 10 x64, Mozilla Firefox 39.0. I can't send attached images or files to my personal account...

 
Karputov Vladimir:
You should not withdraw more than earned, then the balance curve will not go to zero.

The signal has been working for almost 4 months, only ribate additions, no one has withdrawn anything there, everything was normal, stable growth... In the terminal, the data is normal and in another online monitoring ....

Screenshot from mybook attached, everything is normal there.

Answer from broker, the history is stored for 1 month, but then two or three months ago on signals would have been the same...

Files:
Error.png  36 kb
 
It's all about the "private" again. The joints continue...
 

Dear developers!

Bands indicator and iBands indicator have different readings. In the Bands indicator the standard deviation is calculated using the StdDev_Func function, while in the iBands it is calculated using the GetData method. When comparing how the chart is drawn, we can see a big difference in the state of the buffers responsible for deviation levels. I faced this problem in MQL4, perhaps it is the same in MQL5.

 

I hadn't paid much attention to it before, but now, when working with large arrays of class objects, I noticed a too large memory consumption. I checked it by sizeof() and an absolutely empty class takes 16 bytes. And considering that the classes here are managed, we add 8 more bytes per pointer. The total is 24 bytes. It is too expensive.

I looked through the documentation and saw what I've found there:

объекты классов всегда имеют таблицу виртуальных функций, даже если в классе не объявлено ни одной виртуальной функции.

The question is why simple classes (those not participating in inheritance) need the virtual function table, since everything is known about these classes at the compilation stage.

It turns out that methods in them are called in the same way as virtual methods, i.e. there is additional redirection of access through the table. And where is the praised compiler optimization? How can we state after this some comparison of performance with C++?

 

You are wrong.

If a method is not described as virtual, it is called directly. In addition, there are optimizations to remove virtuality. The destructor is always virtual, which leads to a virtual table.

About 24 bytes is a strange statement - object reference does not refer to size.

Classes in managed/secure languages always contain metainformation, so it's all reasonable here. If you want pure size, use structures.

 
Renat Fatkhullin:

The destructor is always virtual, which results in a virtual table.

So why shouldn't the destructor be optimized? It's only because of the destructor that extra 8 bytes are stored...

The 24 bytes is a strange statement - object reference is not related to size.

Well, I just don't know how everything is implemented there. Suppose you have an array of objects:

CObj array[];

Does the system store references (pointers) for each element?

If you want pure size, use structures.

But you can't take a pointer to a structure and that reduces the convenience of using it. That's why you have to make a painful choice sometimes... If you managed to reduce the class size, that would be wonderful. And if you have a pointer to the structure too, everything will be fine.)