그리고 표시기가 5-버퍼인 경우 첫 번째 iCustom 호출은 모든 버퍼를 계산하고 다른 버퍼에 대한 후속 호출 및 요청은 미리 만들어진 정보(계산을 위한 새 데이터가 나타날 때까지)만 읽습니다.
저것들. 프로그램에서 표시기를 한 번 이상 호출한 경우 요청된 버퍼에 대한 정보뿐 아니라 표시기에 포함된 모든 정보도 수신했습니까? 또는 요점은 다른 버퍼의 계산이 메모리에서 발견되고 이로 인해 재계산이 없다는 것입니다. 프로그램(프로그램(EA) 표시기의 데이터를 저장하기 위해 메모리를 명시적으로 할당하지 않음) . 나는 표시기에 액세스할 때마다 다시 계산된다는 것을 읽었습니다. 그렇지 않은 것으로 나타났습니까?
퇴비통 :
매우 무거운 지표가 있는 경우, 첫 번째 실행에서 데이터가 계산 되어 파일에 기록 되고 후속 실행에서는 읽기만 가능하도록 고유한 캐시 시스템을 마련하십시오. 나는 이것을했고 훨씬 빨리 밝혀졌습니다.
그러나 95%의 경우 이 모든 것이 필요하지 않으며 테스터는 이미 충분히 빠르며 5-ke에서는 클라우드를 연결할 수도 있습니다.
행운을 빕니다!
하드 드라이브에서 읽는 것이 더 빠를 것인가, 아니면 계산된 지표 데이터로 메모리에 가상 디스크를 만들 것인가?
글쎄요, 저는 5개만 꿈꿉니다. 지금까지는 4개만 주문할 수 있는 아이디어를 구현하고 있습니다.
매우 무거운 지표가 있는 경우, 첫 번째 실행에서 데이터가 계산 되어 파일에 기록 되고 후속 실행에서는 읽기만 가능하도록 고유한 캐시 시스템을 마련하십시오. 나는 이것을했고 훨씬 빨리 밝혀졌습니다.
그러나 95%의 경우 이 모든 것이 필요하지 않으며 테스터는 이미 충분히 빠르며 5-ke에서는 클라우드를 연결할 수도 있습니다.
행운을 빕니다!
지표에 관한 것이 아니라 고문에 관한 것이지만 주제는 가깝습니다. 내 스캘퍼는 모든 종류의 필터, 변형을 상당히 많이 계산합니다. 나는 즉시 Matlab의 모델에 대해 그러한 캐시를 만들었습니다. 먼저 모든 수학이 계산되어 .mat 파일에 덤프된 다음 이 데이터를 사용하여 전략이 실행되었습니다. 이제 내 손은 MQL4 테스터에 대해 동일한 작업을 수행하고 싶어 가렵습니다. 그렇지 않으면 최적화가 단순히 비현실적입니다.
저것들. 프로그램에서 표시기를 한 번 이상 호출한 경우 요청된 버퍼에 대한 정보뿐 아니라 표시기에 포함된 모든 정보도 수신했습니까? 또는 요점은 다른 버퍼의 계산이 메모리에서 발견되고 이로 인해 재계산이 없다는 것입니다. 데이터는 프로그램(프로그램(EA) 표시기의 데이터를 저장하기 위해 메모리를 명시적으로 할당하지 않음) . 나는 표시기에 액세스할 때마다 다시 계산된다는 것을 읽었습니다. 그렇지 않은 것으로 나타났습니까?
표시기는 하나의 버퍼만 계산할 수 없으며 호출 시 버퍼 안에 있는 모든 것을 계산합니다. 매개변수로 계산을 제한할 수 없다면 이것은 또 다른 주제입니다.
재계산은 각 호출에서 발생하지만 일반적으로 0번째 막대만 재계산됩니다. 그리고 Advisor도 올바르게 작성되었다면 이러한 호출은 모든 틱 에서 발생하지 않습니다.
-알렉스 - :
하드 드라이브에서 읽는 것이 더 빠를 것인가, 아니면 계산된 지표 데이터로 메모리에 가상 디스크를 만들 것인가?
나는 일반 디스크에서 읽었지만 각 막대의 표시기 값이 아니라 "시간, 신호"줄에서 이러한 데이터가 훨씬 덜 필요합니다.
모든 지표에 대한 보편적인 솔루션이 있을 가능성은 거의 없으며 글로벌 작업에서 시작해야 합니다.
-알렉스 - :
글쎄요, 저는 5개만 꿈꿉니다. 지금까지는 4개만 주문할 수 있는 아이디어를 구현하고 있습니다.
그리고 이것은 헛된 것입니다. 이제 하나의 파일에 두 플랫폼에 대한 코드를 작성할 수 있습니다. 차이점은 거래 부분과 시계열(지표 포함) 작업에만 있습니다.
VDev : 지표에 관한 것이 아니라 고문에 관한 것이지만 주제는 가깝습니다. 내 스캘퍼는 모든 종류의 필터, 변형을 상당히 많이 계산합니다. 나는 즉시 Matlab의 모델에 대해 그러한 캐시를 만들었습니다. 먼저 모든 수학이 계산되어 .mat 파일에 덤프된 다음 이 데이터를 사용하여 전략이 실행되었습니다. 이제 내 손은 MQL4 테스터에 대해 동일한 작업을 수행하고 싶어 가렵습니다. 그렇지 않으면 최적화가 단순히 비현실적입니다.
별도의 지표에 대한 캐시를 갖는 것은 거의 의미가 없으며 조언자에서 필요한 데이터에서 시작했습니다.
지표의 OnCalculate()는 새로운 가격에 대해 iCustom()이 처음 호출될 때만 호출됩니다. iCustom()에 대한 후속 호출은 OnCalculate() 함수를 실행하지 않고 데이터만 수신합니다. 가격이 변경되고 iCustom()에 대한 다음 호출이 onCalculate() 를 트리거 하고 후속 호출은 가격이 변경될 때까지 데이터만 수신하는 식으로 계속 진행됩니다. (지금 실험적으로 테스트되었습니다).
따라서 결국 많은 버퍼가 있는 하나의 표시기에 액세스하고 그 중 하나에서 모든 버퍼에 대한 정보를 얻으면 이 표시기를 몇 배나 계산하는 것보다 더 빠르고 메모리 효율적입니다. 다른 버퍼의 정보가 필요합니까?
5개의 버퍼에 대한 1개의 표시기 또는 1개의 버퍼에 대한 5개의 표시 - 거의 동일합니다. 2개의 버퍼에서만 정보가 필요한 경우 5개의 버퍼가 있는 하나의 표시기보다 1개의 버퍼가 있는 2개의 표시기를 호출하는 것이 더 유리합니다. 그러나 2개의 버퍼가 있는 하나의 지표보다 수익성이 좋지 않습니다.
-알렉스 - :
그럼에도 불구하고 누군가가 실험을 할 것입니다. 그렇지 않으면 아이디어가 나를 놓지 않습니다!? 아니면 혁신 연구는 유료로만 흥미로운가요?
퇴비통 :
이 접근 방식은 표시기의 메모리 소비(전후 버퍼 수 차이의 대략 배수)를 줄이지만 프로세서의 부하를 증가시킵니다("어셈블리"와 "분해" 모두 지속적으로 수행되어야 함).
메모리 제한에 도달하지 않으면(현재 볼륨에서는 거의 발생하지 않음) 속도가 느려질 뿐입니다.
그리고 표시기가 5-버퍼인 경우 첫 번째 iCustom 호출은 모든 버퍼를 계산하고 다른 버퍼에 대한 후속 호출 및 요청은 미리 만들어진 정보(계산을 위한 새 데이터가 나타날 때까지)만 읽습니다.
저것들. 프로그램에서 표시기를 한 번 이상 호출한 경우 요청된 버퍼에 대한 정보뿐 아니라 표시기에 포함된 모든 정보도 수신했습니까? 또는 요점은 다른 버퍼의 계산이 메모리에서 발견되고 이로 인해 재계산이 없다는 것입니다. 프로그램(프로그램(EA) 표시기의 데이터를 저장하기 위해 메모리를 명시적으로 할당하지 않음) . 나는 표시기에 액세스할 때마다 다시 계산된다는 것을 읽었습니다. 그렇지 않은 것으로 나타났습니까?
매우 무거운 지표가 있는 경우, 첫 번째 실행에서 데이터가 계산 되어 파일에 기록 되고 후속 실행에서는 읽기만 가능하도록 고유한 캐시 시스템을 마련하십시오. 나는 이것을했고 훨씬 빨리 밝혀졌습니다.
그러나 95%의 경우 이 모든 것이 필요하지 않으며 테스터는 이미 충분히 빠르며 5-ke에서는 클라우드를 연결할 수도 있습니다.
행운을 빕니다!
하드 드라이브에서 읽는 것이 더 빠를 것인가, 아니면 계산된 지표 데이터로 메모리에 가상 디스크를 만들 것인가?
글쎄요, 저는 5개만 꿈꿉니다. 지금까지는 4개만 주문할 수 있는 아이디어를 구현하고 있습니다.
행운을 빌어 주셔서 감사합니다!
매우 무거운 지표가 있는 경우, 첫 번째 실행에서 데이터가 계산 되어 파일에 기록 되고 후속 실행에서는 읽기만 가능하도록 고유한 캐시 시스템을 마련하십시오. 나는 이것을했고 훨씬 빨리 밝혀졌습니다.
그러나 95%의 경우 이 모든 것이 필요하지 않으며 테스터는 이미 충분히 빠르며 5-ke에서는 클라우드를 연결할 수도 있습니다.
행운을 빕니다!
저것들. 프로그램에서 표시기를 한 번 이상 호출한 경우 요청된 버퍼에 대한 정보뿐 아니라 표시기에 포함된 모든 정보도 수신했습니까? 또는 요점은 다른 버퍼의 계산이 메모리에서 발견되고 이로 인해 재계산이 없다는 것입니다. 데이터는 프로그램(프로그램(EA) 표시기의 데이터를 저장하기 위해 메모리를 명시적으로 할당하지 않음) . 나는 표시기에 액세스할 때마다 다시 계산된다는 것을 읽었습니다. 그렇지 않은 것으로 나타났습니까?
표시기는 하나의 버퍼만 계산할 수 없으며 호출 시 버퍼 안에 있는 모든 것을 계산합니다. 매개변수로 계산을 제한할 수 없다면 이것은 또 다른 주제입니다.
재계산은 각 호출에서 발생하지만 일반적으로 0번째 막대만 재계산됩니다. 그리고 Advisor도 올바르게 작성되었다면 이러한 호출은 모든 틱 에서 발생하지 않습니다.
하드 드라이브에서 읽는 것이 더 빠를 것인가, 아니면 계산된 지표 데이터로 메모리에 가상 디스크를 만들 것인가?
나는 일반 디스크에서 읽었지만 각 막대의 표시기 값이 아니라 "시간, 신호"줄에서 이러한 데이터가 훨씬 덜 필요합니다.
모든 지표에 대한 보편적인 솔루션이 있을 가능성은 거의 없으며 글로벌 작업에서 시작해야 합니다.
글쎄요, 저는 5개만 꿈꿉니다. 지금까지는 4개만 주문할 수 있는 아이디어를 구현하고 있습니다.
그리고 이것은 헛된 것입니다. 이제 하나의 파일에 두 플랫폼에 대한 코드를 작성할 수 있습니다. 차이점은 거래 부분과 시계열(지표 포함) 작업에만 있습니다.
클라우드는 정말 강력한 존재입니다.
지표에 관한 것이 아니라 고문에 관한 것이지만 주제는 가깝습니다. 내 스캘퍼는 모든 종류의 필터, 변형을 상당히 많이 계산합니다. 나는 즉시 Matlab의 모델에 대해 그러한 캐시를 만들었습니다. 먼저 모든 수학이 계산되어 .mat 파일에 덤프된 다음 이 데이터를 사용하여 전략이 실행되었습니다. 이제 내 손은 MQL4 테스터에 대해 동일한 작업을 수행하고 싶어 가렵습니다. 그렇지 않으면 최적화가 단순히 비현실적입니다.
별도의 지표에 대한 캐시를 갖는 것은 거의 의미가 없으며 조언자에서 필요한 데이터에서 시작했습니다.
대략적으로 말하면 기성 신호를 녹음한 다음 항목 및 위치 추적만 읽고 수행했습니다.
표시기는 하나의 버퍼만 계산할 수 없으며 호출 시 버퍼 안에 있는 모든 것을 계산합니다. 매개변수로 계산을 제한할 수 없다면 이것은 또 다른 주제입니다.
재계산은 각 호출에서 발생하지만 일반적으로 0번째 막대만 재계산됩니다. 그리고 Advisor도 올바르게 작성되면 이러한 호출이 모든 틱에서 발생하지 않습니다.
따라서 결국 많은 버퍼가 있는 하나의 표시기에 액세스하고 그 중 하나에서 모든 버퍼에 대한 정보를 얻으면 이 표시기를 몇 배나 계산하는 것보다 더 빠르고 메모리 효율적입니다. 다른 버퍼의 정보가 필요합니까?
그럼에도 불구하고 누군가가 실험을 할 것입니다. 그렇지 않으면 아이디어가 나를 놓지 않습니다!? 아니면 혁신 연구는 유료로만 흥미로운가요?
따라서 결국 많은 버퍼가 있는 하나의 표시기에 액세스하고 그 중 하나에서 모든 버퍼에 대한 정보를 얻으면 이 표시기를 몇 배나 계산하는 것보다 더 빠르고 메모리 효율적입니다. 다른 버퍼의 정보가 필요합니까?
5개의 버퍼에 대한 1개의 표시기 또는 1개의 버퍼에 대한 5개의 표시 - 거의 동일합니다.
2개의 버퍼에서만 정보가 필요한 경우 5개의 버퍼가 있는 하나의 표시기보다 1개의 버퍼가 있는 2개의 표시기를 호출하는 것이 더 유리합니다. 그러나 2개의 버퍼가 있는 하나의 지표보다 수익성이 좋지 않습니다.
그럼에도 불구하고 누군가가 실험을 할 것입니다. 그렇지 않으면 아이디어가 나를 놓지 않습니다!? 아니면 혁신 연구는 유료로만 흥미로운가요?
퇴비통 :
이 접근 방식은 표시기의 메모리 소비(전후 버퍼 수 차이의 대략 배수)를 줄이지만 프로세서의 부하를 증가시킵니다("어셈블리"와 "분해" 모두 지속적으로 수행되어야 함).
메모리 제한에 도달하지 않으면(현재 볼륨에서는 거의 발생하지 않음) 속도가 느려질 뿐입니다.
그들이 나를 이해하지 못하는 것 같아! :)
그러나 나는 이것을 이해하지 못할 가능성이 높다는 것을 이해합니다.
코드에서 사용자 지정 표시기 를 호출한다고 가정합니다. 이 표시기의 버퍼를 지정해야 하며 코드를 따라 계속해서 처음과 동일한 이름으로 다른 버퍼를 사용하여 사용자 지정 표시기를 다시 호출합니다.
질문: 지표가 두 번 계산됩니까 아니면 한 번만 계산됩니까?
...
질문 지표가 두 번 계산됩니까 아니면 한 번만 계산됩니까?
한번.