Реter Konow : 글쎄요, 사고에 대한 보장은 없습니다. 인적 요소는 근절 불가능합니다.))
자, 여기 있습니다. 따라서 사람의 실수를 가능한 한 제한하는 방식으로 코드를 작성해야 한다고 생각합니다. 바로 인적 요소 - 비 근절 때문입니다. 어제까지만 해도 Expert Advisor에 대한 통계가 지정된 날짜(Expert Advisor가 생성된 날짜)가 아니라 기록의 시작 부분에서 수집되었기 때문에 코드에서 오류를 발견했습니다. 방금 변수를 초기화하는 것을 잊었고 null로 유지되었습니다.
이제 나는 요청을 할 때 분석할 날짜를 지정해야 하고 Expert Advisor의 부품 공장이 생성 날짜만 반환하도록 분석기를 재설계했습니다. 다른 사람.
현재 - Expert Advisor 생성 시점 이전의 거래 내역을 분석하는 것은 불가능합니다. 이전 버전에서 트랜잭션이 발생했더라도 이제는 통계에 포함되지 않습니다.
기호의 막대는 언제든지 올 수 있으며 임무는 바로 그 순간에 새 막대가 도착했음을 시스템에 알리는 것입니다. 시스템이 1분에 한 번 폴링될 때를 어떻게 상상하십니까?
왜 "지금 이 순간에"???
친구 여러분, 거래에 대한 접근 방식이 다릅니다. 우리가 M1 시간 프레임에 작업 중이라면 - 새로운 막대가 도착했다는 정보 - 우리는 "같은 순간"이 아니라 새로운 분이 도착했을 때 받아야 합니다. S1 기간(안녕하세요, Volchansky)에서 작업하는 경우 새로운 초가 도착할 때 이 정보를 받아야 합니다. 모든 진드기에 대해 작업하는 경우 정보는 새 진드기의 도착과 함께 제공되어야 합니다.
알았습니다. 즉, 바는 투표 당시에 오지 않고 투표 직후에 올 수 있습니다. 그런 다음 시스템에 대해 건너뜁니다. 케이스에 있습니다.
Peter, 두 번째로 토론할 다른 주제를 제안합니다. 아무 것도 쓸 필요가 없고 이론만 있으면 됩니다.
OOP 사용성의 원시적인 예를 찾은 것 같습니다. 다음은 지정된 값으로 배열을 채우는 함수입니다. 배열 유형에 따라 8가지 종류가 있습니다.
한 세트의 매개변수를 전달해야 하는 함수를 작성해야 하는 경우를 상상해 보십시오. 그런 다음 다른 한 세트를 전달한 다음 세 번째 세트를 전달해야 합니다. 알고리즘 접근 방식을 사용하면 N개의 다른 함수 이름을 얻게 됩니다. 괜찮은 것 같습니다. ArrayInitialize Int() A rrayInitializeDouble() 등과 같이 8을 작성할 수 있습니다. 하지만 결국 배열의 종류에 대해 생각하지 않고 어떤 경우에도 하나의 함수를 적용하는 것이 얼마나 좋은지, 그리고 거기에 어떤 배열을 넣을지 혼동하는 것이 얼마나 안전한지 ...
이것이 장점인지는 논란의 여지가 있습니다.
우연히 누군가가 깃발을 바꿀 것이며 이는 차량의 동작에 영향을 줄 것입니다.
나의 본래 임무 : OOP를 사용하지 않고 효과적인 솔루션을 보여줍니다.
내 결정의 핵심 : - 분당 한 번씩 모든 기호 및 시간 프레임의 새 막대에 대한 이벤트 플래그의 전역 배열 형성.
장점:
1. 자동 배열 채우기 및 자동 지우기.
2. 시스템에 부하가 없습니다.
3. 모든 기능에서 어레이에 직접 액세스 하고 어레이가 지워질 때까지 이벤트 플래그를 저장합니다.
글쎄요, 사고에 대한 보장은 없습니다. 인적 요소는 근절 불가능합니다.))
자, 여기 있습니다. 따라서 사람의 실수를 가능한 한 제한하는 방식으로 코드를 작성해야 한다고 생각합니다. 바로 인적 요소 - 비 근절 때문입니다. 어제까지만 해도 Expert Advisor에 대한 통계가 지정된 날짜(Expert Advisor가 생성된 날짜)가 아니라 기록의 시작 부분에서 수집되었기 때문에 코드에서 오류를 발견했습니다. 방금 변수를 초기화하는 것을 잊었고 null로 유지되었습니다.
이제 나는 요청을 할 때 분석할 날짜를 지정해야 하고 Expert Advisor의 부품 공장이 생성 날짜만 반환하도록 분석기를 재설계했습니다. 다른 사람.
현재 - Expert Advisor 생성 시점 이전의 거래 내역을 분석하는 것은 불가능합니다. 이전 버전에서 트랜잭션이 발생했더라도 이제는 통계에 포함되지 않습니다.
젠장, 드디어 일어나....
왜 "지금 이 순간에"???
친구 여러분, 거래에 대한 접근 방식이 다릅니다. 우리가 M1 시간 프레임에 작업 중이라면 - 새로운 막대가 도착했다는 정보 - 우리는 "같은 순간"이 아니라 새로운 분이 도착했을 때 받아야 합니다. S1 기간(안녕하세요, Volchansky)에서 작업하는 경우 새로운 초가 도착할 때 이 정보를 받아야 합니다. 모든 진드기에 대해 작업하는 경우 정보는 새 진드기의 도착과 함께 제공되어야 합니다.
그리고 "이벤트 작업" 옵션이 있지만 IsNewBar() 함수가 없어야 하지만 실제로 OnTick() 함수의 "하위 집합" 인 OnNewBar() 함수가 있어야 합니다.
젠장, 드디어 일어나....
젠장, 드디어 일어나....
알았습니다. 즉, 바는 iBars 요청 시점에 도착하지 않고 요청 직후에 도착할 수 있습니다. 그런 다음 시스템에 대해 건너뜁니다. 케이스에 있습니다.
그럼 뭐, 계속 돌릴까? - 분명히 최선의 해결책은 아닙니다.
알았습니다. 즉, 바는 투표 당시에 오지 않고 투표 직후에 올 수 있습니다. 그런 다음 시스템에 대해 건너뜁니다. 케이스에 있습니다.
Peter, 두 번째로 토론할 다른 주제를 제안합니다. 아무 것도 쓸 필요가 없고 이론만 있으면 됩니다.
OOP 사용성의 원시적인 예를 찾은 것 같습니다. 다음은 지정된 값으로 배열을 채우는 함수입니다. 배열 유형에 따라 8가지 종류가 있습니다.
한 세트의 매개변수를 전달해야 하는 함수를 작성해야 하는 경우를 상상해 보십시오. 그런 다음 다른 한 세트를 전달한 다음 세 번째 세트를 전달해야 합니다. 알고리즘 접근 방식을 사용하면 N개의 다른 함수 이름을 얻게 됩니다. 괜찮은 것 같습니다. ArrayInitialize Int() A rrayInitializeDouble() 등과 같이 8을 작성할 수 있습니다. 하지만 결국 배열의 종류에 대해 생각하지 않고 어떤 경우에도 하나의 함수를 적용하는 것이 얼마나 좋은지, 그리고 거기에 어떤 배열을 넣을지 혼동하는 것이 얼마나 안전한지 ...
Peter, 두 번째로 토론할 다른 주제를 제안합니다. 아무 것도 쓸 필요가 없고 이론만 있으면 됩니다.
조금만 기다려 주세요. 우리는 이 주제를 완전히 이해하고 두 번째 주제를 주의 깊게 읽을 것입니다.
기억하시겠지만 새 막대 의 주제는 OOP의 장점을 찾기 위해 제기되었지만 프로그래밍 옵션이 아니라 확실히 귀하의 능력이 아닙니다. 그러나 코드와 알고리즘 전체에 대한 주석은 토론을 잘못된 단계로 몰아갔습니다. 따라서 계속할 필요는 없다고 생각합니다.
기억하시겠지만 새 막대 의 주제는 OOP의 장점을 찾기 위해 제기되었지만 프로그래밍 옵션이 아니라 확실히 귀하의 능력이 아닙니다. 그러나 코드와 알고리즘 전체에 대한 주석으로 인해 토론이 잘못된 단계로 바뀌었습니다. 따라서 계속할 필요는 없다고 생각합니다.