이 효과에 주목했습니다. 차트에 지표를 추가할 때(별도의 창에서), 시세 창에서는 모든 것이 정상이지만 기본 촛대 차트는 업데이트를 중지합니다(가격 고정). 가격은 빨간색에서 녹색으로 변경됩니다. 그리고 인디케이터는 한 상품의 창에만 추가되지만 가격은 다른 창에서도 동결됩니다. 표시기의 초기화 및 계산은 본문 내부에 있습니다: if(prev_calculated==0). 전일부터 시작되지 않은 종가는 계산에 포함됩니다(현재 종가는 포함되지 않음). 지표 계산이 끝나면 가격 표시가 다시 움직이기 시작하고 창과 동기적으로 변경됩니다. 사진에서 본 것:
이 효과에 주목했습니다. 차트에 지표를 추가할 때(별도의 창에서) 기본 촛대 차트는 업데이트를 중지합니다(가격 고정). 시세 창에서는 모든 것이 정상이지만 가격은 빨간색에서 녹색으로 변경됩니다. 그리고 인디케이터는 한 상품의 창에만 추가되지만 가격은 다른 창에서도 동결됩니다. 표시기의 초기화 및 계산은 본문 내부에 있습니다: if(prev_calculated==0). 전일부터 시작되지 않은 종가는 계산에 포함됩니다(현재 종가는 포함되지 않음). 지표 계산이 끝나면 가격 표시가 다시 움직이기 시작하고 창과 동기적으로 변경됩니다. 사진에서 본 것:
첫 번째 계산은 리소스를 매우 많이 사용하는 것으로 나타났습니다. 지시자 코드가 최적의 방식으로 작성되지 않았는지 확인하십시오.
첫 번째 계산은 리소스 집약적입니다. 지시자 코드가 최적의 방식으로 작성되지 않았는지 확인하십시오.
~에게 alexvd , 불행히도 이제 표시기에는 20개 이상의 클래스로 구성된 3000개 이상의 코드 라인이 있으며 코드를 최적화하는 것은 상당히 어렵습니다(주기적으로 수천억 개의 계산 작업). 이 숫자는 증가할 수 있습니다. 약 10,000까지. 촛대 차트의 따옴표 업데이트를 별도의 프로그램 스레드로 분리하고 지표 계산을 다른 스레드로 로드하는 것이 가능하다는 것을 의미했습니다. 사실 일을 막 시작했을 땐 데스크톱 컴퓨터에서 속도 문제가 이렇게 심각할 줄은 몰랐는데 작은 노트북도 써보고 싶었다.
-Alexey- : ~에게 alexvd , 불행히도 이제 표시기에는 20개 이상의 클래스로 구성된 3000개 이상의 코드 라인이 있으며 코드를 최적화하기가 상당히 어렵습니다(주기적으로 수천억 개의 계산 작업), 이 숫자는 증가할 수 있습니다 약 10,000. 별도의 프로그램 스레드에서 촛대 차트의 따옴표를 업데이트하는 것과 다른 스레드에서 표시기 계산을 로드하는 것을 어떻게든 구별할 수 있다는 의미였습니다. 사실 일을 막 시작했을 땐 데스크톱 컴퓨터에서 속도 문제가 이렇게 심각할 줄은 몰랐는데 작은 노트북도 써보고 싶었다.
지표를 최적화하려고 시도하십시오. 여기서 개체와 행의 수는 중요하지 않습니다. 대부분의 경우 기존 칠면조(3000줄)가 필요한 속도로 작동하도록 할 수 있습니다.
모든 리소스 집약적인 계산이 타이머에 배치되면(가능한 경우) 흥미로운 변형이 얻어지며 이러한 계산은 모든 틱에서 수행되지 않습니다.
표시기를 최적화하려고 시도하십시오. 여기서 개체와 행의 수는 중요하지 않습니다. 대부분의 경우 기존 칠면조(3000줄)가 필요한 속도로 작동하도록 할 수 있습니다.
모든 리소스 집약적인 계산이 타이머에 배치되면(가능한 경우) 흥미로운 변형이 얻어지며 이러한 계산은 모든 틱에서 수행되지 않습니다.
그리고 가능한 한 계산기 블록을 최적화하십시오(합리적인 통로까지).
원칙적으로 작업을 약간 최적화하는 것이 가능하기 때문입니다. 일부 동일한 데이터는 다른 클래스의 개체에서 고려됩니다. 한 번 이상. 그러나 여기서 또 다른 문제가 발생합니다. 즉, 각각 디버깅할 수 있고 확신할 수 있는 많은 블랙박스의 개념을 남겨두는 것입니다(즉, 각 개체는 완전히 자율적인 블록이고, 일부 중간 데이터의 계산이 다른 객체에 대해 동일하고 객체에서 제거하면 자율성이 상실되어 각 클래스를 개별적으로 디버깅할 수 있습니다. 이러한 주의를 기울이면 프로그램의 구조가 손실됩니다. 즉, 나 자신은 내가 작성한 내용을 이해하지 못할 것입니다. 작은 오류도 더 이상 잡히지 않을 것입니다. 디버깅 속도도 매우 빨라질 것입니다. 한 조각이 아니라 전체 알고리즘을 실행해야 하기 때문입니다. 이것이 제가 개체 수를 갖고 속도에 영향을 미치는 방식입니다.
따라서 지표가 완전히 생성, 디버깅 및 테스트되었을 때 이미 최종 단계에서 이러한 최적화를 시도하는 것이 가능할 것으로 보입니다. 약 4개월 동안 초기 단계는 계량경제학, 수학에 관한 책에서 모든 것이 다른 책의 단편으로 흩어져 있기 때문에(자료에 대한 세부적인 통일된 표현이 거의 없음), 저자는 용어와 알고리즘에 오류와 불일치가 있습니다. 초보자가 백과사전을 참조할 때만 발견할 수 있는 이론적 정보는 실제 구현 가능성과 충돌합니다. 즉 수치적 방법의 형태로 구현하고 수치적 방법 자체는 차례로 소프트웨어 환경의 기능에 대한 요구 사항을 부과합니다 이 과정은 길고 지루하며 점성이 있습니다.
계산 논리에 따르면 각 캔들 생성 후에 발생해야하므로 원래 "is new bar"함수의 본문에 배치되어야했지만 시간이이 간격을 초과 할 수 있다는 사실 때문에 어쩔 수 없었습니다. 이제 디버깅 단계에서 한 번만 전달되도록 if(prev_calculated=) function =0)의 본문 안에 배치합니다. 타이머 제안에 대해 생각해 보겠습니다. 감사합니다.
예, 그렇게 보이지 않습니다.
손실 거래는 2건(45건 중 2건)에 불과했으며 둘 다 매수 거래였습니다.
내가 잘못된 곳을 찾고 있는 것은 아닐까?
빨간색으로 표시: 45개 중 5개의 숏 포지션. 40개가 95%라고 가정해 보겠습니다. 질문 - 왜 5 = 100%인지 - 5%로 가정하는 것이 논리적입니다.
이 경우에는 5(11.11%)와 40(88.89%)이어야 하는 것 같습니다.
캐시를 지워보십시오. 다른 옵션, 다른 브라우저를 시도했지만 성공적으로 추가되었습니다.
결국 공격이 아니라 댓글 에 사진을 직접 삽입하는 건가요?
빨간색으로 표시: 45개 중 5개의 숏 포지션. 40개가 95%라고 가정해 보겠습니다. 질문 - 왜 5 = 100%인지, 5%라고 가정하는 것이 논리적입니다.
그 경우에는 5(11.11%)와 40(88.89%)이어야 한다고 생각합니다.
총 45개 거래:
우리가 얻는 총
판매 거래 - 5개, 그 중 100% 성공(수익성 없음)(즉, 모두 수익성 있음)
40개의 구매 거래가 있으며 그 중 38개가 이기고 있습니다(예: 38*100%/40=95%).
더 나아가
수익성 있는 거래 - 45개 중 43개, 즉 43*100%/45 = 95.56%
거래 손실 - 45개 중 2개, 즉 2*100%/45 = 4.44%
총 45개 거래:
우리가 얻는 총
판매 거래 - 5개, 그 중 100% 성공(수익성 없음)(즉, 모두 수익성 있음)
40개의 구매 거래가 있으며 그 중 38개가 이기고 있습니다(예: 38*100%/40=95%).
더 나아가
수익성 있는 거래 - 45개 중 43개, 즉 43*100%/45 = 95.56%
거래 손실 - 45개 중 2개, 즉 2*100%/45 = 4.44%
이 효과에 주목했습니다. 차트에 지표를 추가할 때(별도의 창에서), 시세 창에서는 모든 것이 정상이지만 기본 촛대 차트는 업데이트를 중지합니다(가격 고정). 가격은 빨간색에서 녹색으로 변경됩니다. 그리고 인디케이터는 한 상품의 창에만 추가되지만 가격은 다른 창에서도 동결됩니다. 표시기의 초기화 및 계산은 본문 내부에 있습니다: if(prev_calculated==0). 전일부터 시작되지 않은 종가는 계산에 포함됩니다(현재 종가는 포함되지 않음). 지표 계산이 끝나면 가격 표시가 다시 움직이기 시작하고 창과 동기적으로 변경됩니다.
사진에서 본 것:
이 효과에 주목했습니다. 차트에 지표를 추가할 때(별도의 창에서) 기본 촛대 차트는 업데이트를 중지합니다(가격 고정). 시세 창에서는 모든 것이 정상이지만 가격은 빨간색에서 녹색으로 변경됩니다. 그리고 인디케이터는 한 상품의 창에만 추가되지만 가격은 다른 창에서도 동결됩니다. 표시기의 초기화 및 계산은 본문 내부에 있습니다: if(prev_calculated==0). 전일부터 시작되지 않은 종가는 계산에 포함됩니다(현재 종가는 포함되지 않음). 지표 계산이 끝나면 가격 표시가 다시 움직이기 시작하고 창과 동기적으로 변경됩니다.
사진에서 본 것:
첫 번째 계산은 리소스를 매우 많이 사용하는 것으로 나타났습니다. 지시자 코드가 최적의 방식으로 작성되지 않았는지 확인하십시오.
첫 번째 계산은 리소스 집약적입니다. 지시자 코드가 최적의 방식으로 작성되지 않았는지 확인하십시오.
별도의 프로그램 스레드에서 촛대 차트의 따옴표를 업데이트하는 것과 다른 스레드에서 표시기 계산 을 로드하는 것을 어떻게든 구별할 수 있다는 의미였습니다.
차트의 시세 업데이트는 지표도 계산되는 터미널 시세 데이터베이스의 데이터 상태만 표시합니다. 자원을 절약하기 위해 지표에 입력 데이터로 전달되는 것은 터미널 데이터베이스 데이터입니다. 지표 계산 이 끝날 때까지 변경할 수 없습니다.
~에게 alexvd , 불행히도 이제 표시기에는 20개 이상의 클래스로 구성된 3000개 이상의 코드 라인이 있으며 코드를 최적화하기가 상당히 어렵습니다(주기적으로 수천억 개의 계산 작업), 이 숫자는 증가할 수 있습니다 약 10,000. 별도의 프로그램 스레드에서 촛대 차트의 따옴표를 업데이트하는 것과 다른 스레드에서 표시기 계산을 로드하는 것을 어떻게든 구별할 수 있다는 의미였습니다. 사실 일을 막 시작했을 땐 데스크톱 컴퓨터에서 속도 문제가 이렇게 심각할 줄은 몰랐는데 작은 노트북도 써보고 싶었다.
지표를 최적화하려고 시도하십시오. 여기서 개체와 행의 수는 중요하지 않습니다. 대부분의 경우 기존 칠면조(3000줄)가 필요한 속도로 작동하도록 할 수 있습니다.
모든 리소스 집약적인 계산이 타이머에 배치되면(가능한 경우) 흥미로운 변형이 얻어지며 이러한 계산은 모든 틱에서 수행되지 않습니다.
그리고 가능한 한 계산기 블록을 최적화하십시오(합리적인 통로까지).
표시기를 최적화하려고 시도하십시오. 여기서 개체와 행의 수는 중요하지 않습니다. 대부분의 경우 기존 칠면조(3000줄)가 필요한 속도로 작동하도록 할 수 있습니다.
모든 리소스 집약적인 계산이 타이머에 배치되면(가능한 경우) 흥미로운 변형이 얻어지며 이러한 계산은 모든 틱에서 수행되지 않습니다.
그리고 가능한 한 계산기 블록을 최적화하십시오(합리적인 통로까지).
원칙적으로 작업을 약간 최적화하는 것이 가능하기 때문입니다. 일부 동일한 데이터는 다른 클래스의 개체에서 고려됩니다. 한 번 이상. 그러나 여기서 또 다른 문제가 발생합니다. 즉, 각각 디버깅할 수 있고 확신할 수 있는 많은 블랙박스의 개념을 남겨두는 것입니다(즉, 각 개체는 완전히 자율적인 블록이고, 일부 중간 데이터의 계산이 다른 객체에 대해 동일하고 객체에서 제거하면 자율성이 상실되어 각 클래스를 개별적으로 디버깅할 수 있습니다. 이러한 주의를 기울이면 프로그램의 구조가 손실됩니다. 즉, 나 자신은 내가 작성한 내용을 이해하지 못할 것입니다. 작은 오류도 더 이상 잡히지 않을 것입니다. 디버깅 속도도 매우 빨라질 것입니다. 한 조각이 아니라 전체 알고리즘을 실행해야 하기 때문입니다. 이것이 제가 개체 수를 갖고 속도에 영향을 미치는 방식입니다.
따라서 지표가 완전히 생성, 디버깅 및 테스트되었을 때 이미 최종 단계에서 이러한 최적화를 시도하는 것이 가능할 것으로 보입니다. 약 4개월 동안 초기 단계는 계량경제학, 수학에 관한 책에서 모든 것이 다른 책의 단편으로 흩어져 있기 때문에(자료에 대한 세부적인 통일된 표현이 거의 없음), 저자는 용어와 알고리즘에 오류와 불일치가 있습니다. 초보자가 백과사전을 참조할 때만 발견할 수 있는 이론적 정보는 실제 구현 가능성과 충돌합니다. 즉 수치적 방법의 형태로 구현하고 수치적 방법 자체는 차례로 소프트웨어 환경의 기능에 대한 요구 사항을 부과합니다 이 과정은 길고 지루하며 점성이 있습니다.
계산 논리에 따르면 각 캔들 생성 후에 발생해야하므로 원래 "is new bar"함수의 본문에 배치되어야했지만 시간이이 간격을 초과 할 수 있다는 사실 때문에 어쩔 수 없었습니다. 이제 디버깅 단계에서 한 번만 전달되도록 if(prev_calculated=) function =0)의 본문 안에 배치합니다. 타이머 제안에 대해 생각해 보겠습니다. 감사합니다.