동일한 값의 표시기에 여러 추가 계산이 있으며 물론 동일한 결과를 제공합니다. 해결책은 분명한 것 같습니다. 한 번 계산(기록 데이터에 처음 액세스할 때)하고 모든 것을 버퍼에 푸시하고 다른 경우에는 완료된 결과를 조용히 참조하십시오. 하지만...
표시기에는 이미 상상할 수 없는 수의 버퍼가 있습니다(여러 다른 시간 프레임에서 전체 기록의 계산된 데이터를 저장하기 위해 최소 10개). 해당하는 초기 계산된 데이터에 대해 이미 액세스되었습니다. 이제 이론상 그리고 옵션으로 버퍼 수를 두 배로 늘릴 필요가 있습니다.
물론 모든 것은 하드웨어의 기술적 매개변수, 즉 프로세서의 처리 능력과 RAM의 양에 따라 다릅니다. 그리고 누가 이길 것입니다. 그러나 가장 신선한 가정용 PC가 아닌 매우 평범한 것으로 간주해 봅시다. 그리고 이것, 이것은 너무 많지도 적지도 않습니다. 반면에 메모리를 분산시키거나 컴퓨팅 성능을 선호하는 것은 어렵습니다.
따라서 지식이 풍부한 대중에게 질문하십시오. 무엇을 권장합니까? 아마도 이것 또는 그 옵션에 대한 "에 대한" 인수가 여전히 있을 것입니다... 또는 계산된 표시기 버퍼 를 두 배로 늘려 메모리를 어지럽히지 말고 프로세서를 워밍업하고 필요할 때마다 동일한 것을 계산하거나 그 반대의 경우도 마찬가지입니다.
물론 모든 것은 하드웨어의 기술적 매개변수, 즉 프로세서의 처리 능력과 RAM의 양에 따라 다릅니다. 그리고 누가 이길 것입니다. 그러나 가장 신선한 가정용 PC가 아닌 매우 평범한 것으로 간주해 봅시다. 그리고 이것, 이것은 너무 많지도 적지도 않습니다. 반면에 메모리를 분산시키거나 컴퓨팅 성능을 선호하는 것은 어렵습니다.
...
나는 수백 개의 어레이에 대한 지표를 만들었지만 아무 것도 없었습니다. 제 조언은 그것을 메모리 머신에 던지는 것입니다(다행히 지금은 비싸지 않습니다).
동일한 값의 표시기에 여러 추가 계산이 있으며 물론 동일한 결과를 제공합니다. 해결책은 분명한 것 같습니다. 한 번 계산(기록 데이터에 처음 액세스할 때)하고 모든 것을 버퍼에 푸시하고 다른 경우에는 완료된 결과를 조용히 참조하십시오. 하지만...
표시기에는 이미 상상할 수 없는 수의 버퍼가 있습니다(여러 다른 시간 프레임에서 전체 기록의 계산된 데이터를 저장하기 위해 최소 10개). 해당하는 초기 계산된 데이터에 대해 이미 액세스되었습니다. 이제 이론상 그리고 옵션으로 버퍼 수를 두 배로 늘릴 필요가 있습니다.
물론 모든 것은 하드웨어의 기술적 매개변수, 즉 프로세서의 처리 능력과 RAM의 양에 따라 다릅니다. 그리고 누가 이길 것입니다. 그러나 가장 신선한 가정용 PC가 아닌 매우 평균적인 것으로 간주합시다. 그리고 이것, 이것은 너무 많지도 적지도 않습니다. 반면에 메모리를 분산시키거나 컴퓨팅 성능을 선호하는 것은 어렵습니다.
따라서 지식이 풍부한 대중에게 질문하십시오. 무엇을 권장합니까? 아마도 이것 또는 그 옵션에 대한 "에 대한" 인수가 여전히 있을 것입니다... 또는 계산된 표시기 버퍼 를 두 배로 늘려 메모리를 어지럽히지 말고 프로세서를 워밍업하고 필요할 때마다 동일한 것을 계산하거나 그 반대의 경우도 마찬가지입니다.
고맙습니다.
또는 필요에 따라 데이터베이스를 사용하지 않는 이유는 무엇입니까? 우리는 계산하고 기록했습니다 .. 시간이되었습니다-가장 편리한 형태로 꺼내 사용합니다.
또는 필요에 따라 데이터베이스를 사용하지 않으시겠습니까? 우리는 계산하고 기록했습니다 .. 시간이되었습니다-가장 편리한 형태로 꺼내 사용합니다.
아키텍처 솔루션을 사용하면 계산과 결과 캐싱을 분리할 수 있습니다.
부정하는 것은 아니지만 "시간이 되었습니다"라는 문구는 틱마다 OnCalculate에서 각 호출이 재생된다는 점을 감안할 때 웃기게 들립니다. 데이터베이스가 RAM에 완전히 있어야 하거나 디스크에 천천히 액세스하여 먼지로 잘라야 합니다. 비록... 내가 DBMS에 대해 이해한 것은...
그러나 MQL은 데이터베이스 쿼리 언어가 아닙니까? 그렇다면 디스크에서 데이터베이스 작업이 이미 수행 중이고 디스크가 현재 살아있는 것처럼 보입니다. 여기서 새로운 것을 발명할 필요가 없습니다.
다른 데이터베이스와 액세스하는 특정(비표준) 방법을 의미했다면 설명하십시오. MQL5 상호 작용을 다른 것과 통합하는 것을 제안한다면 그렇게 하기에는 너무 이르고 MLQ를 공부하기 시작했고 고급 보일러로 이동 중입니다...
또한 내가 이해하는 한 손절매에 의한 마감은 테스터의 결과 보고서에서 거래를 손실 발생으로 나타냅니다(여기서 손실 발생 및 수익성 있는 거래의 비율)
Build 507로 업그레이드한 후 테스터에 두 가지 문제가 있습니다.
1. 최적화 중에 테스터 탭을 전환할 때 터미널이 주기적으로(항상 그런 것은 아님) 충돌합니다.
2. 열거형이 최적화된 매개변수로 선택된 경우 최적화 결과 중 하나를 실행하려고 할 때 Expert Advisor는 이 열거형의 값을 볼 수 없습니다. 항상 0입니다.
Build 507로 업그레이드한 후 테스터에 두 가지 문제가 있습니다.
1. 최적화 중에 테스터 탭을 전환할 때 터미널이 주기적으로(항상 그런 것은 아님) 충돌합니다.
2. 열거형이 최적화된 매개변수로 선택된 경우 최적화 결과 중 하나를 실행하려고 할 때 Expert Advisor는 이 열거형의 값을 볼 수 없습니다. 항상 0입니다.
가능한 한 자세하게 서비스 데스크에 작성하십시오.
열거형에 최적화 문제가 있다는 것을 알고 있지만 버그를 재현할 수 없는 것 같습니다.
서비스 데스크에 작성...
귀하의 신청서를 수락하고 명확한 질문을 했습니다.
... 그리고 여기서 질문이 생깁니다 (수사학적?) ...
동일한 값의 표시기에 여러 추가 계산이 있으며 물론 동일한 결과를 제공합니다. 해결책은 분명한 것 같습니다. 한 번 계산(기록 데이터에 처음 액세스할 때)하고 모든 것을 버퍼에 푸시하고 다른 경우에는 완료된 결과를 조용히 참조하십시오. 하지만...
표시기에는 이미 상상할 수 없는 수의 버퍼가 있습니다(여러 다른 시간 프레임에서 전체 기록의 계산된 데이터를 저장하기 위해 최소 10개). 해당하는 초기 계산된 데이터에 대해 이미 액세스되었습니다. 이제 이론상 그리고 옵션으로 버퍼 수를 두 배로 늘릴 필요가 있습니다.
물론 모든 것은 하드웨어의 기술적 매개변수, 즉 프로세서의 처리 능력과 RAM의 양에 따라 다릅니다. 그리고 누가 이길 것입니다. 그러나 가장 신선한 가정용 PC가 아닌 매우 평범한 것으로 간주해 봅시다. 그리고 이것, 이것은 너무 많지도 적지도 않습니다. 반면에 메모리를 분산시키거나 컴퓨팅 성능을 선호하는 것은 어렵습니다.
따라서 지식이 풍부한 대중에게 질문하십시오. 무엇을 권장합니까? 아마도 이것 또는 그 옵션에 대한 "에 대한" 인수가 여전히 있을 것입니다... 또는 계산된 표시기 버퍼 를 두 배로 늘려 메모리를 어지럽히지 말고 프로세서를 워밍업하고 필요할 때마다 동일한 것을 계산하거나 그 반대의 경우도 마찬가지입니다.
고맙습니다.
... 그리고 여기서 질문이 생깁니다 (수사학적?) ...
...물론 모든 것은 하드웨어의 기술적 매개변수, 즉 프로세서의 처리 능력과 RAM의 양에 따라 다릅니다. 그리고 누가 이길 것입니다. 그러나 가장 신선한 가정용 PC가 아닌 매우 평범한 것으로 간주해 봅시다. 그리고 이것, 이것은 너무 많지도 적지도 않습니다. 반면에 메모리를 분산시키거나 컴퓨팅 성능을 선호하는 것은 어렵습니다.
...
... 그리고 여기서 질문이 생깁니다 (수사학적?) ...
동일한 값의 표시기에 여러 추가 계산이 있으며 물론 동일한 결과를 제공합니다. 해결책은 분명한 것 같습니다. 한 번 계산(기록 데이터에 처음 액세스할 때)하고 모든 것을 버퍼에 푸시하고 다른 경우에는 완료된 결과를 조용히 참조하십시오. 하지만...
표시기에는 이미 상상할 수 없는 수의 버퍼가 있습니다(여러 다른 시간 프레임에서 전체 기록의 계산된 데이터를 저장하기 위해 최소 10개). 해당하는 초기 계산된 데이터에 대해 이미 액세스되었습니다. 이제 이론상 그리고 옵션으로 버퍼 수를 두 배로 늘릴 필요가 있습니다.
물론 모든 것은 하드웨어의 기술적 매개변수, 즉 프로세서의 처리 능력과 RAM의 양에 따라 다릅니다. 그리고 누가 이길 것입니다. 그러나 가장 신선한 가정용 PC가 아닌 매우 평균적인 것으로 간주합시다. 그리고 이것, 이것은 너무 많지도 적지도 않습니다. 반면에 메모리를 분산시키거나 컴퓨팅 성능을 선호하는 것은 어렵습니다.
따라서 지식이 풍부한 대중에게 질문하십시오. 무엇을 권장합니까? 아마도 이것 또는 그 옵션에 대한 "에 대한" 인수가 여전히 있을 것입니다... 또는 계산된 표시기 버퍼 를 두 배로 늘려 메모리를 어지럽히지 말고 프로세서를 워밍업하고 필요할 때마다 동일한 것을 계산하거나 그 반대의 경우도 마찬가지입니다.
고맙습니다.
또는 필요에 따라 데이터베이스를 사용하지 않는 이유는 무엇입니까? 우리는 계산하고 기록했습니다 .. 시간이되었습니다-가장 편리한 형태로 꺼내 사용합니다.
아키텍처 솔루션을 사용하면 계산과 결과 캐싱을 분리할 수 있습니다.
또는 필요에 따라 데이터베이스를 사용하지 않으시겠습니까? 우리는 계산하고 기록했습니다 .. 시간이되었습니다-가장 편리한 형태로 꺼내 사용합니다.
아키텍처 솔루션을 사용하면 계산과 결과 캐싱을 분리할 수 있습니다.
부정하는 것은 아니지만 "시간이 되었습니다"라는 문구는 틱마다 OnCalculate에서 각 호출이 재생된다는 점을 감안할 때 웃기게 들립니다. 데이터베이스가 RAM에 완전히 있어야 하거나 디스크에 천천히 액세스하여 먼지로 잘라야 합니다. 비록... 내가 DBMS에 대해 이해한 것은...
그러나 MQL은 데이터베이스 쿼리 언어가 아닙니까? 그렇다면 디스크에서 데이터베이스 작업이 이미 수행 중이고 디스크가 현재 살아있는 것처럼 보입니다. 여기서 새로운 것을 발명할 필요가 없습니다.
다른 데이터베이스와 액세스하는 특정(비표준) 방법을 의미했다면 설명하십시오. MQL5 상호 작용을 다른 것과 통합하는 것을 제안한다면 그렇게 하기에는 너무 이르고 MLQ를 공부하기 시작했고 고급 보일러로 이동 중입니다...
종종 서버와 연결이 끊어집니다. 동시에 표시기는 안정적인 연결을 보여줍니다.
터미널이 다시 연결되지 않습니다. 수동으로 로그인해야 합니다. MQL5를 사용하여 프로그래밍 방식으로 이 작업을 수행할 수 있습니까?