그들은 복잡하지만 빠른 지표를 작성하지 않았기 때문에 그렇지 않으면 왼쪽에서 오른쪽으로 인덱싱하는 것이 매우 중요한 작업에 대한 솔루션이 될 것입니다.
네, 요소에 접근하는 속도에는 차이가 없습니다. 한 경우에는 void* first+sizeof(T)*index이고 다른 경우에는 last-sizeof(T)*index입니다. 컨테이너의 전면 및 후면 메서드는 항상 복잡합니다. mql의 배열이 본질적으로 컨테이너라는 사실이 문제가 되지 않기를 바랍니다.
표시기를 왼쪽에서 오른쪽으로 계산하면 예를 들어 프랙탈이 형성된 경우와 같이 이벤트가 발생한 경우 이 이벤트가 있는 막대의 인덱스를 기억해야 합니다(나중에 사용할 수 있도록). 인덱싱이 오른쪽에서 왼쪽으로 수행되는 경우 n=Bars-i 계산을 수행하고 n을 기억한 다음 그 반대인 i=Bars-n을 기억해야 합니다. 그리고 인덱싱이 왼쪽에서 오른쪽으로 하면 인덱스만 기억하고 사용하면 바뀌지 않습니다. 이것의 필요성은 다소 복잡한 지표에서 항상 발생하기 때문에 왼쪽에서 오른쪽으로 인덱싱하는 것은 지표 작성자의 작업에서 더 큰 안도입니다.
Vladimir Simakov : 네, 요소에 접근하는 속도에는 차이가 없습니다. 한 경우에는 void* first+sizeof(T)*index이고 다른 경우에는 last-sizeof(T)*index입니다. 컨테이너의 전면 및 후면 메서드는 항상 복잡합니다. mql의 배열이 본질적으로 컨테이너라는 사실이 문제가 되지 않기를 바랍니다.
예를 들어볼까요?
잠시만 기다려 주십시오. 여기 코드 베이스에 게시하겠습니다. 그러면 내 사이트에 대한 링크가 어쨌든 삭제됩니다.
그렇다면 왜 이 접근법이 실행되지 않습니까? 어떤 이유에서인지 표시기를 작성하는 대다수의 사람들은 mql4에서와 같이 배열 인덱싱을 반대로 하기도 합니다.
그들은 복잡하지만 빠른 지표를 작성하지 않았기 때문에 그렇지 않으면 왼쪽에서 오른쪽으로 인덱싱하는 것이 매우 중요한 작업에 대한 솔루션이 될 것입니다.
그렇다면 왜 이 접근법이 실행되지 않습니까? 어떤 이유에서인지 표시기를 작성하는 대다수의 사람들은 mql4에서와 같이 배열 인덱싱을 반대로 하기도 합니다.
그들은 복잡하지만 빠른 지표를 작성하지 않았기 때문에 그렇지 않으면 왼쪽에서 오른쪽으로 인덱싱하는 것이 매우 중요한 작업에 대한 솔루션이 될 것입니다.
그들은 복잡하지만 빠른 지표를 작성하지 않았기 때문에 그렇지 않으면 왼쪽에서 오른쪽으로 인덱싱하는 것이 매우 중요한 작업에 대한 솔루션이 될 것입니다.
그리고 최신 것부터 오른쪽으로 인덱싱하는 것의 단점은 무엇입니까?
그들은 복잡하지만 빠른 지표를 작성하지 않았기 때문에 그렇지 않으면 왼쪽에서 오른쪽으로 인덱싱하는 것이 매우 중요한 작업에 대한 솔루션이 될 것입니다.
그리고 최신 것부터 오른쪽으로 인덱싱하는 것의 단점은 무엇입니까?
표시기를 왼쪽에서 오른쪽으로 계산하면 예를 들어 프랙탈이 형성된 경우와 같이 이벤트가 발생한 경우 이 이벤트가 있는 막대의 인덱스를 기억해야 합니다(나중에 사용할 수 있도록). 인덱싱이 오른쪽에서 왼쪽으로 수행되는 경우 n=Bars-i 계산을 수행하고 n을 기억한 다음 그 반대인 i=Bars-n을 기억해야 합니다. 그리고 인덱싱이 왼쪽에서 오른쪽으로 하면 인덱스만 기억하고 사용하면 바뀌지 않습니다. 이것의 필요성은 다소 복잡한 지표에서 항상 발생하기 때문에 왼쪽에서 오른쪽으로 인덱싱하는 것은 지표 작성자의 작업에서 더 큰 안도입니다.
네, 요소에 접근하는 속도에는 차이가 없습니다. 한 경우에는 void* first+sizeof(T)*index이고 다른 경우에는 last-sizeof(T)*index입니다. 컨테이너의 전면 및 후면 메서드는 항상 복잡합니다. mql의 배열이 본질적으로 컨테이너라는 사실이 문제가 되지 않기를 바랍니다.
그리고 요소에 대한 액세스 속도는 어디입니까?
예를 들어볼까요?
여기 예가 있습니다.
예를 들어볼까요?
https://www.mql5.com/en/code/25807