MT4 iMAOnArray 및 iBandsOnArray 계산에 대한 요소 수의 영향 - 페이지 9

 
Dmitry Fedoseev :
또는 EMA
예, SMMA 및 EMA에 대해서만 LWMA와 혼동했습니다. 이전 값은 관련이 있습니다.
 
Sergey Efimenko :
예, SMMA 및 EMA에 대해서만 LWMA와 혼동했습니다. 이전 값은 관련이 있습니다.

Sergey, 하지만 코드에서 LWMA 방식이 사용되었는지 또는 가능한 모든 것을 저주하려는 욕구가 그 기적처럼 눈을 흐리게 하는지 명확하지 않습니다 ...

그리고 종교는 다른 방법으로 다시 컴파일하는 것을 허용하지 않습니까? 그래서 코드를 배치하여 주제를 계속하고 싶지 않았습니다.

귀하의 이 게시물을 기반으로

세르게이 에피멘코 :
이제 LWMA 또는 SMMA 직선 스무딩 모드 에서 코드의 결과와 원본을 비교하고 다른 값을 얻습니다. 계산에서 이 두 가지 유형의 평활화는 고유한 이전 값을 사용하고 매번 기간의 N 요소만 사용하면 따라서 이 데이터를 잃게 됩니다. 또한 결국 iBand와 iMA에 대해 서로 다른 계산 기간이 필요하므로 두 번 복사해야 합니다. 또한 계산을 위한 원래 배열이 동일하게 사용됩니다. 당신의 추론의 논리는 나에게 분명하지만 그것은 잘못된 것입니다. 왜냐하면 배열의 길이를 줄이면서 동시에 복사본을 만들고 모든 요소를 매번 다시 계산하면 최적화할 때 결국 총 표시기 계산 시간을 늘리기 때문입니다. 또는 다양한 기간 동안 여러 버전의 지표를 사용하여 온라인으로 작업합니다. 필자의 경우 초기화 중 초기 계산만 느려지고 새 요소는 1개만 고려됩니다. 문제는 MQL에서 이러한 기능을 구현하는 데 있습니다. 자체 작성 옵션이 더 빠르고 더 잘 작동합니다. 자신의 결론을 도출하십시오.

LWMA에 확인해보니...

그것으로, 나는 이 스레드를 떠납니다. Dmitry와 함께 감히.

 
Alexey Viktorov :

Sergey, 하지만 코드에서 LWMA 방식이 사용되었는지 또는 가능한 모든 것을 저주하려는 욕구가 그 기적처럼 눈을 흐리게 하는지 명확하지 않습니다 ...

그리고 종교는 다른 방법으로 다시 컴파일하는 것을 허용하지 않습니까? 그래서 코드를 배치하여 주제를 계속하고 싶지 않았습니다.

귀하의 이 게시물을 기반으로

LWMA에 확인해보니...

그것으로, 나는 이 스레드를 떠납니다. Dmitry와 함께 감히.

사실 아무 탓도 하지 않지만 제시된 코드의 논리에 오류가 있음을 보여주고 두 번째 예제를 작성할 때 EMA와 LWMA를 섞어서 EMA로 시도해야 했지만 SMMA가 더 좋았기 때문에 나중에 그러한 모욕은 일어나지 않을 것입니다. 또한 이러한 스무딩 유형과 데이터가 일치하지 않는 이유를 이미 여러 번 설명했으며 자연스럽게 SMMA 또는 EMA와 함께 시도하여 사용시 캐치가 무엇인지보고 이해할 수 있도록 제안했습니다. 추가 배열뿐만 아니라 복사해야 할 때마다 결과를 매끄럽게 하는 일부 유형(방법)의 "복잡성"(기능)도 고려해야 합니다.

일반적으로 주제는 누군가의 성격에 초점을 맞추는 것이 아니라 데이터 평활화 과정을 이해하고 모든 사람을 위한배열 인덱싱 의 방향을 이해하는 것입니다. 아마도 누군가는 자신의 새로운 지평을 발견할 것입니다.