MT4 iMAOnArray and iBandsOnArray effect of number of elements on calculations - page 5

New comment
 
Dmitry Fedoseev:
Even though MODE_SMA is the same, it's still not a good idea to use it.

I understand this very well, and I've even written above why not. I've been programming since '96, I started trying MQL somewhere in 2009-10 when I discovered MT after other terminals :).
So I know the rules of "good and correct code" :)

 
Dmitry Fedoseev:
Even though MODE_SMA matches, you still shouldn't use it.

Can you think of any reason why you shouldn't use it?

Or is there only one reason, as always, spread fingers in the way?

Not only MODE_SMA matches but all other sliding methods as well. And even if period of iMAOnArray() doesn't coincide with period of iBandsOnArray() there's no need to double copy a part of buffer array to user array, you just should understand what happens when these functions are called.

 
Alexey Viktorov:

Can you think of any reason why you shouldn't use it?

Or is there only one reason, as always, spread fingers in the way?

Not only MODE_SMA matches, but all other sliding methods as well. And even if period of iMAOnArray() doesn't coincide with period of iBandsOnArray() there's no need to copy a part of buffer array to user array twice, you just should understand what happens when these functions are called.

I pointed out the reasons for the discrepancy in my message on page 4. If you don't take your word for it, put the original on the M1 chart and your version below, enter LWMA smoothing for the MA and a period of 100, leaving a period of 12 for the Bands.
 
Alexey Viktorov:

Can you think of any reason why you shouldn't use it?

...

I can. But I don't want to.
 
Dmitry Fedoseev:
I can. But I don't want to.
You don't see my answer either? I've pointed out why you shouldn't use it.
 
Sergey Efimenko:
I described the reasons for inconsistency in my post on page 4. If you do not take your word for it, set the original one on M1 chart and your version below, enter LWMA smoothing for MA and period 100.

Sergey, I did not immediately understand the reason for all your manipulations, in the normal way there is no need to do such tricks. If you want to limit the history for recalculation, there are other ways to do it, and use these functions for the entire array, that is, where you want to put 300 you can safely put 0 and there won't be any brakes.

And once again I will try to explain that referring to "you" with all respect and kindness is much better than "you" with a small letter and the address where "you" are being sent.

 
Sergey Efimenko:
You don't see my answer either? I pointed out why you shouldn't use it.
I do. But that question was for me personally.
 
Dmitry Fedoseev:
I can. But I don't want to.

You're doing the right thing or you'll break your fingers. Take it easy.


ps; wait for an answer, I'm going to rest...

 
Alexey Viktorov:
You're doing the right thing or you'll break your fingers. Take it easy.
You're so stubborn, but keep at it, you might break your horns someday.
 
Alexey Viktorov:

Sergey, I did not immediately understand the reason for all your manipulations, in the normal way there is no need to do such tricks. If you want to limit the history for recalculation, there are other ways to do it, and use these functions for the whole array, that is, where you want to put 300 you can safely put 0 and there won't be any brakes.

And again you are wrong, the topic was caused by slowness when calculating the full array. When starting the terminal or switching between the TFs with a slightly more complex indicator installed, but based on the functions mentioned here, it actually causes unacceptable braking. In general, the answer is clear that the functions work only when calculating the full array but in this form unacceptably slows down the terminal. The calculation was based on the fact that someone managed to get the required value from these functions with an "incomplete" array without losing the overall performance.
123456789
New comment