물론 작동하지만 브레이크는 끔찍합니다. 보조 표시기의 계산을 주 표시기로 전송할 필요가 있습니다. 일반적으로 계산을 최적화하는 것이 좋습니다.
도움을 주셔서 대단히 감사합니다!!! 그리고 이벤트 과정에서 또 다른 질문은 계산을 최적화할 수 있는 방법과 MACD가 특정 한계 내로 들어가도록 정상화하는 최선의 방법은 무엇입니까? 내가 재료와 프로그래밍과 거리가 멀기 때문에 더 적합한 것을 찾을 수 있었던 것은 위의 노멀라이저뿐입니다. :)
도움을 주셔서 대단히 감사합니다!!! 그리고 이벤트 과정에서 또 다른 질문은 계산을 최적화할 수 있는 방법과 MACD가 특정 한계 내로 들어가도록 정상화하는 최선의 방법은 무엇입니까? 내가 재료와 프로그래밍과 거리가 멀기 때문에 더 적합한 것을 찾을 수 있었던 것은 위의 노멀라이저뿐입니다. :)
도움을 주셔서 대단히 감사합니다!!! 그리고 이벤트 과정에서 또 다른 질문은 계산을 최적화할 수 있는 방법과 MACD가 특정 한계 내로 들어가도록 정상화하는 최선의 방법은 무엇입니까? 내가 재료와 프로그래밍과 거리가 멀기 때문에 더 적합한 것을 찾을 수 있었던 것은 위의 노멀라이저뿐입니다. :)
코드베이스에 게시된 변형을 사용하고 있습니다. 이는 단지 개념일 뿐이며 속도에 최적화되어 있지 않습니다. 실제 사용을 위해 외부 변수에서 특성 기간 변수를 수동으로 설정하고 지정된 기간 동안 주 지표의 3-4 완전한 주기가 발생하도록 선택하는 것이 좋습니다.
개인적으로 더 자주 사용하는 또 다른 옵션은 외부에서 실행 날짜 수를 설정하고 표시기 본문에 이미 있는 특성 기간에서 다시 계산하는 것입니다.
...externdouble days_for_normalization =3;// например, смотрим за три дня...int init (){...
characteristic_period =1440./Period()* days_for_normalization ;// 1440 - это количество минут в сутках}
일반적으로 말하면 Vinin이 맞습니다. 두 번째 지표의 코드를 첫 번째 지표에 삽입하면 계산이 정말 빨라집니다. 여기서 불편한 점은 더 많은 코딩을 해야 하고(코드베이스에서 가져온 것은 이 작업을 단순화할 수 있는 방법을 보여주기 위한 목표 중 하나일 뿐이었습니다) 두 번째 칠면조가 첫 번째 버퍼를 차지한다는 것입니다. 항상 그런 것은 아닙니다. 허용됩니다.
안녕하세요! 제 칠면조는 매일 그림을 그리는 것을 싫어해서 계속 프레임을 바꿔가며 마지막 바까지 업데이트 해야 하는 거 아시는 분들의 도움을 구합니다 이 단점을 어떻게 고칠 수 있을까요? 미리 감사드립니다!!!
두 번째 표시기가 없으면 여전히 확인할 수 없습니다.
두 번째 표시기가 없으면 여전히 확인할 수 없습니다.
소리! 수정합니다 :)
소리! 수정합니다 :)
물론 작동하지만 브레이크는 끔찍합니다. 보조 표시기의 계산을 주 표시기로 전송할 필요가 있습니다. 일반적으로 계산을 최적화하는 것이 좋습니다.
물론 작동하지만 브레이크는 끔찍합니다. 보조 표시기의 계산을 주 표시기로 전송할 필요가 있습니다. 일반적으로 계산을 최적화하는 것이 좋습니다.
도움을 주셔서 대단히 감사합니다!!! 그리고 이벤트 과정에서 또 다른 질문은 계산을 최적화할 수 있는 방법과 MACD가 특정 한계 내로 들어가도록 정상화하는 최선의 방법은 무엇입니까? 내가 재료와 프로그래밍과 거리가 멀기 때문에 더 적합한 것을 찾을 수 있었던 것은 위의 노멀라이저뿐입니다. :)
도움을 주셔서 대단히 감사합니다!!! 그리고 이벤트 과정에서 또 다른 질문은 계산을 최적화할 수 있는 방법과 MACD가 특정 한계 내로 들어가도록 정상화하는 최선의 방법은 무엇입니까? 내가 재료와 프로그래밍과 거리가 멀기 때문에 더 적합한 것을 찾을 수 있었던 것은 위의 노멀라이저뿐입니다. :)
많은 최적화 옵션이 있습니다. 나는 코드에 너무 많이 들어가지 않았다.
도움을 주셔서 대단히 감사합니다!!! 그리고 이벤트 과정에서 또 다른 질문은 계산을 최적화할 수 있는 방법과 MACD가 특정 한계 내로 들어가도록 정상화하는 최선의 방법은 무엇입니까? 내가 재료와 프로그래밍과 거리가 멀기 때문에 더 적합한 것을 찾을 수 있었던 것은 위의 노멀라이저뿐입니다. :)
코드베이스에 게시된 변형을 사용하고 있습니다. 이는 단지 개념일 뿐이며 속도에 최적화되어 있지 않습니다. 실제 사용을 위해 외부 변수에서 특성 기간 변수를 수동으로 설정하고 지정된 기간 동안 주 지표의 3-4 완전한 주기가 발생하도록 선택하는 것이 좋습니다.
개인적으로 더 자주 사용하는 또 다른 옵션은 외부에서 실행 날짜 수를 설정하고 표시기 본문에 이미 있는 특성 기간에서 다시 계산하는 것입니다.
그것은 작동하지 않습니다 .. 여기를 읽으십시오 모든 사람이 그런 조언자를 가지고 있지만 나는 MM 만 있습니다. 나는 단지 작은 매트가 기다리고있을 것입니다 + .... 어 ...
그리고 장기간에 걸친 최적화 없이 -0.12의 매트 기대치가 정상적인 상황입니까? 내 말은, 모든 사람이 최적화 없이 하고 나서 기대치를 조정하기만 하면 높아지는 것인가, 아니면 이것이 선택사항이 아니고 어드바이저를 완전히 바꿔야 하는 것인가?